I said "yes, people are proposing to read cert fingerprints over the phone to authenticate public keys."
Who is proposing that? I certainly wasn't, and I hope you didn't say so.
(But, FWIW, in the case of my bank, I did exchange keys with my bank using a paper letter. They do that with all customers for RSA authentication with HBCI, a German banking standard for financial applications.)
He said "That's the theoretical SSH model! Let me tell you about the REAL SSH model". He went on to say that people visit an SSH server, it presents an RSA public key, and they just blindly trust it without any effort to check its authenticity first, because that's too inconventient.
Right.
In other words, people use SSH in a way that provides NO authentication whatsoever. They get encryption, and feel good about that, not realizing how easy MITM attacks with transparent proxies and routers really are. They get no more real security than without any encryption at all, especially not from any governments.
True - if, and only if, the first connection is tampered with. If the first connection is secure, all are, because they all use the same keys. The fingerprints are stored automatically and compared the next time.
The whole *idea* of this model is that I *do* store the keys (or fingerprints). If I don't store them and always just use the keys the sites presents, then I indeed have no security at all.
If the first connection is tampered with and the rest isn't, the (successful) attack is uncovered in retroperspect. So, to have the victim not notice the problem, you have to run the man-in-the-middle attack *always*, basically *forever*. Even if the victim changes ISPs or travels.
Now, if you believe authentication is not needed for adequate security, if you believe we really don't need more authentication than what we get with present insecure protocols, then why not just drop encryption alltogether?
You have a different kind of authentication in mind. CAs are based on the idea that (esp. in the case of S/MIME) the *real name* is what's important. I claim that for a number of cases, it's the *continuity* that's important.
I meet somebody online via IRC or find a company online via Google. I gain trust in that entity. A week later, I want to come back to that entity. That *same* entity. It would be a breach of security for me to unknowingly talk to another entity with the same name, but I don't care what the real name of the entity is. E.g. if I talked to Mark Franklin last week and now talk to a Mary Franklin again, but it's a different person this time, I have a problem. If the Mary Franklin I talked to is really Mary Bullard in real life, it's usually not a problem for me.
Note that this is no different from domain names. I find a company online, remember the domain name or bookmark it, and then come back to that domain. The domain name has hardly any connection to real life. Nevertheless, it's the key for trust on the web - even with SSL.
The case is different for ecommerce, where liability matters. When I need the ability to sue, the real name matters, and the CA-based model is of real utility. Also, with ecommerce, usually it doesn't matter, if the government is listening.
The 2 models are not exclusive:
IMO, the continuity of the cert should be checked in *any* case, with or without CAs, because of the threat model I outlined earlier. For me, it would be a severe security bug to not do that. I don't know if Mozilla currently does, I haven't tested it.
Additionally, you can use the proposed model for self-signed keys, but then not trust the real name. Only when the cert is signed by a trusted CA, you mark the real name as trusted / verified 'by CA XYZ'.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
