Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard
Marsh Ray <marsh@extendedsubset.com> Thu, 02 December 2010 18:10 UTC
Return-Path: <marsh@extendedsubset.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D59E28C13C; Thu, 2 Dec 2010 10:10:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599]
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 VNjn-cCCDNP6; Thu, 2 Dec 2010 10:10:04 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0C97A28C136; Thu, 2 Dec 2010 10:10:03 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1PODcl-000Mx4-Gb; Thu, 02 Dec 2010 18:11:19 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CE2A96018; Thu, 2 Dec 2010 18:11:17 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+oA6UNnysfvu8Ex31KMuOfqFH26eFeCps=
Message-ID: <4CF7E145.8050209@extendedsubset.com>
Date: Thu, 02 Dec 2010 12:11:17 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard
References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net> <4CF7283C.2030905@pobox.com> <000001cb9229$6a09e960$3e1dbc20$@net>
In-Reply-To: <000001cb9229$6a09e960$3e1dbc20$@net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 02 Dec 2010 13:56:28 -0800
Cc: 'Michael D'Errico' <mike-list@pobox.com>, ietf@ietf.org, tls@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Dec 2010 18:10:11 -0000
On 12/02/2010 08:01 AM, 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... Hard to argue with that logic...but... :-) The Client Hello message is the first message sent in the protocol. Its format changed completely from SSLv2 to what is used by SSLv3 thorough TLS 1.2. The number one job of the Hello messages (in any protocol) is generally to negotiate the version of the protocol used for all subsequent messages. Everything else in the Hello message is, in a sense, put there as an optimization to save some round trips. Since the ancient v2 servers obviously couldn't understand one bit of a v3 or later Client Hello (some would break quite badly), there was an option in the SSLv3 spec to lead off the handshake with a v2-compatible Client Hello. A direct transliteration of the v3 Client Hello message to a v2 was defined The only reason that worked was because the v3 Hello didn't introduce any significant new information (when it was first defined). So it is, in fact, possible to use a SSLv2 Client Hello message with later protocols, even if neither endpoint is willing to speak SSLv2 for the actual connection. There is a significant percentage of handshakes today which lead off with a v2 Hello, even though the vast majority of servers support TLS 1.0. The renegotiation problem required a means to signal at least one new flag (roughly, "I'm patched") in the initial Hello message. This is probably still fresh on everyone's minds, so the fact that a means was found to signal this bit in the SSLv2-format Client Hello message still feels relevant. If it had not been possible to squeeze that extra flag in, the text we have been discussing would be much different. On 12/01/2010 08:31 PM, Glen Zorn wrote: > Section 3 says "TLS clients MUST NOT send SSL 2.0 CLIENT-HELLO > messages." and "TLS servers MUST NOT negotiate or use SSL 2.0" and > later "TLS servers that do not support SSL 2.0 MAY accept version > 2.0 CLIENT-HELLO messages as the first message of a TLS handshake for > interoperability with old clients." Taken together, I find these > statements quite confusing, if not outright self-contradictory. I don't see any problem with them. Sometimes the wording in RFCs reads a bit like a bullet-point list of standalone requirements that got formatted into a paragraph. I find this style to actually be quite comforting when you go to implement something. You can turn it into an implementation checklist with less chance that you might lose something written between the lines. > Maybe, a "However" might fix the problem, though: > > TLS servers MUST NOT negotiate or use SSL 2.0; however, TLS servers > MAY accept SSL 2.0 CLIENT-HELLO messages as the first message of a > TLS handshake in order to maintain interoperability with legacy > clients. I do like your wording better. But I don't think it's enough of a technical improvement to necessitate change during last call. - Marsh
- RE: Last Call: <draft-ietf-tls-ssl2-must-not-03.t… Glen Zorn
- RE: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Glen Zorn
- Re: Last Call: <draft-ietf-tls-ssl2-must-not-03.t… Joe Salowey
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Martin Rex
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Michael D'Errico
- 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: Last Call: <draft-ietf-tls-ssl2-must-not-03.t… 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… Glen Zorn
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Marsh Ray
- Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-no… Sean Turner