Re: [TLS] Version negotiation, take two

Vlad Krasnov <> Fri, 16 September 2016 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6398012B2EC for <>; Fri, 16 Sep 2016 13:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 aLTWUN1Lv53u for <>; Fri, 16 Sep 2016 13:21:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16A4E12B016 for <>; Fri, 16 Sep 2016 13:21:11 -0700 (PDT)
Received: by with SMTP id 21so19670479pfy.0 for <>; Fri, 16 Sep 2016 13:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=doo+uLC3Ug9AssVDYa7LOvhiUyqchaKIVbibInb8SWU=; b=XRd8xZOctArI0daIFAG91lr+mMmZGgjsOA2djB3P5f3IOKjeEiTEnkgfPUSul/3LfS yVqke+iWO2ybcKFRmjkyRllo6+jYD5o01bNUvN5LqGFEAXNAE8lRQyFdWJ1CoTDl7unj GpMDoRCeAnt1Sr3R30AvUGUrt/f5w2zS3lF+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=doo+uLC3Ug9AssVDYa7LOvhiUyqchaKIVbibInb8SWU=; b=dWLSX444bS1ipph0ca5mVcK7kf3tctCMdICQ2+qLout9vyvUNyYjy3HnhCw5Q8+MLM JV03BxvdokYyVtUaT+OhrtZZqxbjjUmRk+i3pOAda7cr8W5HN60jEZhjXaV/iGkvdGKm txXdmhDKj/EWQV3ScjPMV8LdbOjCAeH06+/ZtbBCjP2JEvdesPmqluAK4nXxl3XwfODw 4ZDsmzL6PvoXYnx1knhlaO4x51SuLdnJiDLu8X/hwpcda6hEW+9ryTnehI/REaFxizwL 7v/xuTprAKKqHvlLiMxYDWFVqccjZjnBs7vqYPzL/NiZ3B8VzXduLv39E3X+OeOKrA9k N9IQ==
X-Gm-Message-State: AE9vXwNjsjt4uPgIj2s6K/CD70flAExVuYtuPkqq/0QpRyf0kInHL2umjp7GA8J6Es4+Mmyh
X-Received: by with SMTP id b8mr25656304pfc.122.1474057270638; Fri, 16 Sep 2016 13:21:10 -0700 (PDT)
Received: from ?IPv6:2606:4700:1000:8200:a914:4243:3cd9:677d? ([2606:4700:1000:8200:a914:4243:3cd9:677d]) by with ESMTPSA id n7sm54145293pfg.45.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Sep 2016 13:21:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Vlad Krasnov <>
In-Reply-To: <>
Date: Fri, 16 Sep 2016 13:21:09 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Hubert Kario <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
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: Fri, 16 Sep 2016 20:21:13 -0000

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 "negotiation"
>> 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