Re: [TLS] Version negotiation, take two

Andrei Popov <> Fri, 16 September 2016 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D52A12B327 for <>; Fri, 16 Sep 2016 13:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, 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 bHpcPo0n6meF for <>; Fri, 16 Sep 2016 13:29:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1518B12B322 for <>; Fri, 16 Sep 2016 13:29:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ltT9LI6JJwh5HC0wCv3L2ikkP369GWLZdYbNhY9n1Q8=; b=FAj1aoH6R5vRV6uTtWIBHbNG/EOUIggjLXV0e+SD0nYsHcuiv+d8bCNDILaM4hh02pj7vzcwc3weYIReMUDeWAr778uREd2dmm0ouNwE6cjdtZoNSK1DeNRdcs8l7mVU+ETZgrMvQteGhtaM60mWYkdzJZKIuXnMT9npFfrTymk=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.629.8; Fri, 16 Sep 2016 20:29:45 +0000
Received: from ([]) by ([]) with mapi id 15.01.0629.006; Fri, 16 Sep 2016 20:29:45 +0000
From: Andrei Popov <>
To: Vlad Krasnov <>, Hubert Kario <>
Thread-Topic: [TLS] Version negotiation, take two
Date: Fri, 16 Sep 2016 20:29:45 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: 45a9bea4-37ea-489d-3683-08d3de7032c6
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:dpxX7qbeWWBNkb7HO+A0X8Hx4R6O3uF8tLMEFrl9fXZw3GS7JU4iBu6UoGMHhc6gOeTtC5g2nReYooVXwUCYIeQJ3LeOuLI4BQPqsWyR9K+QswpwBhj1czd0pgPcufBIMZ6kWnxst/s9Dw0zoxg1YoQycH/O26FnPMZnsBcYDwpiygAlHglQQmJKvaSiTyiuVJpgN4c6sa/hA7tBkpKh/IeNL9jrCNV3Kd212ipxEBt/uyCtk0JLcpeFmc77IV2kQiV2oSkrVZIFdlmqbiEbYLbrSrSuWPdeIt1eoZbi91HDxtju6AJgMbAprMjclo5z4GhMH/fKGbBqdXwlH8EowA==; 5:EGLaolBTfK3EfwhgLWu1IH4B8HT4qR09ZYgNmBwP3+KwYses6gLlxdn36YCU1+VSa6COQ4RGVBERHcLgUMOvqkWhqxBarNY/imDnjgdwH0F+xmKdHd1iGOSN/eKlzXsGs5NzdggOuePZ5t01lmvp9Q==; 24:4kw/E/1hMmPywvJa1KusHfYkCoDLXAIuGOHS/ZDiUsGcycVbiWHkT5mJFOx9KyrcqLmCl8llovwlmZqySDpPcs3lYQVQoHaqCwo9i+rSsms=; 7:8K+1s+SzZ7+4npRaNxauw1mKa/S+5n//fpwQsonfq4aRV2Ue2ca0iTflX1f6EpNFC/Au11DzZzr1ssapQy7r5ZiPO1xv/WN/772erDuvcXy/65MUk3+NFC+og//I4Tgds8co8MGCGTOByqZ+IHJo8tUB3UDPjyAVe6appuXtOBjxtsj0P/Oy/qLNJv03tbRd/IZbd4K3mIX9EjvzqdAFYLe2cYaNP6YI9YHSA//8jvP1xNwsh/T5JkNoQz07wH4i
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 0067A8BA2A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(24454002)(13464003)(19580395003)(102836003)(122556002)(68736007)(87936001)(5660300001)(86362001)(5001770100001)(10290500002)(93886004)(189998001)(8990500004)(97736004)(7846002)(10090500001)(6116002)(10400500002)(3660700001)(7736002)(5005710100001)(586003)(9686002)(74316002)(19580405001)(305945005)(15974865002)(3280700002)(7696004)(99286002)(76576001)(76176999)(54356999)(4326007)(2906002)(8676002)(81156014)(81166006)(92566002)(8936002)(33656002)(86612001)(50986999)(106356001)(11100500001)(106116001)(5002640100001)(2900100001)(77096005)(15975445007)(105586002)(2950100001)(101416001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2016 20:29:45.6634 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
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: Fri, 16 Sep 2016 20:29:50 -0000

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

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



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

TLS mailing list