> 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.
Another argument in favor of separate ports is an implementation issue: It is
fairly common in large scale deployments to have specialized hardware to
perform SSL/TLS stuff, and that hardware often is not resident on the same
machines that offer POP/SMTP/IMAP services. This means that proxy that delves a
bit into the underlying protocol is needed to do STARTTLS. Unfortunately
proxies are in practice responsible for far more bugs you'd expect and the
proxy has to dig into the protocol the worse things get. Separate ports, on the
other hand, are much easier to implement on a front end.
The counter argument to this is the separation of the SSL/TLS layer from the
protocol layer is actually a bad thing security-wise. More specifically, when
it is done as a separate layer information about the SSL/TLS negotiation tends
to remain at that layer. Not making this information available to the
application protocol makes implementation of some security schemes, including
but not limited to SASL external, problematic.
So, while STARTTLS is in some senses more complex, it is useful complexity.
IMO this counterargument is fairly compelling. Add in the other issues that
come up with separate ports (RL Bob" Morgan has already summarized them nicely
so I see no reason to repeat them here) leads me to conclude that STARTTLS is
the way to go.
Ietf mailing list