> 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).

Ian, 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.

> 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.

Pedro, 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.

The 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:

another 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