Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
One very important thing to note is that clients on Microsoft's rather
popular OS family (as much as I loathe it personally) will *not* use TLS 1.0
at all, by default.
then they shouldn't claim to conform to the SMTP STARTTLS RFC, and
they shouldn't try to negotiate STARTTLS with a server.
if they can call Microsoft's library with non-default settings that
cause the library to use TLS, fine. if not, they can supply their
own library - because the Microsoft one doesn't allow them to conform
to the standards.
we didn't write a specification for SMTP over TLS so that people could
pretend to support it and actually support something weaker. there
are reasons that TLS was approved for standards track and SSLv3 wasn't.
Hmm... I think this rather overstates the case. SSLv3 has no
known cryptographic weaknesses that TLS does not. The cryptographic
changes made to TLS are more "tightening-up" than anything.
There are three primary cryptographic changes between SSLv3 and
(1) The key derivation function is different (it uses an
HMAC-derived PRF rather than the rather ad hoc MD5(SHA())
(2) The MAC is replaced with HMAC. The original MAC was
a variant of an earlier version of HMAC.
(3) The Finished message computation is slightly different and
None of these changes are particularly significant. No good
attacks are known against the old versions of the functions.
At best, these changes might protect against some hypothetical