Mike McNally writes:
aba@atlas.ex.ac.uk writes:
Now the puzzling stuff is people who appear to be arguing that MITM is unimportant
Hal said this same thing in a recent note. For myself, I've never meant to argue that the MITM threat is unimportant. I've simply contended that you're no more vulnerable to it in the key-as-True-Name scenario than with a certificate-bound key-to-name relationship system. If you assume an MITM could thwart the establishment of trust in the first case, then I guess I posit that the same energies could with equivalent hope for success be directed in an attack on a more "traditional" certificate scheme.
I disagree. The MITM is foiled by one successful communication. The reason for certificates is to isolate and limit the number of authentication transactions which are not automated. When you get your key certified you go through some sort of very-hard-to- subvert process. The exact process is irrelevant, as it merely affects the trustworthiness of the certifier. Let's assume for the sake of argument that the key is certified by the same organization (DMV/MVA/DPS/whatever) that issues drivers licences, and on the same identification criteria. When you have your key certified, you also get a copy of the KCA's key. You now have enough information to authenticate to roughly the same level as presentation of a state issued ID card. After the first transaction, you can accept any key *signed* by the KCA under the same circumstances you'd accept the id card. But you can get KCA signed keys from almost *anywhere*, without the overhead associated with that level of authentication. The expensive authentication happens once, followed by a nearly unlimited number of cheap ones.
Perhaps the view is based on the fact that there are plenty of situations where you don't care what an entities name is, and hence the attribute which should be under discussion is credit worthiness, or reliability, but still you need to protect against MITM, using whatever channels and means available. I don't see how this alters the argument.
And this is where I start to think we're all in agreement even though there's an argument going on! Yes, I think you need to protect against MITM attacks by whatever means are available. I think that no matter what you do, if you're strictly relying on communications systems over which you ultimately have no control (if at some point somebody you simply have to trust on faith inevitably gets his hands on your bits), then you have to put up with a non-zero probability of being victimized by a MITM attack. If you're willing on blind faith to trust certificates granted by some authority, you're fooling yourself (I claim). If you only trust that authority because it fits into an established web, then I don't see why there's any need for a certificate binding a public key to some "True Name" constant; what's the point? (How do you know the alleged True Name has any meaning in the first place?)
I also posit that this is not really any different than the problems of social interaction homo sapiens have been dealing with ever since they grunted their way into cooperative tribal life.
I think we're still "arguing past each other." One side seems to argue "people have keys, and we need a way to authenticate them". The other seems to argue "there are situations where we don't care about the people behind the keys." Both are correct. As I said before, authentication is the correlation of entities with whom you've communicated over different channels. The notion that "people have keys" sort of implies that you know something about the "people". This really means you've communicated with them out-of-band --- even if you've just heard about them, it's a few bits of information. When you finally communicate in-band, you need an authentication protocol to correlate the entity on the other end of the current channel with the entity you have in mind.