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