This is not an IETF problem, but a general problem with upgrading legacy services and software. Everyone has this same problem, and has to choose their own approach to the problem. You cannot move faster than your client software base. It means that you may have to either adjust your security policy to accomodate those legacy clients, or exclude legacy clients altogether. Some people must do the former. Some other people can do the latter. Since you are in a limited internal academic environment, you probably have more lattitude to specify that all of your users use a given set of software products that meets your security and software protocol goals. However, if for some reason this is unsuitable, then you have to adjust your security policy. Those are your choices. One thing: You should pay close attention to the fact that some of the protocols you have mentioned are experimental, and probably should not be used for production environments. --Dean On Sun, 9 May 2004, John Rudd wrote: > > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf