Re: [TLS] consensus on backwards compatibility changes

Dave Garrett <> Mon, 26 January 2015 23:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 732A01A0079 for <>; Mon, 26 Jan 2015 15:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CgMPNYWw6BdZ for <>; Mon, 26 Jan 2015 15:31:40 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18E301A0067 for <>; Mon, 26 Jan 2015 15:31:40 -0800 (PST)
Received: by with SMTP id w8so9182434qac.13 for <>; Mon, 26 Jan 2015 15:31:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=k2RyXZynlBGonA5zEg1h6UKyBgstoGZu9JuabMwtFGQ=; b=HR2z4pzynfq8A98JUV8eicQDPhEwz8NFXyC83KmFaIZ0hMf7nbpkdQGjDL/w00etN9 xo28HS1oTXhShLYPXGLLJls3tGjsao+Tl7yu/pdNa0gddpDcq5/1YEnxIwSNaMe8YCmo bt+y7MDXVcXtgOcBXR8x3aj/Qg1dbnxi1V8ROPqTiZyPAhrqzo5mtU9hE63OZN/YZNpH UZrBUDTerDjXuVnhx6vVGxFNoe/8DFRj1+X/SCxtmCv8vc/W/MPqoiQhnCK1q7wdXPHY CPk0wJH2d16YFhhjrlARteg2oW3vxsiRqj9r6EUcxJCjqEoH7rWcHhUXMip6d2AAdv0k qmZw==
X-Received: by with SMTP id 78mr1928533qgo.93.1422315099359; Mon, 26 Jan 2015 15:31:39 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 50sm7007930qgj.12.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Jan 2015 15:31:38 -0800 (PST)
From: Dave Garrett <>
To: Kurt Roeckx <>
Date: Mon, 26 Jan 2015 18:31:36 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-70-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Cc: " (" <>
Subject: Re: [TLS] consensus on backwards compatibility changes
X-Mailman-Version: 2.1.15
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: Mon, 26 Jan 2015 23:31:41 -0000

On Monday, January 26, 2015 03:25:22 pm Kurt Roeckx wrote:
> I don't see how you're going to fit an SSLv2 client hello in an
> SSLv3 or TLSv1 record.

You don't. Please see the TLS 1.2 spec, RFC 5246 E.2. The deprecated
format is specified and instructed to be sent "directly on the wire, not
wrapped as a TLS record".

These changes are in direct reference to that existing spec.

> So you're saying that things that implement TLS 1.3 MUST NOT
> support negiotating SSLv2?  If that it what you mean, please say
> that instead.

| Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO.

The first sentence is sufficient to prohibit negotiating SSL2 entirely. I've also cited RFC 6176.
If you think this needs yet more, I guess I could stick a "and must not be negotiated"
onto the two lines citing RFC/I-D prohibitions, if you think it needs to be more clear. I have
nothing against adding redundancy here.

With regard to this topic, please see the previous discussion on list. (the "drop obsolete
SSL 2 backwards compatibility" thread) Implementers have specifically pushed back against
dropping all SSL 2 stuff, in particular because they think it is valid to still negotiate TLS 1.2
using an SSL version 2.0 client hello. I can understand why you'd have trouble
understanding this; I do too. :/

I'd much rather have an even simpler SSL backwards compatibility section with the sum
of the text being "NO", but there is not yet consensus on this.