Re: [TLS] Version negotiation, take two
Benjamin Kaduk <bkaduk@akamai.com> Tue, 13 September 2016 16:23 UTC
Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D112B453 for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 09:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level:
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 dVQia5cDYTXm for <tls@ietfa.amsl.com>; Tue, 13 Sep 2016 09:23:40 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5C54512B44F for <tls@ietf.org>; Tue, 13 Sep 2016 09:07:35 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6CAE6433412; Tue, 13 Sep 2016 16:07:34 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 56390433411; Tue, 13 Sep 2016 16:07:34 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1473782854; bh=C7Fp9HDjCc4ROnRc1fTTyjc1Fzx+Dd0bu6IR0X8tgb8=; l=12668; h=To:References:From:Date:In-Reply-To:From; b=qjnOCP3WRxa/e+lXuhLow3OlLUtqeo72e96/4LQkpJTwpsyhKF5zTKSlcWamBVcxh ea06lkU5hWPXL0UQySqKQ/40Q6saZcY5Za1U+VTQHH+wSbY0JbjhxNuDGV++xWTRFU v5To0W1HhDEZvW3HUnmWp4zX9mOOAqcRhAb3oz5k=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 195941FC86; Tue, 13 Sep 2016 16:07:34 +0000 (GMT)
To: David Benjamin <davidben@chromium.org>, "tls@ietf.org" <tls@ietf.org>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <ef4bb2e7-2077-58a8-6819-01a7495837f9@akamai.com>
Date: Tue, 13 Sep 2016 11:07:33 -0500
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: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4A9E539F7ACFAC536ABB60F1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_9ekNWI-TiOP-_mj3hhvKWW6WJc>
Subject: Re: [TLS] Version negotiation, take two
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Tue, 13 Sep 2016 16:23:43 -0000
This is the best proposal I've seen given the deployment constraints imposed by reality. Perhaps it could be tweaked to improve it slightly, but I support merging this version. -Ben On 09/08/2016 11:04 AM, 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: > https://github.com/tlswg/tls13-spec/pull/632 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_632&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=1euqoGMgrdBFwR2KiZey_Du1pzwHcBTJJgTNL0Ynvo0&e=> > > 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%: > https://blog.qualys.com/ssllabs/2016/08/02/tls-version-intolerance-in-ssl-pulse > <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.qualys.com_ssllabs_2016_08_02_tls-2Dversion-2Dintolerance-2Din-2Dssl-2Dpulse&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=6ziW12EZ1iGkM2bN_6ooRy7CV9SPp0CVFv4hX7bpYSw&e=> > > (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. > https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/comments/4 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.launchpad.net_ubuntu_-2Bsource_openssl_-2Bbug_1256576_comments_4&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=aarB3I3r_Kn7FPWJq9AJd1ivPK1niUnkupGujPoRKpk&s=tBAuUGE2Q0PBvobD02Z-2PhxBDD1DP7dGKm1M6YxIQM&e=> > ) > > 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [TLS] Version negotiation, take two David Benjamin
- Re: [TLS] Version negotiation, take two Short, Todd
- Re: [TLS] Version negotiation, take two Xiaoyin Liu
- Re: [TLS] Version negotiation, take two Hannes Tschofenig
- Re: [TLS] Version negotiation, take two Benjamin Kaduk
- Re: [TLS] Version negotiation, take two Kyle Rose
- Re: [TLS] Version negotiation, take two Sean Turner
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Benjamin Kaduk
- Re: [TLS] Version negotiation, take two David Benjamin
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two Salz, Rich
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Benjamin Kaduk
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two Vlad Krasnov
- Re: [TLS] Version negotiation, take two Andrei Popov
- Re: [TLS] Version negotiation, take two David Benjamin
- Re: [TLS] Version negotiation, take two Hubert Kario
- Re: [TLS] Version negotiation, take two Vlad Krasnov
- Re: [TLS] Version negotiation, take two Joseph Salowey