Ian Grigg <[EMAIL PROTECTED]> writes: > Nobody doubts that it can occur, and that it *can* > occur in practice. It is whether it *does* occur > that is where the problem lies. > > The question is one of costs and benefits - how much > should we spend to defend against this attack? How > much do we save if we do defend?
I have to find I find this argument very odd. You argue that TLS defends against man in the middle attacks, but that we do not observe man in the middle attacks, so why do we need the defense? Well, we don't observe the attacks much because they are hard to undertake. Make them easy and I am sure they would happen frequently. Protocols subject to such attacks are frequently subjected to them, and there are whole suites of tools you can download to help you in intercepting traffic to facilitate them. You argue that we have to make a "cost/benefit analysis", but we're talking about computer algorithms where the "cost" is miniscule if it is measurable at all. Why should we use a second-best practice when a best practice is in reality no more expensive? It is one thing to argue that a bridge does not need another million dollars worth of steel, but who can rationally argue that we should use different, less secure algorithms when there is no obvious benefit, either in computation, in development costs or in license fees (since TLS is after all free of any such fees), and the alternatives are less secure? In such a light, a cost/benefit analysis leads inexorably to "Use TLS -- second best saves nothing and might cost a lot in lower security". Some of your arguments seem to come down to "there wasn't enough thought given to the threat model." That might have been true when the SSL/TLS process began, but a bunch of fairly smart people worked on it, and we've ended up with a pretty solid protocol that is at worst more secure than you might absolutely need but which covers the threat model in most of the cases in which it might be used. You've yet to argue that the threat model is insufficiently secure -- only that it might be more than one needs -- so what is the harm? Honestly the only really good argument against TLS I can think of is that if one wants to use something like SSH keying instead of X.509 keying the detailed protocol doesn't support it very well, but the protocol can be trivially adapted to do what one wants and the underlying security model is almost exactly what one wants in a majority of cases. Such an adaptation might be a fine idea, but it can be done without giving up any of the fine analysis that went into TLS. Actually, there is one other argument against TLS -- it does not protect underlying TCP signaling the way that IPSec does. However, given where it sits in the stack, you can't fault it for that. > I think the failure of client certs has the same > root cause as the failure of SSL/TLS to branch > beyond its "mandated" role of "protecting e- > commerce." Literally, the requirement that > the cert be supplied (signed) by a third party > killed it dead. If there had been a button on > every browser that said "generate self-signed > client cert now" then the whole world would be > using them. This is not a failure of TLS. This is a failure of the browsers and web servers. There is no reason browsers couldn't do exactly that, tomorrow, and that sites couldn't operate on an SSH "accept only what you saw the first time" model. TLS is fully capable of supporting that. If you want to argue against X.509, that might be a fine and quite reasonable argument. I would happily argue against lots of X.509 myself. However, X.509 is not TLS, and TLS's properties are not those of X.509. -- Perry E. Metzger [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]