Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard

Michael D'Errico <> Thu, 02 December 2010 05:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 354733A689B; Wed, 1 Dec 2010 21:00:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6T+5o1tQdTwG; Wed, 1 Dec 2010 21:00:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0DA9C3A6899; Wed, 1 Dec 2010 21:00:40 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id B75973F72; Thu, 2 Dec 2010 00:02:14 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=3Mxtlog5PtjX /9GQOi5V0/rBCAA=; b=r9xNuecF1k7zYSzIVr8YyC91bVDlmYXwM++qXaMlBLh4 j8hLHPPG4xxn2vQGdepc5mMrcXMC+Cq8QJc/JSE0oWafjjglMCJj27mvymUWZ8iD Fezw7jck32MedQY6U1PVOImYTiJTzihzfQzWd16HJZmf2jKveM04e2qIDPWoEng=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=sOGOkB fnAYCFJS8zZHQ7+1hMoHhibeR0xED2eqen667cmMINMIwKERhlYeo5ag15mTDdmV KXcCF2MDwnE6w2WWSPOpJ9rThxyvHhFh87rLnSLgEjyBP97vqzsf2J9LlKqh45Yq s7OioziBTcJabtxD5kyH/KgukvVrMPksaXsfk=
Received: from (unknown []) by (Postfix) with ESMTP id 595103F70; Thu, 2 Dec 2010 00:02:12 -0500 (EST)
Received: from iMac.local (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5FDA43F6D; Thu, 2 Dec 2010 00:02:09 -0500 (EST)
Message-ID: <>
Date: Wed, 01 Dec 2010 21:01:48 -0800
From: Michael D'Errico <>
User-Agent: Thunderbird (Macintosh/20090302)
MIME-Version: 1.0
To: Glen Zorn <>
References: <20101201135503.20212.98672.idtracker@localhost> <002a01cb91c8$ff8f4fe0$feadefa0$@net>
In-Reply-To: <002a01cb91c8$ff8f4fe0$feadefa0$@net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 52C88B62-FDD1-11DF-8898-CDEAE6EC64FC-38729857!
Subject: Re: [TLS] Last Call: <draft-ietf-tls-ssl2-must-not-03.txt> (Prohibiting SSL Version 2.0) to Proposed Standard
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Dec 2010 05:00:43 -0000

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


There is no contradiction among the statements, but they may be confusing (I
can't tell anymore since I've gone through the drafts several times).  The
idea is that:

   - no TLS client should ever negotiate SSL 2.0; therefore there is never
     a need for it to send an SSL 2.0 CLIENT-HELLO

   - servers, however, need to interoperate with older software that might
     send an SSL 2.0 CLIENT-HELLO even though it supports SSLv3 or later,
     so it's OK for them to accept that message as long as the resulting
     version is not SSL 2.0.

The reason it is OK to accept CLIENT-HELLO is because it can carry the SCSV
cipher suite value used to plug the renegotiation security hole (RFC 5746).