I'm not even sure they are similar arguments. I mean, the argument against SSL is that *if* an SSL connection is blocked, and *if* an alternative clear channel exists, and *if* that channel accepts clear-text logins, and *if* the client fallsback through all of that, then the session will be exposed. I'll grant that it's easy enough to interfere with somebody establishing a session, and that there's a measurable percentage of services that maintain clear channel alternatives, and that PLAIN/LOGIN are still the only things that work everywhere, and that there are probably clients which fallback invisibly. I can also argue some of those points to some degree -- that people who have setup SSL versions are likely to have eliminated access to the clear channel, for example -- so instead of any of those things being certainties, we should agree that this is a question of overlapping probabilities.
Not only can you argue that, it is the default setting for most SSL-using applications today (other than web browsers). As we were discussing this years ago, most application developers thought that this arrangement is exactly what the users wanted.
On the other hand, STARTTLS *requires* a clear channel that the client MUST *already* be using. So whereas the attack on SSL *might* succeed in putting the client in touch with an unencrypted service, TLS is *guaranteed* to be using such a service already anyway. The only question is whether or not a decipherable login can be used, which is a probability mask that also applies to the SSL scenario.
Exactly right. This is the strongest argument in favor of protected ports over STARTTLS.
Given the collection of probabilities, therefore, starting with an SSL channel and refusing connections to a backup clear channel eliminates most of the probability from the MitM attack model.
Right. And this is rejected by most people as unreasonable for the application users, unfortunately. What we are battling here is not how to do the protocols securely, but how to get the users to use the applications securely. If they say "if I can't get a secure connection I still want to communicate", all our lovely design is lost.
I don't think it really matters given the other problems (see below).
Fully agree.
--Paul Hoffman, Director --VPN Consortium
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf