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

[Sean Turner <[e-mail]>]

On 12/10/10 6:09 PM, Marsh Ray wrote:
> 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."

I don't have objections to this.

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

I'd only add a pointer to the specific place in 5246, which somebody 
else asked for.

>> [RFC5246] allowed TLS servers to respond with a SSL 2.0
>> SERVER-HELLO message.
>
> I don't see where it says that explicitly.

5246 does not say this explicitly, or at least I couldn't find it 
either.  I definitely inferred that it was allowed.

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

It would line up better with the change to the 1st bullet.

spt