Not sure if this is the right place for this

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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf