Note that neither clients nor servers are required to actually
support protocol versions other than TLS 1.0; but the above rules
make sure that clients can operate in a backwards-compatible mode
without risking interoperability with servers following the
current specifications.
This is completely bogus. The reason we have a TLS specification
is so people can get interoperability by implementing it. If they
instead implement some earlier specification that isn't TLS, they're
not meeting the requirements of the standard. SMTP servers that claim
to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN,
full stop. Similarly, clients that issue a STARTTLS command and don't
send TLS 1.0 Hello messages are also BROKEN, full stop.
Sigh. It is my understanding that there's a fair amount of SSL out there
masquerading as TLS. And using SSL is certainly better than using nothing.
Nevertheless, I think Keith is right. We have to take the long view. We cannot
cannot afford to be wishy-washy about this, much as short-term pragmatism would
say otherwise.
If a server wants to accept older Hello messages, that's its own
business. And servers would do well to parse older Hello messages
and continue with the TLS dialog even if they don't accept the
resulting client authentication as valid and don't treat the
negotiated session as if it were secure - just because it makes
for better error recovery. But client implementations shouldn't
expect that sending older Hello messages are going to make them
interoperable with servers that advertise STARTTLS.
Exactly. We're not precluding nonstandard behavior, but we're also not
condoning it.
An SMTP client can partially protect against these attacks by
recording the fact that a particular SMTP server offers TLS during
one session and generating an alarm if it does not appear in the
EHLO response for a later session. The lack of TLS during a session
SHOULD NOT result in the bouncing of email, although it could result
in delayed processing.
it seems quite reasonable to explicitly configure a client to insist
on the server supporting TLS, and refusing to send a message to the
server if it doesn't advertise STARTTLS. this also seems safer than
the "automatic discovery" mechanism above.
This was discussed at length during the first round on this document,
and the consensus was to use the words that are here.
This is also bogus. People need to be able to change server configurations,
or switch from one server to another, without it causing bounced mail.
Experimenting with TLS on an SMTP server (and turning it off later)
should not cause subsequent mail for that SMTP server to bounce.
At one point I toyed with the idea of a SASL mechanism based on a
Diffie-Hellman exchange. Clients and servers would remember the credentials
established from past exchanges and use them to mitigate man in the middle
attacks.
I gave up on this idea for precisely the reason Keith cites: Our SMTP
infrastucture is just too variable for such a scheme to work in wide
deployment. There will be too many times when retained information will be at
odds with infrastructure shifts and messages will fail to transfer.
Ned