In talking with Hagai, it was suggested that I try using the TLS/IMAP capabilities of Thunderbird, which I turned on (it's been a year or two since the last time I tried it). Unfortunately, nothing happened. Nothing positive, nothing negative. Cue in here a long debate about whether it was working or not, and how there should be a status display, at least, and various other remedies, at most.
A week later, the cleaning lady came in and cleaned up my desk. This process, for her, also involves unpowering the machine. Darn, normally I leave it on for ever, like a couple of months or so.
On restarting everything, Thunderbird could not connect to the mail servers. Our earlier mystery is thus resolved - the settings don't take effect until restart. Doh!
So, how then did Thunderbird handle? Not so well, but it may have got there in the end. This gives me a change to do a sort of case study in 1990s design weaknesses, a critique in (un)usability, leading to design principles updated for this decade.
To predict the punch line, the big result is that there should only be one mode, and it should be secure. To get there more slowly, here's what I observed:
Firstly, Thunderbird grumbled about the certificate being in the wrong name. I got my negative signal, and I knew that there was something working! Hooray!
But, then it turned out that Thunderbird still could not connect, because "You have chosen secure authentication, but this server does not offer it. Therefore you cannot log in..." Or somesuch. Then I had to go find that option and turn it off. This had to be done for all mail accounts, one by one.
Then it worked. Well, I *guess* it did... because funnily enough it already had the mail, and again had not evidenced any difference.
Let's break this up into point form. Further, let's also assume that all competing products to be as bad or worse. I actually *choose* Thunderbird as my preferred email client, over say Kmail. So it's not as bad as it sounds; I'm not "abandoning Thunderbird", I'm just not getting much security benefit from it, and I'm not recommending it to others for security purposes.
Another demerit: multiple options with no clear relationship, but unfortunate consequences.
(So, we now start to see what "need" means when used by users... it means "I need my email and I'll switch the darned security rubbish off and/or move to another system / supplier / etc.)
We can conclude that this is a nightmare in terms of:
Let's put this in context: when this system was designed, we didn't have the knowledge we have now. Thunderbird's security concept is at least 3 years old, probably 8-10 years old. Since those years have passed, we've got phishing, usability studies, opportunistic crypto, successful user-level cryptoapps (two, now), and a large body of research that tells us how to do it properly.
We know way more than we did 3 years ago - which was when I started on phishing. (FTR, I suggested visit counts! How hokey!)
Having got the apologies off our chest, let's get to the serious slamming: If you look at any minor mods to the Thunderbird TLS-based security, like an extra popup, or extra info or displays, you still end up with a mess. E.g., Hagai suggested that there should be an icon to display what is going on - but that only helps *me* being an experience user who knows exactly what it is trying to tell me. I know what is meant by 'secure authentication' but if you ask grandma, she'll offer you some carrot cake and say "yes, dear. now have some of this, I grew the carrots myself!"
(And, in so doing, she'll prove herself wiser than any of us. And she grows carrots!)
Pigs cannot be improved by putting them in dresses - this security system is a pig and won't be improved by frills.
The *design* is completely backwards, and all it serves to do is frustrate the use of the system. The PKI view is that the architecture is in place for good reasons, and therefore the user should be instructed and led along that system path. Hence,
"We need to educate the users better."
That is a truly utterly disastrous recommendation. No! Firstly, the system is wrong, for reasons that we can skip today. Secondly, the technical choices being offered to the users are beyond their capabilities. This can never be "educated." Thirdly, it's a totally inefficient use of the user's time. Fourthly, the end effect is that most users will not ever get the benefit.
(That would be a mighty fine survey -- how many users get the benefit of TLS security in Thunderbird? If it is less than 10%, that's a failure.)
The system should be reversed in logic. It should automatically achieve what it can achieve and then simply display somewhere how far it got:
The buttons to turn these modes on are totally unneccessary. We have computers to figure that sort of nonsense out.
Even the above is not the best way. Fallback modes are difficult to get right. They are very expensive, brittle even. (But, they are better - far far far cheaper - than asking the user to make those choices.) There is still one way to improve on this!
Hence, after 5 demerits and a handful of higher-level critiques, we get to the punchline:
To improve, there should only be one mode. And that mode is secure. There should be only one mode, because that means you can eliminate the fallback code. Code that falls back is probably twice as large as code that does not fallback. Twice as brittle, four times as many customer complaints. I speak from experience...
The principle, which I call my 3rd Hypothesis in Secure Protocol Design, reads like this:
There is only one mode, and it is secure.
If you compare and contrast that principle with all the above, you'll find that all the above bugs magically disappear. In fact, a whole lot of your life suddenly becomes much better.
Now, again, let's drag in some wider context. It is interesting that email can never ever get away from the fact that it will always have this sucky insecure mode. Several of them, indeed. So we may never get away from fallbacks, for email at least.
That unfortunate legacy should be considered as the reality that clashes with the Hypothesis. It is email that breaches the Hypothesis, and it and all of us suffer for it.
There is no use bemoaning the historical disaster that is email. But: new designs can and will get it right. Skype has adopted this Hypothesis, and it took over - it owns VoIP space in part because it delivered security without the cost. SSH did exactly the same, before.
In time, other communication designs such as for IM/chat and emerging methods will adopt Hypothesis #3, and they will compete with Skype. Some of the mail systems (Start/TLS ?) have also adopted it, and where they do, they do very well, allegedly.
(Nobody can compete with SSH, because we only need one open source product there - the task is so well defined there isn't any room for innovation. Well, that's not exactly true - there are at least two innovations coming down the pipeline that I know of but they both embrace and extend. But that's topic drift.)
Posted by iang at July 23, 2006 07:19 AM | TrackBack> I do know that the ISP is not the same name as my domain
> name, dammit!!!!" This is an old debate; in the PKI world,
> they do not subscribe to the theory that the user knows more > than any CA
actually I think that the PKI position is that nobody knows more than the CA about anything ... otherwise it would start to erode the idea that the CA should be paid for knowing more than everybody else. misc. past certificateless postings
http://www.garlic.com/~lynn/subpubkey.html#certless
> Nobody can compete with SSH
earlier ssh related thread
https://financialcryptography.com/mt/archives/000769.html
and even more topic drift in that thread mentioning IETF
RFC on using DNS to publish SSH key fingerprints
http://www.garlic.com/~lynn/aadsm24.htm@24
i.e. the equivalent feature/function provided by PKI CA digital certificates ... how do i know that a supplied public key really belongs to the associated entity
and pointing out that I've made large number of postings in the past that something similar could be done for an SSL implementation (relying directly on the domain name infrastructure rather than having a PKI certificate authority inserting themselves in the middle).
lots of past posts pointing at that PKI CAs have to rely on the domain name infrastructure as to the true domain name owner ... and potentially if public keys were registered directly with the domain name infrastructure ... then the PKI CA middlemen could be totally eliminated.
I've frequently raised the catch22 issue where the PKI domain name certification industry has suggested direct public key registration with the domain name infrastructure as part of improving the reliability and integrity of PKI CA certified information (in PKI CA digital certificates). However this could also be viewed as sowing the seeds of their own demise.
a few of the past "catch22" posts:
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm23.htm#47 Status of opportunistic encryption
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#27 confidence in CA
http://www.garlic.com/~lynn/2006h.html#34 The Pankian Metaphor
sorry, couldn't resist
IBM Virtualization Achieves One of Industry's Highest Security Levels, Says Government Evaluator
http://www.marketwire.com/mw/release_html_b1?release_id=146570
the more things change, the more things stay the same, some
reference to doing this same stuff nearly 40 years ago (building secure systems)
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
recent post building secure systems going back only 20-30 years
http://www.garlic.com/~lynn/2006n.html#44
http://www.garlic.com/~lynn/2006n.html#47
Ian, you may want to check out Nelson Bolyard's comments in mozilla.dev.tech.crypto regarding the Thunderbird SSL/TLS-related options. Also, I think your point about "There is only one mode, and it is secure" is well-taken. This worked for Skype because Skype controlled both ends of the communication channel. It's possible in IM as well because typically the client and server are tied together (e.g., AIM client talks to AIM servers, MSN client talks to MSN server, etc.). Obviously this is not the case in legacy email (a partial exception being the Outlook/Exchange combination).
Posted by: Frank Hecker at July 23, 2006 05:50 PMIan, I have a lot of experience deploying and supporting Thunderbird in "secure mode" to a number of users. I must say that I did not encounter as many problems as you describe, while I was able to provide a TLS connection to POP3 and IMAP, using server authentication, and disallowing non-TLS, non-secure connections for the users. Moreover, I added OpenPGP support with the Enigmail plugin, to achieve encrypted and signed e-mail among this group of users. However I do agree that several things should be done differently in Thunderbird.
You claim that "There is only one mode, and it is secure" and it seems from your post that Thunderbird is completely at fault for not complying to this single mode (secure mode).
I think it is unfair to dump all responsability on Thunderbird, because the infrastructure (e-mail servers and CAs) take part in this process as well, and as you very well point out, e-mail has been insecure from its very beginning.
Lastly, I'd like to point out that if e-mail had been designed with stringent security features and requirements from the get-go, e-mail would probably have not flourished as the killer app that it is. We would have a secure e-mail system, without much use.
I would also like to point out that Skype offers confidential connections between two users, but there is no authentication of the remote user. I have no way to verify the identity of the other user before I establish the voip call with them. I may not want an attacker to have a recording of my voice, but an attacker can try to voip me using a made-up Skype ID that sounds familiar to me, and then try to impersonate the voice of someone I know, while recording my voice. Therefore, Skype may be very cool and all, but I would not call it "secure". In any communication, I regard authentication as much more important than confidentiality.
Posted by: Pedro Soria-Rodriguez at July 24, 2006 02:34 AM> There is no ability to say "Yes, use that cert for ever, I
> do know that the ISP is not the same name as my domain name,
> dammit!!!!"
See the Remember Mismatched Domains plugin:
https://addons.mozilla.org/firefox/2131/
Pedro: thanks for your comments. I am sure that an experienced systems guy can whizz through the Thunderbird install for users. That's not the point; can a user? No, I suggest, there are too many barriers.
The rant probably reads as quixotic. That's because I know more than a user, but when I use software, I have a habit of being a user, not knowing enough. That's partly because I don't have time to learn it all, partly to help me see the user's perspective, and partly to understand the long term value of the solution. I find that thinking like a techie helps me understand how the guy built it, and thinking like a dumb user helps me understand how the product will fail or succeed in the marketplace. In this particulate case I have little interest in how it was built, and a lot of interest in how we get crypto to the user.
> I think it is unfair to dump all responsability on Thunderbird,...
I agree Thunderbird has little of the responsibility.
They were handed a design from way back when, back in the days when email had no validated threats. The logic of this design is lost in time, and it is only over the last 3-6 years has there been a concerted attempt to rework designs for the new knowledge we have. We now know so much more, and only one instance of this knowledge is:
"There is only one mode, and it is secure."
The reasons for this are long and noisy ... which I do not go into in the post. I simply point out that practically all the woes listed disappear when we adopt that principle.
Frank underscores above how this won't work for email, and you may think it is unfair to use Thunderbird as the whipping boy for these ills. That's not my point although I accept it will appear unfair; my point is that the old designs are bad, and new designs should not copy them. We can only make that point by showing the old designs to be bad.
Posted by: Iang at July 26, 2006 08:10 AMPedro, on this specific point:
> I would also like to point out that Skype offers confidential connections between two users, but there is no authentication of the remote user. I have no way to verify the identity of the other user before I establish the voip call with them.
This is the PKI position, and it is wrong. There's no other way to call it.
What skype does is to authenticate that who you are talking to is the same login account as last time. It leaves to you to determine what that means. In contrast, what PKI does is to authenticate to you that the CA says the machine is a person calling themselves X. See Lynn's comment above.
Both of them have a flaw. In Skype you have to figure it out yourself (easy, listen to the voice). In PKI, you are vulnerable to the brittle architecture, which is far more loose than you can possibly imagine (click on the link for just how hard this is).
Both work technically for mild situations. Skype wins because it is free, which is why there are nearly 6 million people using skype right now, and maybe 200-400k websites using certificates. I have no stats on how many people use certs in email clients, but it is probably less than a million, more like 100k. That's after a decade of trying...
> Therefore, Skype may be very cool and all, but I would not call it "secure". In any communication, I regard authentication as much more important than confidentiality.
Right. This is correct: your definition of security is different to everyone elses. Skype is secure, according to their definition. PKI is secure by its definition. So the question is, what definition of security is best?
The market is deciding. Skype's may not be what you want, but it is what the users want. 6,047,744 users logged in right now - the most successful crypto tool ever, by the only metric that matters: usage. I think we've shown over a decade or so that PKI isn't what the market wants.
Posted by: Iang (PKI flaws) at July 26, 2006 08:37 AMThe thread Frank was referring to is here:
http://groups.google.com/group/mozilla.dev.security/browse_frm/thread/c959dad07d22cf26/8cb4623158b64971#8cb4623158b64971
In brief, it seems like the mozo users & developers are also discussing this, for the laudable purposes of bettering Thunderbird. It starts:
=========== Deneb Meketa writes:
Looking at the "Server Settings" panel for an email account in [Thunderbird/Mozilla] 1.5, I see these options:
Security Settings
Use secure connection:
() Never
() TLS, if available
() TLS
() SSL
[] Use secure authentication
I'm curious what "use secure authentication" actually does. I'd like to see security be really easy for users, and I think they will find it confusing (I certainly do) that "use secure authentication" is separate from "use secure connection". How do the two differ?
I have a few theories:
Posted by: Frank's Thread at July 26, 2006 04:47 PManother kind of digital signature certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#certless
where characteristics of each chip is recorded in the fab manufactoring standard manifest
http://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#51 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
basically extending chip manufactoring serial number with digital signatures and private key that is never divulged ... as countermeasure to things like "copy chips" (akin to copy/counterfeit watches, copy/counterfeit DVDs, copy/counterfeit jeans, etc).
so the chip claims to be an original, provides a digital signature and a public key as evidence supporting the assertion ... and then the serial number and public key can be used to lookup the chip in the fab's manifest and obtain the associated information (like integrity characteristics of the chip). Trivial information is binary condition whether the chip is original (or possible copy/counterfeit).
Standard serial number is static and vulnerable to skimming and replay attack. Public key and digital signature is dynamic and countermeasure to simple impersonation replay attack.
Another variation is public key for kerberos,
http://www.garlic.com/~lynn/subpubkey.html#kerberos
the original PK-init draft for kerberos just specified certificateless public key operation ... where a public key was registered for a userid in lieu of registering a password. under various pressures, the kerberos pk-init draft was extended to include PKI certificate-mode of operation.
now, if the certificate was sufficient, by itself ... then anybody with a valid certificate could connect to every system (that support kerberos authentication ... like all the windows systems).
however, instead ... a PKI kerberos infrastructures now will have redundent and duplicated administrative infrastructures ... one for the registration and issuing of a digital certificate and one of registration and specification of allowed userids .... along with matching a digital certificate to userids .... compared to the certificateless pk-init which simply added public key registration (in lieue of password) to the existing, single kerberos administration infrastructure.
so i typically want to register my list of friends (or other entities with specific characteristics meaningful to me) ... and I could do it by having a local repository (various kinds of address or phone book) where i register their public key (and other meaningful personal context information)
Any sort of generic digital certificate may aid in validating that whoever some entity claims to be, was able to provide some proof to a certification authority that appeared to substantiate a similar claim. However, that would fail to provide a local context ... i.e. just because somebody is authenticated within the context of a generic digital certificate would still fail to indicate whether they should be allowed to enter my house, drive my car, or use my computer.
previous post in this thread:
http://www.garlic.com/~lynn/aadsm24.htm#44
send me some algorithms
Posted by: guruprasad at November 9, 2009 07:01 AM