> 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.
Ned
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf