Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard

[Marsh Ray <[e-mail]>]

On 12/02/2010 08:01 AM, Glen Zorn wrote:
>
> Maybe I just don't understand the word "use".  It seems like if a
> server accepts a protocol message it's using the protocol...

Hard to argue with that logic...but... :-)

The Client Hello message is the first message sent in the protocol. Its
format changed completely from SSLv2 to what is used by SSLv3 thorough
TLS 1.2.

The number one job of the Hello messages (in any protocol) is generally 
to negotiate the version of the protocol used for all subsequent 
messages. Everything else in the Hello message is, in a sense, put there 
as an optimization to save some round trips.

Since the ancient v2 servers obviously couldn't understand one bit of a
v3 or later Client Hello (some would break quite badly), there was an 
option in the SSLv3 spec to lead off the handshake with a v2-compatible 
Client Hello. A direct transliteration of the v3 Client Hello message to 
a v2 was defined The only reason that worked was because the v3 Hello 
didn't introduce any significant new information (when it was first 
defined).

So it is, in fact, possible to use a SSLv2 Client Hello message with
later protocols, even if neither endpoint is willing to speak SSLv2 for
the actual connection. There is a significant percentage of handshakes 
today which lead off with a v2 Hello, even though the vast majority of 
servers support TLS 1.0.

The renegotiation problem required a means to signal at least one new
flag (roughly, "I'm patched") in the initial Hello message. This is
probably still fresh on everyone's minds, so the fact that a means was
found to signal this bit in the SSLv2-format Client Hello message still
feels relevant. If it had not been possible to squeeze that extra flag
in, the text we have been discussing would be much different.

On 12/01/2010 08:31 PM, Glen Zorn wrote:
> Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO
> messages." and "TLS servers MUST NOT negotiate or use SSL 2.0" and
> later "TLS servers that do not support SSL 2.0 MAY accept version
> 2.0 CLIENT-HELLO messages as the first message of a TLS handshake for
> interoperability with old clients." Taken together, I find these
> statements quite confusing, if not outright self-contradictory.

I don't see any problem with them. Sometimes the wording in RFCs reads a 
bit like a bullet-point list of standalone requirements that got 
formatted into a paragraph. I find this style to actually be quite 
comforting when you go to implement something. You can turn it into an 
implementation checklist with less chance that you might lose something 
written between the lines.

> Maybe, a "However" might fix the problem, though:
>
> TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers
> MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a
> TLS handshake in order to maintain interoperability with legacy
> clients.

I do like your wording better. But I don't think it's enough of a 
technical improvement to necessitate change during last call.

- Marsh