I've noticed a trend with the adoption of SSL/TLS that I'm not sure is really in the best long term interests of the community.
It seems that early on an "alternate port" strategy is/was adopted, such as having an SSL only version of POP on port 995, IMAP on 993, and SMTP on 465. These ports start p with an SSL session before any data is sent, so only SSL enabled clients are able to attach. (I will refer to this as the "alternate port strategy")
Then, as time has marched on, and the "STARTTLS" command was implimented, SSL/TLS has been integrated into the "primary port". So, now, SSL/TLS is handled on ports 110, 143, and 25 (respectively), with SSL/TLS being initiated (by the client sending the "STARTTLS" command) after the plain-text session has started. When this shows up in the RFC for extensions to the protocol, the alternate port method is usually then mentioned as "deprecated". (I will refer to this as the "STARTTLS strategy").
The problem with the STARTTLS strategy is: you can't guarantee at the network level that a client will use SSL/TLS. The service provider might be able to do that (ex: CommuniGate Pro, a mail server from stalker.com, has an option to require "secure logins", meaning that they must be happening within an SSL/TLS protected session), but the network provider cannot. In large organizations, or situations with outsourced services, those two groups may not be the same. This leads to a situation where a networking service may be trying to enforce a mandate of "secure protocols only", but cannot do so under the STARTTLS strategy.
This is our current issue at UCSC with the deployment of wireless access points. I, the email administrator, can't currently require "secure logins" because of some legacy issues. As dangerous as it may be, I can't disallow plain text sessions yet. Yet, the wireless group doesn't trust WEP (for good reasons), and has decided that wireless privacy must come from SSL/TLS enabled protocols ... so they're blocking the non-SSL/TLS ports. You can't get to POP via 110, IMAP via 143, nor SMTP via 25. If you want to check your email, you have to it via the Alternate Port strategy.
Personally, I'm quite happy with their agenda. But I have a concern: clients which are aiming at RFC compliance now see that the RFCs which cover them consider the Alternate Port strategy to be deprecated. So, we cannot depend upon current clients to "do the smart thing" and have the Alternate Port strategy available. Yet, the Alternate Port strategy is the only way to, at the network level, enforce SSL/TLS*. So, the Alternate Port strategy still has some very real, very lasting value. If the Alternate Port strategy were to be considered "current", then it might encourage authors to embrace both strategies (the best path).
(* Yes, someone could merely start a standard STARTTLS based server on ports 993, 995, etc. and circumvent the network agenda, but we're not so concerned about that type of blatant action, we're concerned with typical software in typical configurations being able to be pigeonholed into only having the option of entering in to SSL/TLS sessions.)
So, what I would like to see, as a general agenda for the RFC's is:
1) The Alternate Port strategy should no longer be deprecated for any protocol
2) Those services (such as the Message Submission Protocol) that were created with an assumed dependance upon STARTTLS should be extented to also have an Alternate Port for SSL/TLS only.
3) Standard Compliance (of the software) should depend upon implementing both strategies, not one or the other (but it would be acceptable if the systems administrator were to not activate both strategies, which is why I inserted "of the software").
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf