Re: [TLS] Separate APIs for 0-RTT

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 13 June 2017 18:57 UTC

Return-Path: <Andrei.Popov@microsoft.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 CEAB8129486 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 IS8qL0Pw3xKR for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:57:07 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0102.outbound.protection.outlook.com [104.47.32.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E339A129409 for <tls@ietf.org>; Tue, 13 Jun 2017 11:57:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XS+75at/YpL14tGrR4/98Z6+0yrn0G7oexm0jZDPtpA=; b=erGyDDHJ7MLtKr8nvxUju2Tto/VrobvuhsT77QN8XhrFuQobdn6cwuiDwEsT/uu76iVIY21OWqM7DTZg/QYa4GwnToUYi+YD432Wue+j8+AjXuQtlwcONYgQGv28RwfshW31QcmBmi73QjMZrWl6HO/EqwkTm3uZ2JFlhl8MUcI=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0058.namprd21.prod.outlook.com (10.161.140.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Tue, 13 Jun 2017 18:57:05 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f%15]) with mapi id 15.01.1199.000; Tue, 13 Jun 2017 18:57:05 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Benjamin Kaduk <bkaduk@akamai.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, Colm MacCárthaigh <colm@allcosts.net>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Separate APIs for 0-RTT
Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkIAABhGAgAAS9ICAAAKWgIAABRGAgAAA6oCAAAfUAIAAA2CAgAACI1A=
Date: Tue, 13 Jun 2017 18:57:05 +0000
Message-ID: <DM2PR21MB0091B8DC8780B4FA67464F0A8CC20@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <CABcZeBPkRhjLNT2QKO+DgfjE8-e-KrJ5XOLbA9bR24R1Fd96MQ@mail.gmail.com> <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <CABcZeBMpeBhcKoJYuMwLyER0VBh+RtVr6amWMPos3CJipXYHcA@mail.gmail.com> <DM2PR21MB00916718A71749E5D2CB19C38CC20@DM2PR21MB0091.namprd21.prod.outlook.com> <CABcZeBO+Qprg4DTwNJrFU1PXDPyKbbdakMrF9fhe02jRL50cow@mail.gmail.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <CAAF6GDfyqMndibTujY83_Xha2dZn7qvaCpZJw7xZ--b=-EOaYA@mail.gmail.com> <bf4506e7-13ce-ce7f-d20e-67a0d73c642a@akamai.com> <CAAF6GDePg9FL0JgzrWrTcrK7X=J0_fKjHVCj9EScvyQobJWTKA@mail.gmail.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com>
In-Reply-To: <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:b::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0058; 7:6nPrgEzYfpnAQYsoipqLkgxy49lr+hhPNegiDta02a+8/vtJptUF0PjyyM9qd9UBH767n1C5sdp39jFFo5nkHLsPJq0orykKiw/iUHpQwsdtjEg2Act0Qe4Fnfhveto+RmMP0JlXW3U0TOqwjltOCZnZTeh1exa/xwpeyn7lwYKf5nDCHmu9YLE7uD8FdM/4lAIko0PAbKMIW9TOMqnzAA3p5R6969glSG9OseTou3G0jK2bfiu0VU6NtoI1yNCVgcVd8gnBL0zeCaTyCYy/GzvS0u3tiInkv5i/mQixwuv/lH6ddQ0JN5rdRhcdWr7YpmZTvdswndndd1BerNjI1DCMEj3eE2qG2yim93WwKAI0cIQAlKFEuf5zLvKod57GERnMVs3Kg6VG1pdVaZQNUa5PsuxosyWu5artYr2D7pXRCYraZhFPCNuColJnJ+/ChPTgPugRkVSj3qigHS85NRvQqqUHqgct96Bfk83pkHPIO5ivsit7CzOAcAeLDkHLCOZBQDrOpS9yBOHTZUZEQYjf29kvk56afLSk6ohBstMf3oUJqryWp6scAD8/RYCm11WszQVCXtM44+rRMbx2oQcK29ykJzwaabP2v9LPiZQwGoCfGPH07sFM/nNPeAXM07GgvqGtuqVvYyaU2asJfRu/ju+GDjhOpDHemYjL1CD9z9CLKd68Gw+l589Sv8TPYbCydyhd7XXc5b1ES19TRrFzlwsj0jwbmo8ThQPybNP1hK1wgqqx5sW7E4Ns8mwG4kVLs68/MAYd9o4BPpF6wy42uutfLY1Mb3Ql73IhxYxfM4WEOPH8CqF5K/wxPjiv
x-ms-office365-filtering-correlation-id: 279e53db-1e35-4799-a975-08d4b28dfbec
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0058;
x-ms-traffictypediagnostic: DM2PR21MB0058:
x-microsoft-antispam-prvs: <DM2PR21MB00580CA277957508B2B0B1558CC20@DM2PR21MB0058.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0058;
x-forefront-prvs: 0337AFFE9A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(377454003)(199003)(189002)(6116002)(7696004)(790700001)(14454004)(102836003)(7736002)(53546009)(2900100001)(81156014)(97736004)(8676002)(8936002)(81166006)(229853002)(25786009)(5660300001)(2906002)(4326008)(72206003)(74316002)(3280700002)(2950100002)(5250100002)(3660700001)(106356001)(6506006)(6436002)(9686003)(54896002)(6306002)(236005)(55016002)(99286003)(68736007)(10290500003)(478600001)(189998001)(53936002)(105586002)(38730400002)(6246003)(101416001)(54356999)(76176999)(86612001)(33656002)(8990500004)(5005710100001)(10090500001)(50986999)(86362001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0058; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB0091B8DC8780B4FA67464F0A8CC20DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 18:57:05.1045 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0058
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TxDFGh8aDQvm2oCYu4Y7QJT6ugs>
Subject: Re: [TLS] Separate APIs for 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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 Jun 2017 18:57:10 -0000

Regarding RFC language, I think we could be more specific:



1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in;

2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in;

3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data.



Or some better phrasing that our capable editor can craft😊.



Cheers,



Andrei

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Tuesday, June 13, 2017 11:48 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; Colm MacCárthaigh <colm@allcosts.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

On 06/13/2017 01:35 PM, Ilari Liusvaara wrote:


On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:

On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <bkaduk@akamai.com><mailto:bkaduk@akamai.com> wrote:



I have been operating under the impression that at least some application

profiles for early data will require that certain application protocol

requests (e.g., something like HTTP POST) must be rejected at the

application layer as "not appropriate for 0-RTT data", which requires the

application to know if the request was received over 0-RTT data.







That's a really good point; you've changed my mind. It's obviously a good

idea to return a 5XX to a POST over 0-RTT and that would need this.



I think the proper code to send is 400. The request is client error,

nor server error, so it is 4XX. And there does not seem to be suitable

4XX code, so it goes to catch-all client error code 400.



For HTTP/2, refusing the stream (sending stream error 7 without sending

server headers)  is also a good choice, as this should trigger a

retransmission of the offending request (POST requests failed by

refusing the stream are retryable).



At least the http 0-RTT profile that I started writing was going to allocate a new 4XX error code for this purpose.  I am under no pretense that my version of such a document will resemble anything that finally gets published, though.

-Ben