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

"Glen Zorn" <gwz@net-zen.net> Sat, 11 December 2010 03:32 UTC

Return-Path: <gwz@net-zen.net>
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 71D173A6CD0 for <tls@core3.amsl.com>; Fri, 10 Dec 2010 19:32:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level:
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 U6m2hcSg0hVR for <tls@core3.amsl.com>; Fri, 10 Dec 2010 19:32:54 -0800 (PST)
Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id D0AF83A6C0C for <tls@ietf.org>; Fri, 10 Dec 2010 19:32:53 -0800 (PST)
Received: (qmail 25649 invoked from network); 11 Dec 2010 03:34:25 -0000
Received: from unknown (124.122.184.73) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 11 Dec 2010 03:34:24 -0000
From: Glen Zorn <gwz@net-zen.net>
To: 'Sean Turner' <turners@ieca.com>
References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> <4D029D2B.9090900@ieca.com>
In-Reply-To: <4D029D2B.9090900@ieca.com>
Date: Sat, 11 Dec 2010 10:34:04 +0700
Organization: Network Zen
Message-ID: <000601cb98e4$453ca980$cfb5fc80$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcuYsjKOzaswq6UsQFqLxJ8pj+jS4AAMf1VQ
Content-Language: en-us
Cc: tls@ietf.org, ietf@ietf.org
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: Sat, 11 Dec 2010 03:32:56 -0000

Looks good to me.

Hope this helps.

 ~gwz

> -----Original Message-----
> From: Sean Turner [mailto:turners@ieca.com]
> Sent: Saturday, December 11, 2010 4:36 AM
> To: tls@ietf.org; ietf@ietf.org
> Cc: mrex@sap.com; Glen Zorn
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
> 
> 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