Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard

Keith Moore <[email protected]> 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
TLS:
(1) The key derivation function is different (it uses an
HMAC-derived PRF rather than the rather ad hoc MD5(SHA())
nesting.
(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
is truncated.

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
future attack.

-Ekr