Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
Clients MAY use backwards compatible SSL Client Hello message
formats. However, except for SSL session resumption, Client
Hello messages MUST be suitable for negotiating TLS 1.0 or later
(i.e. the version field of SSL 2.0 compatible Client Hello
messages or the client_version field of SSL 3.0 compatible Client
Hello messages must be at least 3.1).
Servers MUST be able to understand backwards compatible SSL
Client Hello messages, provided that the client indicates that
it supports TLS 1.0 or later.
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.
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.
Similarly, clients that issue a STARTTLS command and don't
send TLS 1.0 Hello messages are also BROKEN, full stop.
Can you name an existing SMTP client with STARTTLS support that is not
'broken' by your definition?
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.
That's not something that should be done lightly.
if you can define a set of rules by which old and new clients can
interoperate with old and new servers, without compromising security,
I would find that acceptable. but I actually think it's more
important to allow implementations *that followed the spec*
to continue to interoperate, as it is to allow implementations that
failed to follow the spec to interoperate. (unless of course there
was a fundamental bug in the spec, which doesn't seem to be the case here.)
If a server wants to accept older Hello messages, that's its own
business.
This is not about 'older' Client Hello messages, this is about
backwards compatible Client Hello messages -- old format, but new
content.
yes, I understand the distinction.
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.
A backwards compatible Client Hello message does not mean that the
connection actually uses the older protocol. (And anyway, client
authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)
hmmm. I thought TLS 1.0 had fixed a few of these.
(but it's been a while since I analyzed it in detail, and that was
quite painful enough.)
But client implementations shouldn't
expect that sending older Hello messages are going to make them
interoperable with servers that advertise STARTTLS.
They cannot expect interoperability if they support only SSL 3.0 or
even SSL 2.0, but that's not what this is about. No-one requires
servers to support SSL 3.0 or SSL 2.0; all that is required is support
for backwards compatible Client Hello handshake messages so that it is
possible for clients to tolerate SSL-only servers if they feel like
it. Backwards compatible Client Hello messages are described in the
TLS RFC.
I think the problem is that you're adding a new requirement that would
keep conforming older servers (that did not recognize old format hello
messages) from interoperating with new clients.
Keith