Re: [TLS] consensus on backwards compatibility changes

Kurt Roeckx <kurt@roeckx.be> Mon, 26 January 2015 20:25 UTC

Return-Path: <kurt@roeckx.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66301A1B0C for <tls@ietfa.amsl.com>; Mon, 26 Jan 2015 12:25:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WZgfdZwptHk for <tls@ietfa.amsl.com>; Mon, 26 Jan 2015 12:25:24 -0800 (PST)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD3D1A1A8F for <tls@ietf.org>; Mon, 26 Jan 2015 12:25:24 -0800 (PST)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 4F43B1C213A; Mon, 26 Jan 2015 21:25:22 +0100 (CET)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 2BF601FE01D3; Mon, 26 Jan 2015 21:25:22 +0100 (CET)
Date: Mon, 26 Jan 2015 21:25:22 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150126202521.GA12484@roeckx.be>
References: <201412300503.03923.davemgarrett@gmail.com> <20150125200326.GA27020@roeckx.be> <201501251814.36985.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201501251814.36985.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/8Bh6qRG8TuwBXFzBWIVM8yq0ra4>
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] consensus on backwards compatibility changes
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 26 Jan 2015 20:25:28 -0000

On Sun, Jan 25, 2015 at 06:14:36PM -0500, Dave Garrett wrote:
> On Sunday, January 25, 2015 03:03:27 pm Kurt Roeckx wrote:
> > On Tue, Dec 30, 2014 at 05:03:03AM -0500, Dave Garrett wrote:
> > > PR #105 remove SSL 2 backwards compatibility section & prohibit SSL negotiation
> > > https://github.com/tlswg/tls13-spec/pull/105
> > 
> > Doesn't that "or accept" prevent the previous sentence?  And isn't
> > the rest already covered by the first sentence?
> 
> The SSL2 CLIENT-HELLO format can be used with TLS 1.0 (version {3,1}).

I think there is some misunderstanding of how an SSLv2 client
hello works, or I'm not understanding what you're trying to say.

In SSLv2 the bytes of the record header are:
0: record length MSB, & 0x7f (or & 0x3f)
1: record length LSB
<optional padding length>

And for the record data:
<optional mac data when encrypted>
0: message type (1, client hello)
1: highest supported version MSB
2: highest supported version LSB
[...]


Since SSLv3 this has changed.  It looks like:
0: record content type (22, handshake)
1: record protocol version major
2: record protocol version minor
3: record length msb
4: record length lsb

And then in the fragment you have:
0: handshake type (1, client hello)
1: handshake length MSB
2: handshake length
3: handshake length LSB
4: highest supported version major
5: highest supported version minor
[...]

I don't see how you're going to fit an SSLv2 client hello in an
SSLv3 or TLSv1 record.  Please note that for SSLv2 there is only 1
version field while with SSLv3 there are 2.

You could of course argue that there is no record protocol version
in SSLv2.

> > | Implementations MUST NOT send or accept any records with a version less than { 3, 0 }.
> 
> Nothing stating a version for SSL2 or any bogus versions below SSL3 are allowed.
> A v2 format hello with a TLS 1.0 version is unfortunately permitted.

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.


Kurt