Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>

[Marsh Ray <[e-mail]>]

On 12/10/2010 03:35 PM, Sean Turner wrote:
> On 12/3/10 3:27 PM, Sean Turner wrote:
>>
>> "negotiate" means returning a ServerHello handshake message with that
>> version number (neither an SSL 2.0 SERVER-HELLO, nor an SSLv3
>> ServerHello with a server version of { 0x02,0x00 }).
>>
>> "use" means to successfully complete the handshake and start exchanging
>> application data protected under protocol version {0x02,0x00}.

How could you ever "use" it without "negotiating" it first?
It seems like a distinction without a difference in this document.

> So it's been proposed that I better integrate the text after the bullets
> into the bullets and better explain negotiate and use. I'm game.
>
> For the client, all I've ever wanted to do is change the "TLS 1.2
> clients SHOULD NOT support SSL 2.0" to a MUST NOT.

Sounds good to me.

> For me, client
> support meant sending SSL 2.0 CLIENT-HELLO, accepting SSL 2.0
> SERVER-HELLO, and then proceeding using SSL 2.0 records. I can see that
> people might not make the leap that client support meant accepting the
> SSL 2.0 SERVER-HELLO and using SSL 2.0 records because the above-quoted
> sentence was in a warning that discussed 2.0 CLIENT-HELLOs.

 >RFC2246: TLS 1.0 clients that support SSL Version 2.0 servers
 >RFC2246: must send SSL Version 2.0 client hello messages [SSL2].

IMHO, this is statement on its own is ambiguous to the point of being 
wrong. The problem is that is muddies up the essential distinction:
The term "SSL Version 2.0" refers to a completely different thing
than an "SSLv2-format compatible Client Hello message".

But it is cleared up in subsequent wording:
 >RFC 2246: TLS servers should accept either client hello format if

This uses the word "format" to make that critical distinction.

RFC2246: they wish to support SSL 2.0 clients on the same
RFC2246: connection port. The only deviations from the Version 2.0
RFC2246: specification are the ability to specify a version with a
RFC2246: value of three and the support for more ciphering types
RFC2246: in the CipherSpec.

It's really imprecise to talk about a "Version 2.0 Client Hello" message 
because one of the primary purposes of the initial hello message 
exchange is to negotiate exactly which protocol will be used for all 
subsequent messages (i.e., the "protocol version").

The Client Hello, in effect, has its own protocol version which has 
evolved somewhat independently over the years:

SSLv2
SSLv2 with SCSV
SSLv3/TLS
SSLv3/TLS with SCSV
SSLv3/TLS with extensions

> For servers, my thinking has evolved. I'm now at the point where I'd
> like to have TLS servers not have to support SSL 2.0 SERVER-HELLOs and
> SSL 2.0 records after the handshake (RFC 5246 is clear that TLS
> 1.*/SSLv3 servers can accept a SSL 2.0 CLIENT-HELLO).

Isn't an "SSL 2.0 SERVER-HELLO" is equivalent to negotiating the use of 
the SSL 2.0 protocol? Isn't that the thing for which we're trying to put 
the final nail in the coffin?

> If we prohibited TLS client's sending SSL 2.0 CLIENT-HELLO and TLS
> servers sending SSL 2.0 SERVER-HELLO, then I'd be happy because clients
> won't send SSL 2.0, servers won't respond with SSL 2.0, and therefore
> clients won't end up agreeing to send SSL 2.0 records and the server
> won't have to do SSL 2.0 records.

Really all you have to do is prohibit the client from sending an 
SSLv2-compatible client hello.

It may not hurt to reiterate that this implies that the server will not 
be subsequently negotiating the use of SSL 2.0 either. But the client 
hello messages and the server hello messages have completely different 
considerations, so there's no point in trying to make the language 
symmetric.

> How the following replacement text for Section 3:
>
> Because of the deficiencies noted in the previous section:
>
> * TLS Clients MUST NOT propose SSL 2.0 to a TLS server by sending
> an initial SSL 2.0 CLIENT-HELLO handshake message with protocol
> version { 0x02, 0x00 }.

How about

"TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO 
message format. Clients MUST NOT send any client hello message which 
specifies a protocol version less than { 0x03, 0x00 }. As previously 
stated by the definitions of all previous versions of TLS, the client 
SHOULD specify the highest protocol version it supports."

> * According to [RFC5246] Appendix E.2, TLS Servers, even when not
> implementing SSL 2.0, MAY accept an initial SSL 2.0 CLIENT-HELLO
> as the first handshake message of a SSLv3 or TLS handshake.

"TLS servers MAY continue to accept client hello messages in the version 
2 client hello format as specified in TLS [RFC2246]. Note that this does 
not contradict the prohibition against actually negotiating the use of 
SSL 2.0."

> [RFC5246] allowed TLS servers to respond with a SSL 2.0
> SERVER-HELLO message.

I don't see where it says that explicitly.

I would have interpreted RFC5246 as being mostly irrelevant once each 
endpoint learns that the highest mutually-supported version was 
something less than TLS 1.2.

AFAICT, this is the first document in the SSL/TLS evolution that 
attempts to mandate behavior WRT earlier versions of the protocol.

> This is no longer allowed. That is, TLS
> Servers MUST NOT reply with a SSL 2.0 SERVER-HELLO with a protocol
> version of { 0x02, 0x00 } and instead MUST abort the connection,
> i.e., when the highest protocol version offered by the client is
> { 0x02, 0x00 } the TLS connection will be refused.

Would "is less than { 0x03, 0x00 }" be a better condition? Not that many 
clients are likely to send { 0x02, 0xFF }, but we might as well prohibit it.

- Marsh