Re: [TLS] Version negotiation, take two

Hannes Tschofenig <> Fri, 09 September 2016 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F09DD12B236 for <>; Fri, 9 Sep 2016 07:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.109
X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F_Cprtl6OJkw for <>; Fri, 9 Sep 2016 07:07:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E68EF12B102 for <>; Fri, 9 Sep 2016 07:07:20 -0700 (PDT)
Received: from [] ([]) by (mrgmx002) with ESMTPSA (Nemesis) id 0MF4eJ-1bokFp0M7n-00GGJz; Fri, 09 Sep 2016 16:07:18 +0200
To: David Benjamin <>, "" <>
References: <>
From: Hannes Tschofenig <>
Message-ID: <>
Date: Fri, 09 Sep 2016 16:07:17 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:5SMS+o+sGdvRO9kKwYVo/3oLnXjmICeoFa0w04xbLXAgkf4rdYT tQeYTH0z+ANlCnTS19+n+COKKrRmrfONs6ufXWyLG3mi2WZefxNXHDtJtLEtjHTemyi/BiO vKqvwIIIO72wTOwcZ8/IwXyj2QVxT+0WsCYMUJAUy+6Ez8VaLYGfCoKTzujUGHv3NOgcsAc OySOFMYpokoS9zZlcHBJQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:QdAQSo+XYxI=:WjMYoXU92tFJ72AERr87E7 D19Ux7/GYqyAhtbj37beaVK6t/kQq3Oh2/ytlblxXSMAmlCskTgg45RGYsaAE2oEsdvXoJkI2 fGuh0ZFjcu+BwSIHepA8aRGA25/6KHw/hPfSB78a5Cr4axpEFvHpLFfiiLZafGFV3Sdw5sega nW0Rf5y4r2Vjo0SFoePm/anZ3ViJdloguSl+3ElMGylaDOKUxF9XDm8o8ZIugWFeDIO43iyx6 BsJIV0+i8g9/3pBeoWkLvyKo3PHQhcAhxAwnWjmIP9QZMVPJ6Gjco9GKEZeQ9BCUmKEyCQ5f9 x5WFmHBIAkuImQwWKF0cTTZnKpvU3dk+2Tk5HXB1CMVy5PDAfFkbNbmpI1O3XgbZYpjArILYt eoPPb3rRAP3XhYpBscUnQT4bZefjzeReSkexjFjg5bTABvujPCgYDNA3JNouG1AywO9JyDO8M zflH6ZTg+fGbhvQMufdG/LnnK+2OFAj4OI40A+KITY0Q3qF3cZbRtHK8V33MZEA9IjoqrKd8R 9LNGssCQOjSE+LvN8DpTG0yTn77Go/UhuGaGjq9EzjpG9+QOg66D12MfVX9XLkMHsGOGdliRC YgspnVfeI1m1HhxJD/OeCLmMtWiQCxE551frTVTp23VPvDJl003EM2mnYnPWQckCktweES5w1 LbHSlXrWe5Hv7n+79zUuur2EgEFSmsp2J9DROds+2VB5Bmv4VZmm7e7rhxRSzASQZkEvW1JMI PN7JfNqou/NSn/pJnI8VbjKUS2Az0J4BC5371foTDNLcB1yHDxzdSt6TSHNYpjZlsqYots13w voQLney
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, 09 Sep 2016 14:07:27 -0000

I like this approach.

On 09/08/2016 06:04 PM, David Benjamin wrote:
> Hi folks,
> I’d like to revisit the question of version negotiation.
> EKR wrote up some text for moving version negotiation to an extension:
> I would like us to adopt this proposal.
> In Berlin, this really got framed as a pragmatic question: the current
> version negotiation has a lot of intolerance and so let’s work around
> that. So, understandably, this seemed like a “let’s adopt a hack
> forever” proposal. I think that framing is wrong. The intolerance
> situation is serious, but I think there’s also a strong argument that
> the current scheme isn’t very good.
> The current scheme is very simple. The client advertises a maximum
> version and the server selects based on that. This is the only piece of
> TLS negotiation which works this way. Elsewhere (extensions, cipher
> suites, signature algorithms), one side offers a list and the other side
> picks out of it. I think it’s clear now that strategy is more robust:
> every time we’ve bumped version numbers, we’ve had intolerance problems
> and this time is no exception (see below). By contrast, we regularly
> introduce new cipher suites, extensions, etc., and while we do see the
> occasional failure, they are much rarer and typically within the level
> of breakage that clients can tolerate and deal with by reaching out to
> affected servers. Moreover, lists lend themselves to future-proofing via
> draft-davidben-tls-grease-00 in a way the current scheme does not.
> An additional benefit is lists make it much easier to roll out
> prototype/draft versions. Currently, we are using a hack where the
> client offers {3, 4} but also includes a draft version number in an
> extension. This does work, but requires servers process that extension
> in perpetuity or at least until all draft version clients go away.  With
> a list, it’s trivial to offer a draft version by just including it. This
> is the strategy HTTP/2 used (via ALPN) and it worked well.
> Despite all of the above, it probably wouldn’t be worth fixing version
> negotiation in 1.3 except for intolerance. Unfortunately, this fourth
> time, it’s the same story as before. A probe of Alexa top million sites
> with BoringSSL’s TLS 1.3 code (the Go version), shows 1.63% of
> TLS-capable hosts reject a TLS 1.3 ClientHello. Note these are top sites
> and traffic is top-heavy, so we can expect much higher usage-weighted
> numbers. Qualys SSL Pulse reports 3.6%:
> (Ignore the drop in the graph. We’ve long fixed the ClientHello
> record-layer at {3, 1}. TLS 1.3 only codified existing practice here.)
> If instead we use a TLS 1.3 ClientHello with version TLS 1.2, the
> breakage drops to 0.017%. (Some of this is an NSS signature algorithms
> bug, fixed last year, which we hope to clear by deploying RSA-PSS in
> browsers early. The rest appears to be noise from transient errors which
> crop up in large tests.)
> These numbers are *far* too high for clients to accept as damage, which
> means that they (at least browsers) will be forced to do fallback. This
> represents a security risk (cf. POODLE) as well as hides serious interop
> problems. The situation is even worse for non-browser clients, which may
> be unable to deploy at all (Ubuntu 12.04, despite shipping an OpenSSL
> release with TLS 1.2, had to disable it on the client.
> )
> The major arguments against this change seem to be:
> 1. It’s inelegant to have two mechanisms.
> 2. We should fix broken servers
> The first is true, but as with other changes, EKR’s PR replaces the 1.2
> mechanism with one for 1.3, so we’ll just have one going forward. The
> second would be nice, but as a practical matter, I spend a lot of time
> trying to get those servers fixed and it doesn’t work very well here.
> Better is simply to move to a situation where once those servers upgrade
> they will be correctly behaving forever (instead of just handling 1.3
> correctly and breaking with 1.4). This change does that.
> Thanks,
> David
> _______________________________________________
> TLS mailing list