John:
There is actually a list for discussion of this topic,
ietf-apps-tls(_at_)imc(_dot_)org, though it hasn't seen much traffic for quite a
while.
Your note is a reminder that this issue, while much-debated on the various
apps-protocol lists a few years ago when the decisions to invent and
promote STARTTLS were made, is not well-described (so far as I know) in
any RFC. An informational (or maybe BCP) RFC presenting the reasons why
the separate-port approach is a poor choice, and promoting some good
practices for clients and servers using STARTTLS, would be a good thing
(he said, not quite volunteering).
In a nutshell, the reason STARTTLS is a better approach is that, rather
than treating the use of SSL/TLS as entirely different than other session
characteristics, it permits the use of TLS to be negotiated by client and
server, just as other protocol features are negotiated. The most
important practical benefit of this is that clients can be designed with
their default behavior to try STARTTLS (perhaps based on a server's
announcing it as a capability), thus giving the generic user the benefits
of TLS-protected connections without having to configure anything. With
the separate-port approach, the user (in any client I have ever seen) has
to configure the use of the separate port, which in many deployment
scenarios means it doesn't get used at all (since every required obscure
user config step is another $NN of support cost). (There are lots of
other reasons I won't go into now since I'm up too late already.)
Promoting long-term the use of both STARTTLS and separate ports is also a
bad thing, since having two ways to do the same thing is guaranteed to be
confusing, and security stuff is already confusing enough.
Unfortunately, the separate-port meme has been drilled into people's heads
very effectively by http/https, so it's likely that clients will support
it for a long time to come, but there is no way that this will be anything
other than legacy-compatibility behavior (ie, it won't be specified in
standards RFCs).
Your network administrators are well-meaning, I'm sure, but their policy
is just foolish. They might reflect on the fact that there are lots of
non-TLS ways to avoid reusable-passwords-in-the-clear with common app
implementations (on the plain old port), including Kerberos, CRAM-MD5,
DIGEST, SRP, and others. They might reflect on the fact that filtering
out ports just makes people send their traffic over the ports that remain
open, which almost universally includes port 80. So a "secure ports only"
policy has very little to do with security and very much to do with
organizational power relationships, and making your computing environment
dysfunctional. Try a "secure servers only" initiative. It worked much
better for us at my university.
- RL "Bob"
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf