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