Re: [TLS] Enforcing Protocol Invariants

Yuhong Bao <yuhongbao_386@hotmail.com> Wed, 13 June 2018 03:50 UTC

Return-Path: <yuhongbao_386@hotmail.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 CFAC1130DD8 for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 20:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.876
X-Spam-Level:
X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 EhCC2lJCYnVB for <tls@ietfa.amsl.com>; Tue, 12 Jun 2018 20:50:24 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05olkn080e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::80e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735F1130DD2 for <tls@ietf.org>; Tue, 12 Jun 2018 20:50:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s9XcbKH3oXmcX3v6F3dHwdjkz79iTuZNzDSlkP6SCLQ=; b=oa91c+qBibobf3lcmN9ojgXYz9Z8BC8tQr8yIOAmbZAs3VJglisoCdKjfQ/txnU2s7BHte7n7JWv0f3c7Yu1CcMhuiVJNbuD+dKy/+Nki3Uhj/+9WsDL/cImr7rV9jHP7hvTqaQum5wxQhANUhRIUc0KC3ebGnKZmDh+1c6eMc/mRiFjz5BiE2QYDwziWC2hBFzjmObC05Vz5AMWKno5I/pbXISVH8C/DzGRmUwxcFyhbXplhMCnalBwk9PjjtqFhqMmXwZGF44mdH9X7Nn2ymOFGmegHEfJ0d17rWJUUZIuW0e+lo4HhbBpUftHIT84vau7D2dm+He2mwcCjsUDeA==
Received: from DM3NAM05FT019.eop-nam05.prod.protection.outlook.com (10.152.98.52) by DM3NAM05HT112.eop-nam05.prod.protection.outlook.com (10.152.99.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.863.7; Wed, 13 Jun 2018 03:50:22 +0000
Received: from MWHPR18MB1086.namprd18.prod.outlook.com (10.152.98.51) by DM3NAM05FT019.mail.protection.outlook.com (10.152.98.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.863.7 via Frontend Transport; Wed, 13 Jun 2018 03:50:22 +0000
Received: from MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::c38:703:b4b5:be64]) by MWHPR18MB1086.namprd18.prod.outlook.com ([fe80::c38:703:b4b5:be64%8]) with mapi id 15.20.0841.021; Wed, 13 Jun 2018 03:50:22 +0000
From: Yuhong Bao <yuhongbao_386@hotmail.com>
To: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Enforcing Protocol Invariants
Thread-Index: AQHUAmpiGRv5NErB2Uyku/LX/tlnAaRdjnTJ
Date: Wed, 13 Jun 2018 03:50:22 +0000
Message-ID: <MWHPR18MB108627ADE461F848BD2C5B5FC37E0@MWHPR18MB1086.namprd18.prod.outlook.com>
References: <CAF8qwaBfG2aQTMCTQ9=8Uj1yRB7PRAaZNeNQnTPtvboxfAh6HQ@mail.gmail.com>
In-Reply-To: <CAF8qwaBfG2aQTMCTQ9=8Uj1yRB7PRAaZNeNQnTPtvboxfAh6HQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:D4EE84961E6F2C7C151FF12F9A748D3D1DF86ED959483D7AB69B27F41B66819A; UpperCasedChecksum:AB884BA96B8789FD8EFB488EC112E84D74A6839CBA0C38D84151735124F3FCBD; SizeAsReceived:7179; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [vi4KrCcQkePkJgXRqgqYqEPz8fZPp7iOJ9EVAQBxxCH9tpBq6VwvlbDYtyLHqxYr]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM3NAM05HT112; 7:ewAOAv8VlV8A9U99ilda44b+m3x+qYWK1NOXmAFVHs2IBp8yVdMEAAkLRF9ArxXutMYmJNdOL6Kxk9ZVPVBEd9YK80lxUK4lftdgDgEUOSwoj647MHwjhCE5PIAOkrGyG+WJVMFPG+w33MJs0OiZieKtTXIfMu+aYUtWXEgA78DRIEAzT+3G815ghiDyWQpSZ39Gpe5w8tfHOHec0JClciV6YQofZb9KAYR5E8tcFUF4MUjZemnba3hO10LLz6Zt
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:DM3NAM05HT112;
x-ms-traffictypediagnostic: DM3NAM05HT112:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:DM3NAM05HT112; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM05HT112;
x-forefront-prvs: 07025866F6
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(53754006)(6436002)(110136005)(106356001)(87572001)(104016004)(76176011)(7696005)(105586002)(9686003)(25786009)(83332001)(6306002)(55016002)(99286004)(5660300001)(2900100001)(14454004)(97736004)(82202002)(81156014)(33656002)(8936002)(8676002)(229853002)(20460500001)(74316002)(6506007)(68736007)(6246003)(305945005)(73972006)(3280700002)(3660700001)(11346002)(5250100002)(6346003)(486006)(86362001)(476003)(53546011)(446003)(59450400001)(102836004)(46003)(15852004)(491001); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM05HT112; H:MWHPR18MB1086.namprd18.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:;
received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=yuhongbao_386@hotmail.com;
x-microsoft-antispam-message-info: v8nKQ2NRf+OSy6SefJm4DjXUw/Lc/BgbYHcfApreTPyG43sdxx4SzdQ+XW781o9P15pYuNbUDBt1PIp0SXOY51gg/thMG+SfYdflS4jWX/wqoK7c3sDy0C6j/LlShe1YxjUXr58wa/fgFL9SJsR+Mfn+IFFpFgwE/UC23TWy7shszfmDkMOYjiMhDewHgiI2
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: bdf02e0b-4d7b-41aa-27c3-08d5d0e0ca4e
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd
X-MS-Exchange-CrossTenant-Network-Message-Id: bdf02e0b-4d7b-41aa-27c3-08d5d0e0ca4e
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 074d7d4d-72e2-4a0a-9d89-73b16535e4cd
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2018 03:50:22.7695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM05HT112
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9HfTTiXBQXc6hCeUrP_QsYBXLrA>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 13 Jun 2018 03:50:28 -0000

