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

[Michael D'Errico <[e-mail]>]

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

Glen,

There is no contradiction among the statements, but they may be confusing (I
can't tell anymore since I've gone through the drafts several times).  The
idea is that:

   - no TLS client should ever negotiate SSL 2.0; therefore there is never
     a need for it to send an SSL 2.0 CLIENT-HELLO

   - servers, however, need to interoperate with older software that might
     send an SSL 2.0 CLIENT-HELLO even though it supports SSLv3 or later,
     so it's OK for them to accept that message as long as the resulting
     version is not SSL 2.0.

The reason it is OK to accept CLIENT-HELLO is because it can carry the SCSV
cipher suite value used to plug the renegotiation security hole (RFC 5746).

Mike