> > 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. > > Somebody check my math on this please, but it seems to me that the whole > STARTTLS approach is succeptible to a specific attack which the secure > socket model is not. A man-in-the-middle can just as easily (more easily, in fact, since it doesn't require datastream modification) send back a port-unreachable to the client's attempt to contact the foo-over-ssl port. It is true, as you imply, that if either the client or the server has a SSL/TLS-required policy, then a non-SSL/TLS connection won't get made. This policy can be configured into endpoints using STARTTLS if that's desired. If clients and servers both permit the use of cleartext reusable passwords to be negotiated, then a MITM will be able to force them into it in either case. At a theoretical level there isn't much difference between the two security-wise. Arguments about which is better in practice depend on assumptions about what implementors and deployers and users might or might not do. The underlying reason why the separate-port approach loses, though, is that it makes simplistic assumptions about the relationships between services on different ports. Do imap://example.com/ and imaps://example.com/ provide access to the same resource? There's no reason to believe that they do in the general case. The separate-port approach wires-in assumptions about "what's on a port" that are easily circumvented later, both by bad guys and good guys (as we tend toward a world where everything runs over port 80). - RL "Bob" _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf