Re: [TLS] Version negotiation, take two

Xiaoyin Liu <xiaoyin.l@outlook.com> Thu, 08 September 2016 20:04 UTC

Return-Path: <xiaoyin.l@outlook.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 937A012B240 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 13:04:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.72
X-Spam-Level:
X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 aLVnUFmPZB44 for <tls@ietfa.amsl.com>; Thu, 8 Sep 2016 13:04:38 -0700 (PDT)
Received: from SNT004-OMC1S15.hotmail.com (snt004-omc1s15.hotmail.com [65.55.90.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B51CE12B22A for <tls@ietf.org>; Thu, 8 Sep 2016 13:04:38 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com ([65.55.90.9]) by SNT004-OMC1S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 8 Sep 2016 13:04:37 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pXX7rdAPb1VIpc9aRWHSS2dm4G1bdk4ziEzTLKZ/DJw=; b=gL5RoHCx8ijsFKJ+tDnZCzkBPnTr09ZxsgZLp63AybARqjrWfpeCoCpXveolfkejGdMRLK4fPNG4S/O/AzDuFQvVFpHzh3btZBrZsKPvgm1TdVt22I+xb1JWjWVlg6278Z9qD9zrm6W0RHXd3e1UiW1fH1GRN2lWRcFevqc4UcqFYt6b5lhiYJN+mHlT+G9R836Wv+Rx2FMB3qrpokor6yP60Rhh3mFz6rLgOBCK8NZmTRrIxXYFU5v0yq/Bs1by3qp1Xc5mLSsQjx6PkVxje7osCcTAff/FpHF9TgcKQlIZgIPSBOGlw8SitTTbQYUMotnMQWWEtHf3qGNgtLzUdg==
Received: from BY2NAM01FT042.eop-nam01.prod.protection.outlook.com (10.152.68.57) by BY2NAM01HT141.eop-nam01.prod.protection.outlook.com (10.152.68.69) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Thu, 8 Sep 2016 20:04:37 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.68.51) by BY2NAM01FT042.mail.protection.outlook.com (10.152.68.172) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Thu, 8 Sep 2016 20:04:35 +0000
Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0609.016; Thu, 8 Sep 2016 20:04:34 +0000
From: Xiaoyin Liu <xiaoyin.l@outlook.com>
To: David Benjamin <davidben@chromium.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Version negotiation, take two
Thread-Index: AQHSCetRKkDbmwL9ck2Ry98tgh3e2aBwBJdu
Date: Thu, 8 Sep 2016 20:04:34 +0000
Message-ID: <CY1PR15MB0778E26BA17F328FA82F3EFEFFFB0@CY1PR15MB0778.namprd15.prod.outlook.com>
References: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
In-Reply-To: <CAF8qwaA86yytg29QOD_N7ARimh9QcNGU_nnr_OrxqCrvrk2MBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=softfail (sender IP is 10.152.68.51) smtp.mailfrom=outlook.com; chromium.org; dkim=none (message not signed) header.d=none;chromium.org; dmarc=fail action=none header.from=outlook.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning outlook.com discourages use of 10.152.68.51 as permitted sender)
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [9ytPcLO9dEUeG7og8maFzx92qypJuQ7P]
x-eopattributedmessage: 0
x-forefront-antispam-report: CIP:10.152.68.51; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2NAM01HT141; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en;
x-microsoft-exchange-diagnostics: 1; BY2NAM01HT141; 6:LYSkhpV+YQamBHEmQdy9Ko3t/G4qYDPF3+IHn45DBbaRhDDcTdvuGy//oGyr8oWx4N2Rw15E1FGjkdaxDUqz870sIjm6xZeiyFcQ8t2mS41CRErDJStLgMrJzJVVuYQRuzKLO2QvPPCTw2Y5VKP7xvvQLt3kP9DeKL2qMKVUfCUJcIkhP3bIPAFJ1eUnN6Obo7UHVfsNomILRV1lVvWtBw7/WbZelqXYys5jAH7N2KsqrLkNELZOsEcNuf5i0xLLVBbNcQh+6d9X9oD/d3KofKAYt8nY1gAu8bU4N78zjzP5sd839NVSx7gKCCkZCcnS; 5:7UYFOhLAjjQJ5p3P9raE45RTi8XFFveLjtmcA/vFFoJwVFzj5u/zQ/E4dqoaQtmXeRizTIIVaSqK9RrDpPBnq6PxE4iIitRCu88j+C9xSX36tEWT0MkJJ6Nc7Hirhvqv0l5ggD7oUhWUCe/vnPwt+A==; 24:qksluHuVTIEUp+kFjGowudzkhxqRVYLvdIk2RrvlHdQuJmt/2I6RTl21RiLbbZPSQyZfQGOe53rT51xU2++Wyr0s6Nxlff6oTFV/pjlA/C0=; 7:+nt4cxhK6QniSlb32HioIETZ+jOAWB3xZtOggxXpnPFKJRkkuc/Rfx0xeyRs8kQVC8bEl0X2AARVfOMestSTe+w2lePNgnEjOobPwZMXYrxDrR28ZtDIyC4fN2e5LZoZ3Gb43Y1dwSOkyvr17f/dQNqKmIYSAXvXQQueBSZAvJgpz042KPsMtieAUwN6VbCP2xZAiNIjHAcnO9n3R6QoJnetk95nlNBJrGxlo4IRbGJ9JXnLq/E+KUAyZXfilgvu
x-ms-office365-filtering-correlation-id: fcb976b3-310e-4f18-c2a9-08d3d8235ae2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1603103081)(1601125047); SRVR:BY2NAM01HT141;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BY2NAM01HT141; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT141;
x-forefront-prvs: 00594E8DBA
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778E26BA17F328FA82F3EFEFFFB0CY1PR15MB0778namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2016 20:04:34.9012 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT141
X-OriginalArrivalTime: 08 Sep 2016 20:04:37.0981 (UTC) FILETIME=[3A3828D0:01D20A0C]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/03cReHfjHvVYhYzm13qeGRC_VGs>
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: Thu, 08 Sep 2016 20:04:40 -0000

I support this proposal.

Xiaoyin

From: David Benjamin<mailto:davidben@chromium.org>
Sent: Thursday, September 8, 2016 12:09 PM
To: tls@ietf.org<mailto:tls@ietf.org>
Subject: [TLS] Version negotiation, take two

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

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

(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 )

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