Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt>
Sean Turner <turners@ieca.com> Mon, 13 December 2010 19:44 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 9295828C123 for <tls@core3.amsl.com>; Mon, 13 Dec 2010 11:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.519
X-Spam-Level:
X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.079, 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 zpt1Gr+N4YD0 for <tls@core3.amsl.com>; Mon, 13 Dec 2010 11:44:02 -0800 (PST)
Received: from nm12.bullet.mail.sp2.yahoo.com (nm12.bullet.mail.sp2.yahoo.com [98.139.91.82]) by core3.amsl.com (Postfix) with SMTP id 75CB728C0EB for <tls@ietf.org>; Mon, 13 Dec 2010 11:44:02 -0800 (PST)
Received: from [98.139.91.69] by nm12.bullet.mail.sp2.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000
Received: from [98.139.91.35] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000
Received: from [127.0.0.1] by omp1035.mail.sp2.yahoo.com with NNFMP; 13 Dec 2010 19:45:38 -0000
X-Yahoo-Newman-Id: 298331.1145.bm@omp1035.mail.sp2.yahoo.com
Received: (qmail 71627 invoked from network); 13 Dec 2010 19:45:37 -0000
Received: from thunderfish.local (turners@96.241.0.81 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 13 Dec 2010 11:45:37 -0800 PST
X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ
X-YMail-OSG: 0GY8xAgVM1lj2tp5K8BiPYAVSWBgzCMlt3fONclSXIFeZrU Nx4_ziBt9Xbgp7m86pNOJd.ClRXTHNUZUADm0tqdT4ull3ieC.a.YRvrOo3a w3mgTJZSGOKXukEhhXKwXXYFP4Ya1D6VbCKzB4yok_NRMffg7RT9JqVC6D.M HDtu6FsCHX9Gkl1jwOE4Ik12RCIdOkWZuL7Jx7CuC3y8e4Gh8bAsKuDP8NtX bkXaWGmnnrpn3Z.LJTbkHsfXt9BGwdDrdbAoKwPayeXgM.UBkqIUesfnxOO3 NXwNNK.OMMekP7Ew4KviCl5F6gaQxG4qKM8hQVCT90XgpiEEA7IaheCLimIe DLCSXlCdhBkf95eFjTykdGeFtqfqbso.oBLVByJ1_g4c-
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4D0677E0.4010009@ieca.com>
Date: Mon, 13 Dec 2010 14:45:36 -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: Marsh Ray <marsh@extendedsubset.com>
References: <201012031958.oB3JweOg015633@fs4113.wdf.sap.corp> <4CF952A2.2070904@ieca.com> <4D029D2B.9090900@ieca.com> <4D02B31D.8010906@extendedsubset.com>
In-Reply-To: <4D02B31D.8010906@extendedsubset.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Glen Zorn <gwz@net-zen.net>, 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: Mon, 13 Dec 2010 19:44:03 -0000
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
- [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03… The IESG
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Michael D'Errico
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Matt McCutchen
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Michael D'Errico
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Matt McCutchen
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Michael D'Errico
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Nikos Mavrogiannopoulos
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Marsh Ray
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Joe Salowey
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Sean Turner
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Marsh Ray
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Sean Turner