ietf
[Top] [All Lists]

Re: Not sure if this is the right place for this

2004-05-11 08:15:51
At 2:18 AM -0500 5/11/04, Eric A. Hall wrote:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf