John: There is actually a list for discussion of this topic, ietf-apps-tls@xxxxxxx, 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf