[...]
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.
I agree that such servers are broken. But clients may want to
tolerate them anyway, and it is easy for TLS-only servers to tolerate
clients tolerating such broken servers.
Servers can tolerate such clients if they wish. But clients that send
anything other than a TLS 1.0 Hello message shouldn't expect to
interoperate with servers that assert STARTTLS. The way the TLS
protocol is designed, the burden is on the client to send an appropriately
formatted Hello message.
The TLS protocol includes provisions for protocol version negotiation.
Yes, I understand. It's the SSL 2.0 Hello messages that I'm concerned
about, not SSL 3.0 Hello messages with a maximum version # >= 3.1.
And yes, this is really a bug in the TLS spec, and maybe that's where
it should be fixed.
But given that SMTP STARTTLS has *never* supported anything less than
TLS 1.0 I have a difficult time understanding why SMTP client authors
thought it was acceptable to send SSL 2.0 Hello messages. Maybe they just
blindly linked in SSL libraries without telling them what protocol
version to use?
I think it's quite reasonable to document the fact that lots of SMTP
clients have been shipped that send out SSL 2.0 Hello messages, and
that servers might want to support these messages (you could even
say RECOMMENDED) in addition to TLS 1.0 messages. But in the future,
clients should send TLS 1.0 Hello messages.
does it matter? the current specification defines rules such that if you
follow them, you should be able to interoperate. what you're proposing
to do is to change the rules so that servers that followed the old
spec, might not interoperate with clients that follow the new spec.
This is true, but I seriously doubt that there are any servers that
would have such problems.
I have limited faith in a WG's ability to enumerate all existing
implementations, and I don't like the WG deciding that broken
implementations are more deserving of compatibility with future
versions of the standard, than ones that followed the original spec.
As I said before, essentially all existing
STARTTLS clients are 'broken' in the sense that they use backwards
compatible Client Hello messages; so STARTTLS servers not supporting
backwards compatible Client Hello messages wouldn't be able to survive
in the wild.
:-)
not necessarily true - it just means that people wouldn't use the
STARTTLS feature of the client.
Keith