Re: [TLS] ALPN with 0-RTT Data

Kyle Nekritz <knekritz@fb.com> Wed, 12 October 2016 21:07 UTC

Return-Path: <prvs=9093a824df=knekritz@fb.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 62DF3129684 for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 14:07:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
X-Spam-Status: No, score=-0.731 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=FhYTp2X2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kxZjUNGn
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 UZ13d5EC-L3E for <tls@ietfa.amsl.com>; Wed, 12 Oct 2016 14:07:13 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13444129656 for <tls@ietf.org>; Wed, 12 Oct 2016 14:07:13 -0700 (PDT)
Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.17/8.16.0.17) with SMTP id u9CL6Qak017272; Wed, 12 Oct 2016 14:07:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=if3YYR/S2gbJGbZXx29aDxW7Hbnjs6n8leS4bINk+Jk=; b=FhYTp2X2CdlcjXKhPFqHyKqBfpawpmxvMrT9BgTX+RHvK8Oale9MMb2wvVVCIVPQOImW thFjXCDok9EUh7qAUEANMdVoSrlKZOJRU0TVApFvt8l7PV/l9tKYRgkWktFHl8Wiy3a9 m9+SKNugAs5vvkgJjnibrR1F3cgn8OjASkU=
Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2615d3fa3u-13 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Oct 2016 14:07:10 -0700
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 12 Oct 2016 14:06:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=if3YYR/S2gbJGbZXx29aDxW7Hbnjs6n8leS4bINk+Jk=; b=kxZjUNGnfircXmbNGJ2aP3Gj+C5fUk6QGe3QBZ5mwpGs3DFrca5mISn0KVjjm4zElFXkicKuPSBIGjEcnF2x0YchWVEy+XZ7tKBDLE1ywpuXHznPMX1yOxSuB+RQRAiMn/a3Eq+A6udD8OJlUERtVkkZ3d7dJ1cU7ONHfKn1zAI=
Received: from MWHPR15MB1182.namprd15.prod.outlook.com (10.175.2.136) by MWHPR15MB1181.namprd15.prod.outlook.com (10.175.2.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Wed, 12 Oct 2016 21:06:00 +0000
Received: from MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) by MWHPR15MB1182.namprd15.prod.outlook.com ([10.175.2.136]) with mapi id 15.01.0659.020; Wed, 12 Oct 2016 21:06:00 +0000
From: Kyle Nekritz <knekritz@fb.com>
To: Eric Rescorla <ekr@rtfm.com>, David Benjamin <davidben@chromium.org>
Thread-Topic: [TLS] ALPN with 0-RTT Data
Thread-Index: AdIkwNG9QrjHsFtFQbqjMnydw22iRwAAqeUAAAAMq4AAAGmTkA==
Date: Wed, 12 Oct 2016 21:05:59 +0000
Message-ID: <MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0@MWHPR15MB1182.namprd15.prod.outlook.com>
References: <MWHPR15MB118283AEF96DAD58FD3F6FF3AFDD0@MWHPR15MB1182.namprd15.prod.outlook.com> <CAF8qwaAj=Dzs+DBoTVkFTCLz07HhtgmGp7YjsmzZx6BBSU+Zmw@mail.gmail.com> <CABcZeBPaMMv23W9sqggcnhQKEy9QAYPDpgUH-naji_fVTHZ=+g@mail.gmail.com>
In-Reply-To: <CABcZeBPaMMv23W9sqggcnhQKEy9QAYPDpgUH-naji_fVTHZ=+g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2620:10d:c091:200::5:ba78]
x-ms-office365-filtering-correlation-id: cd436ed0-1589-42bb-b9eb-08d3f2e39169
x-microsoft-exchange-diagnostics: 1; MWHPR15MB1181; 20:5RGjTFGn2svQZGplJ7YbfWFx3ntJyx+XzzUXSEXseeiryjkQfpV6HFbPd9/xCLfRI293jrFzdhYYw0euS+Yx2uSCfAuxbHQ5wT1l5x0WqzCc/IoLiN7eiyIt7XpNtFvf0SWCpSowIWLQblRz4ZKnTFu8X0nJU6Ul7PGOcc24NZw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR15MB1181;
x-microsoft-antispam-prvs: <MWHPR15MB1181B584A79DDB446D80130FAFDD0@MWHPR15MB1181.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(67672495146484)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:MWHPR15MB1181; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1181;
x-forefront-prvs: 0093C80C01
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(189002)(377454003)(11100500001)(106356001)(7696004)(5660300001)(2900100001)(76576001)(101416001)(7736002)(10400500002)(19609705001)(87936001)(105586002)(2906002)(81166006)(81156014)(189998001)(77096005)(33656002)(122556002)(7846002)(99286002)(7906003)(74316002)(4326007)(68736007)(15975445007)(19617315012)(3280700002)(76176999)(2950100002)(3660700001)(19580395003)(5001770100001)(16236675004)(54356999)(19300405004)(5002640100001)(50986999)(92566002)(586003)(790700001)(6116002)(19625215002)(97736004)(19580405001)(86362001)(9686002)(8676002)(102836003)(8936002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1181; H:MWHPR15MB1182.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1182EB64501B697B7B4E3D4FAFDD0MWHPR15MB1182namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2016 21:05:59.8783 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1181
X-OriginatorOrg: fb.com
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-12_11:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/BBvqF649FgLgyt3AYrvrOmmglG4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ALPN with 0-RTT Data
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: Wed, 12 Oct 2016 21:07:15 -0000

Reordering the ALPN offer has a couple advantages:
* It explicitly defines the protocol that the 0-RTT data is using on that connection. Without this, both the client and the server must independently store the ALPN in use (of course the server can put it in the ticket). While this should work if implemented properly, there is nothing in the protocol that enforces they match before the server accepts the data. If the client ALPN offer does happen to change, it’s even possible for the selected ALPN to be one that the client didn’t even offer.
* If the client knows out-of-band (or learns over the application protocol) that the server supports multiple protocols, it will not be able to use its current connection to start up a 0-RTT connection over the new protocol.
* I think realistically for many clients the protocol used to send 0-RTT data will end up being the only protocol that can be used on that connection, even if 0-RTT is rejected. Rejected 0-RTT data can’t be resent 1-RTT if a different application protocol is used, and it’s difficult API-wise to tell the higher layer “Your http/2 early data failed, but you can send http/1.1 requests if you want”. Thus it makes sense for these clients to advertise the 0-RTT data’s application protocol as the most preferred.

I’m not sure how this makes protocol transitions awkward. I’d still expect clients to choose the application protocol that was previously negotiated, so preferring h3 wouldn’t cause all h2 0-RTT to go away.

Kyle

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Wednesday, October 12, 2016 4:03 PM
To: David Benjamin <davidben@chromium.org>
Cc: Kyle Nekritz <knekritz@fb.com>; tls@ietf.org
Subject: Re: [TLS] ALPN with 0-RTT Data



On Wed, Oct 12, 2016 at 1:01 PM, David Benjamin <davidben@chromium.org<mailto:davidben@chromium.org>> wrote:
My interpretation was:

1. Client and server remember the previous selected ALPN protocol in the session.

2. The client may offer whatever ALPN protocols it likes. It does not need to match the previous offer list, though it presumably will unless you've got a persistent session cache or so.

3. The client assumes that session's ALPN protocol was selected for purposes of minting 0-RTT data.

4. The server must decline 0-RTT if it choses a different ALPN protocol. This can be implemented by just doing ALPN negotiation as normal and declining 0-RTT if the result does not match. (If client and server prefs have not changed, 0-RTT will work. If prefs have changed, 0-RTT will miss but future sessions will start being 0-RTT-able. I think this is probably the sanest behavior.)

5. The client performs the usual checks on the selected ALPN protocol (must be one of the advertised ones). In addition, it enforces that, if 0-RTT was accepted, the protocol must match the session one.

This matches the behavior I intended in the spec (and the one NSS implements).

-Ekr


Pinning on the most preferred one causes awkward transitions when the most preferred ALPN protocol is not the same as the most commonly deployed one. If we ever define, say, h3, we want that one in front of h2 presumably, but we wouldn't want to lose 0-RTT against all the h2 servers out there.

I don't think we should be reorder preferences based on the sessions we are offering. That makes it much harder to reason about the behavior of preference lists.

David

On Wed, Oct 12, 2016 at 3:49 PM Kyle Nekritz <knekritz@fb.com<mailto:knekritz@fb.com>> wrote:
Currently the draft specifies that the ALPN must be "the same" as in the connection that established the PSK used with 0-RTT, and that the server must check that the selected ALPN matches what was previously used. I find this unclear if

1) the client should select and offer one (and only one) application protocol

2) the client can offer multiple protocols, but use the most preferred one offered for 0-RTT data

3) the client must send the exact same ALPN extension as in the previous connection, but must use the ALPN previously selected by the server (even if it was not the client's first offer).



To clarify this we can instead

* allow the client to offer whatever ALPN extension it wants

* define that the 0-RTT data uses the client's most preferred application protocol offer (and the server must pick this ALPN if it accepts 0-RTT), similar to using the first PSK offer if multiple are offered

* recommend that the client uses the same application protocol that was used on the previous connection.



PR: https://github.com/tlswg/tls13-spec/pull/681



Kyle



_______________________________________________

TLS mailing list

TLS@ietf.org<mailto:TLS@ietf.org>

https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=diBVKMBm_GJBrqBsilZWP0aN5KD9xwvXSCIDOE5-LAA&s=FuSqdY1S96Vtry63oUY7VG4b-5JRJgZYv33IoBPkAhM&e=>