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

Sean Turner <turners@ieca.com> Fri, 10 December 2010 21:34 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1486A3A6CC6 for <tls@core3.amsl.com>; Fri, 10 Dec 2010 13:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level:
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJj+wDaAOVUj for <tls@core3.amsl.com>; Fri, 10 Dec 2010 13:34:12 -0800 (PST)
Received: from nm26.bullet.mail.sp2.yahoo.com (nm26.bullet.mail.sp2.yahoo.com [98.139.91.96]) by core3.amsl.com (Postfix) with SMTP id A64123A6CC3 for <tls@ietf.org>; Fri, 10 Dec 2010 13:34:12 -0800 (PST)
Received: from [98.139.91.65] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000
Received: from [98.139.91.20] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000
Received: from [127.0.0.1] by omp1020.mail.sp2.yahoo.com with NNFMP; 10 Dec 2010 21:35:42 -0000
X-Yahoo-Newman-Id: 184977.91730.bm@omp1020.mail.sp2.yahoo.com
Received: (qmail 82061 invoked from network); 10 Dec 2010 21:35:42 -0000
Received: from thunderfish.local (turners@71.191.10.121 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 10 Dec 2010 13:35:40 -0800 PST
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: VaGs1dYVM1nTssJ3ATlpXecsuQbtf6t.IlnNmBl.y61c0BK ngQj8lobUPKiB1.gJQt.DBJi3KBQSfTBMGmcfBPvQQUVz_aLI3gvUBKz2f9J 5Sb948RHjtBTN9ipLBQHhmGppDekeI0oY3gcO1Y.9WkazA8moNRNN41iRCjQ v_VPNTUS8T6JwbZqYxvpZSU9MzRwbE1MViKt0sqNCPHPa1KvZ2tvMHMwYBnK xJfRTeOqAjJjW9vfr8C7HJzeZfqveZxmBnunXfuFJNtI.Bz5lTGqb4z8XdLH 34pr0YrMnAQAPjc0TZrMnyIHxDn5nzuAtGQ--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4D029D2B.9090900@ieca.com>
Date: Fri, 10 Dec 2010 16:35:39 -0500
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: tls@ietf.org, ietf@ietf.org
References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com>
In-Reply-To: <4CF952A2.2070904@ieca.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <gwz@net-zen.net>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Dec 2010 21:34:18 -0000

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