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

[Sean Turner <[e-mail]>]

On 12/3/10 3:27 PM, Sean Turner wrote:
> On 12/3/10 2:58 PM, Martin Rex wrote:
>> Glen Zorn wrote:
>>>
>>> Martin Rex wrote:
>>>>
>>>> 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...
>>>>
>>>> With "negotiate" I meant 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 }).
>>>>
>>>> With "use" I meant to successfully complete the handshake and start
>>>> exchanging application data protected under protocol version
>>>> {0x02,0x00}.
>>>
>>> Maybe you could spell these things out in the draft just as you have
>>> above?
>>
>> I'm sorry, my explanations were misleading. I explained what I meant
>> when I wrote these statements that ended up in the document.
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg07091.html
>>
>> The author/editor of this I-D is Sean Turner.
>
> I've got no problem with providing additional clarifying text. How about
> we add the following (some minor tweaks to what you suggested) to
> explain what we mean by use and negotiate (send seems clear):
>
> "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}.

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

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

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.

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

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

   [RFC5246] allowed TLS servers to respond with a SSL 2.0
   SERVER-HELLO message.  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.

Note that the number of servers that support this above-mentioned "MAY 
accept" implementation option is declining, and the SSL 2.0 CLIENT-HELLO 
precludes the use of TLS protocol enhancements that require TLS 
extensions. TLS extensions can only be sent as part of an (Extended) 
ClientHello handshake message.

spt