Personally, I understood when the ClientHello was changed to deal with TLS version intolerant servers, but disliked the middlebox changes in the ServerHello.

________________________________________
From: TLS <tls-bounces@ietf.org> on behalf of David Benjamin <davidben@chromium.org>
Sent: Tuesday, June 12, 2018 9:27:39 AM
To: <tls@ietf.org>
Subject: [TLS] Enforcing Protocol Invariants

Hi all,

Now that TLS 1.3 is about done, perhaps it is time to reflect on the ossification problems.

TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet we had problems. Widespread non-compliant servers broke on the TLS 1.3 ClientHello, so versioning moved to supported_versions. Widespread non-compliant middleboxes attempted to parse someone else’s ServerHellos, so the protocol was further hacked to weave through their many defects.

I think I can speak for the working group that we do not want to repeat this adventure again. In general, I think the response to ossification is two-fold:

1. It’s already happened, so how do we progress today?
2. How do we avoid more of this tomorrow?

The workarounds only answer the first question. For the second, TLS 1.3 has a section which spells out a few protocol invariants<https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.3>. It is all corollaries of existing TLS specification text, but hopefully documenting it explicitly will help. But experience has shown specification text is only necessary, not sufficient.

For extensibility problems in servers, we have GREASE<https://tools.ietf.org/html/draft-ietf-tls-grease-01>. This enforces the key rule in ClientHello processing: ignore unrecognized parameters. GREASE enforces this by filling the ecosystem with them. TLS 1.3’s middlebox woes were different. The key rule is: if you did not produce a ClientHello, you cannot assume that you can parse the response. Analogously, we should fill the ecosystem with such responses. We have an idea, but it is more involved than GREASE, so we are very interested in the TLS community’s feedback.

In short, we plan to regularly mint new TLS versions (and likely other sensitive parameters such as extensions), roughly every six weeks matching Chrome’s release cycle. Chrome, Google servers, and any other deployment that wishes to participate, would support two (or more) versions of TLS 1.3: the standard stable 0x0304, and a rolling alternate version. Every six weeks, we would randomly pick a new code point. These versions will otherwise be identical to TLS 1.3, save maybe minor details to separate keys and exercise allowed syntax changes. The goal is to pave the way for future versions of TLS by simulating them (“draft negative one”).

Of course, this scheme has some risk. It grabs code points everywhere. Code points are plentiful, but we do sometimes have collisions (e.g. 26 and 40). The entire point is to serve and maintain TLS’s extensibility, so we certainly do not wish to hamper it! Thus we have some safeguards in mind:

* We will document every code point we use and what it refers to. (If the volume is fine, we can email them to the list each time.) New allocations can always avoid the lost numbers. At a rate of one every 6 weeks, it will take over 7,000 years to exhaust everything.

* We will avoid picking numbers that the IETF is likely to allocate, to reduce the chance of collision. Rolling versions will not start with 0x03, rolling cipher suites or extensions will not be contiguous with existing blocks, etc.

* BoringSSL will not enable this by default. We will only enable it where we can shut it back off. On our servers, we of course regularly deploy changes. Chrome is also regularly updated and, moreover, we will gate it on our server-controlled field trials<https://textslashplain.com/2017/10/18/chrome-field-trials/> mechanism. We hope that, in practice, only the last several code points will be in use at a time.

* Our clients would only support the most recent set of rolling parameters, and our servers the last handful. As each value will be short-lived, the ecosystem is unlikely to rely on them as de facto standards. Conversely, like other extensions, implementations without them will still interoperate fine. We would never offer a rolling parameter without the corresponding stable one.

* If this ultimately does not work, we can stop at any time and only have wasted a small portion of code points.

* Finally, if the working group is open to it, these values could be summarized in regular documents to reserve them, so that they are ultimately reflected in the registries. A new document every six weeks is probably impractical, but we can batch them up.

We are interested in the community’s feedback on this proposal—anyone who might participate, better safeguards, or thoughts on the mechanism as a whole. We hope it will help the working group evolve its protocols more smoothly in the future.

David