Re: [TLS] Version negotiation, take two

David Benjamin <> Sat, 17 September 2016 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE08B12B0AC for <>; Fri, 16 Sep 2016 18:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jqyX6c-lo4h7 for <>; Fri, 16 Sep 2016 18:04:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAA5412B0A8 for <>; Fri, 16 Sep 2016 18:04:18 -0700 (PDT)
Received: by with SMTP id 186so29841129itf.0 for <>; Fri, 16 Sep 2016 18:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ij/ebPr59UTqW5VLoas3vXhTYw7iQviHx2vusEHprxo=; b=lpFoWGa8v2pnuLlhN8lZKjk4j7J83uLlEezj2jt+zt0oTkwLOvPuvO5dxLfKGiHHco ZYZUExky7DfsNcMoPgxlAT8ayjsRH3YFC7SlNhdQ6yd6yCzJ8xeD57zbiCprNeLTJbsW gCtSZR6HitGa4tsI6t9gyOr+CVmKPfbQACArI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ij/ebPr59UTqW5VLoas3vXhTYw7iQviHx2vusEHprxo=; b=DBIBOm9g2ApHafU5hpMhpmEzI3A7hNIDP1UrmxmhdCobAq9Q7/6SDkDIyVFOzLER8P ldoh7HZ1FbttEx2LImtUT2vreg+tpb6YGv2f8h7utaHweLzbAsW4/DrT2USlsx2BQz57 YmV8k+qyFNOSFfC8FLqcblvF/nShBTE4wd+/5Ux1h0IUxFO4QuxY6rPWDXnHeAcjXy8f 9o9jUOxhBAEhQwb2czV1/X69A8oM6d3T76Y7XuMfbtbxHxjMMkU2FKAfsKTMC4vMoeWE gGpBHBoOxN28B484T8StGxgoW7e5WmtrGRIs4JTgibO0yTfKBtXot6XH2kI0UV2gpElb 8+Fg==
X-Gm-Message-State: AE9vXwMN4/xSvZr+cVe/5latlAxdSIPEbP8gittq7kMwMm3fCvLZDFXsjfUPGKfB0RrvIhYz9KZd6fBUY8sX6lEA
X-Received: by with SMTP id b79mr167202itb.67.1474074257773; Fri, 16 Sep 2016 18:04:17 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Sat, 17 Sep 2016 01:04:07 +0000
Message-ID: <>
To: Andrei Popov <>, Vlad Krasnov <>, Hubert Kario <>
Content-Type: multipart/alternative; boundary=001a114409ac826110053ca9a832
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Version negotiation, take two
X-Mailman-Version: 2.1.17
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: Sat, 17 Sep 2016 01:04:22 -0000

On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov <>

> At the very least, if version is negotiated as extension it must be the
very first extension advertised.
I don't think it's a good idea to impose extension ordering requirements.

Agreed. If we're concerned with the order, I suppose are other options like
smuggling them in the front of the cipher list or hacky things like that.
:-) But using extensions is cleaner, and still perfectly deployable.

> Some implementations out there rely on the fact that they can read the
first two bytes of the client hello, and take the appropriate code path on
the spot.
Yes, these implementations (Windows TLS stack included) will need to do
more elaborate/slightly slower pre-parsing if we use TLS version
negotiation via TLS extension(s). Not something I like, but can be done.

TLS already does not strictly permit sniff-based implementations like this.
A handshake message may be fragmented pathologically or even interspersed
with warning alerts. It's doable if you reject such fragmentations (no one
would send a ClientHello this way...), but you need to be careful because
this fragmentation does not figure into the handshake transcript. In
particular, you cannot have an else clause in your dispatch. The dispatcher
must reject anything it can't definitively resolve rather than blindly
forward to your pre-TLS-1.3 implementation.

CVE-2014-3511 is an example of OpenSSL's 1.0.x sniff-based implementation
going wrong (OpenSSL 1.1.x is no longer sniff-based). It is a particularly
silly instance, but it's the sort of failure mode you can get.

Further, with the current trajectory, TLS 1.3 servers will need to do
version-negotiation based on extensions anyway. All the various
implementors have been using this "draft_version" extension to experiment
with TLS 1.3. (draft_version is really just a worse version of this

I don't think anyone has actually enabled client code by default yet, but
once anyone does, servers will need to process extensions for versioning
until draft TLS 1.3 clients are out of the ecosystem. This seems the worst
of both worlds. We'll have extensions in versioning and an undeployable
protocol. I think we should go for the latter and, if we must have the
former, at least do it properly.




-----Original Message-----
From: TLS [] On Behalf Of Vlad Krasnov
Sent: Friday, September 16, 2016 1:21 PM
To: Hubert Kario <>
Subject: Re: [TLS] Version negotiation, take two

I am opposed to this change.

I don’t think that version selection as an extension is such a good idea.

Some implementations out there rely on the fact that they can read the
first two bytes of the client hello, and take the appropriate code path on
the spot.

That allows for a very simple and stream-lined parsing of the hello, with
minimal buffering.

Also note that several fields *preceding* the extensions have special
values for TLS 1.3.

Delaying this decision until after all the extensions are parsed will make
implementations that much more complex, memory consuming, and slower (HOL
blocking), plus potentially leading to new bugs we want to avoid.

At the very least, if version is negotiated as extension it must be the
very first extension advertised.


> On 15 Sep 2016, at 11:03, Hubert Kario <> wrote:
> On Thursday, 15 September 2016 11:51:31 CEST Benjamin Kaduk wrote:
>> On 09/14/2016 02:02 PM, Andrei Popov wrote:
>>> Basically, I don't feel strongly about the switch to the proposed
>>> version negotiation mechanism. But if we are going to make this
>>> change based on the theory of having only one extension point and
>>> actively defending it, then we should probably follow the theory and
>>> send a separate TLS extension per TLS version.
>> To me, the (ordered) list of client supported versions in a single
>> extension feels more intuitively natural, so I want to try harder to
>> understand the reasoning that leads you to prefer a separate
>> extension for each version.  Is it just that doing an additional
>> within the extension body constitutes another extension point that we
>> would have to actively defend, or is there something else about what
>> a TLS extension is philosophically supposed to indicate?
> the extensions joint is well greased and works
> the lists inside extensions are a hit and miss, they mostly work, but
> then we have SNI in general, signature methods in past NSS versions,
> and if you dug more I wouldn't be surprised if you found half a dozen
> other issues just like it (in late October I may have actual numbers
> about it)
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web:
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
> Republic_______________________________________________
> TLS mailing list

TLS mailing list
TLS mailing list