IETF Logo Mail Archive

Re: [TLS] Separate APIs for 0-RTT

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 14 June 2017 21:01 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 A07DB1275AB for <tls@ietfa.amsl.com>; Wed, 14 Jun 2017 14:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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] 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 mkUg3xvNQvug for <tls@ietfa.amsl.com>; Wed, 14 Jun 2017 14:01:11 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24F8127B31 for <tls@ietf.org>; Wed, 14 Jun 2017 14:01:11 -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=FQpcRzvjO5QTk/+UD0NUHnXnTDu1FVYq4lPrcYkHo2s=; b=nxzgbJtoETPn/RIWjfSLu9cert2KFmtoTQJODoclgnsRfdimz04z9og6iBqs4nMghU/Y8hgtuT/RwY9Egr52LgW9l75eWuU92CXAtRWgiu3z79YaTj8GZru5M9D4BttNPqgJWRpm9x5YxrwWPltUGHBCD4do9CCJEoSUshWzuMw=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0073.namprd21.prod.outlook.com (10.161.140.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Wed, 14 Jun 2017 21:01:08 +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; Wed, 14 Jun 2017 21:01:08 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: David Benjamin <davidben@chromium.org>, Petr Špaček <petr.spacek@nic.cz>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Separate APIs for 0-RTT
Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkIAABhGAgAAS9ICAAAKWgIAABRGAgAAA6oCAAAfUAIAAA2CAgAACI1CAACGTAIAAnPmAgADkkgCAAA/9kA==
Date: Wed, 14 Jun 2017 21:01:08 +0000
Message-ID: <DM2PR21MB009176844759F65141E1D6EA8CC30@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <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> <DM2PR21MB0091B8DC8780B4FA67464F0A8CC20@DM2PR21MB0091.namprd21.prod.outlook.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> <e5ab9945-054b-67bf-beef-9fce7a4a6f36@nic.cz> <CAF8qwaCuDk3oemXeKyEzzRgg2oCMA22qMBXQaL4YW3yWAeXUvA@mail.gmail.com>
In-Reply-To: <CAF8qwaCuDk3oemXeKyEzzRgg2oCMA22qMBXQaL4YW3yWAeXUvA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: chromium.org; dkim=none (message not signed) header.d=none; chromium.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:b::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0073; 7:XN9d4yigE0Ylv9lAvLiGun5U19krrQhfX7c8yQl5oLuIQB8kmDZ007oWhoK+a5wxFwYKV2HsA985a+cFuUAIsKPDruFXApVcJxYc85zlp24hOmaXvOC2NCLIc4jhgqEAaJV76+b3nZZc4aMmsMlSPI1nMICWCvAd1QTJXL7UVHXc9id+9QbL+NzodufaJ61ILW4KIAWg1uBxLLzme9DkrUZj9Kr42IJyHRzCvAVaredQqSw1hvYLSEthrSTwo1aODPK5a51I13zmaxcQg/lsnqpuPq37Ua5jbZDN327NHWUds0ABXgXK9KY3an4+9h6ktCWxO5ODBNTFiDO9K+K6ujj90C3/sVaahHUvCtV3CL2Oq+WLbF+VJrYc+zRKkpqUjltFXIVQO5abVW60g4b48XDTof9+DN5dS821xrTyH1ozvgAt0znOXRufnyAl8nryUyHjkUq8uQVERjX7fYZHdvnOBsogwgi7/dQhWy8UciR1LmNdumLxE8VUY14niBIh5qP0l6w2nn+jU/ZhrYt52EmKWofcdYa9gmpmW/eZnObvFTvJDoS0WwxpjQRUxkpIE7HXhOfk9pz7a7I3EE2aV//zt5X4WIGhJVGRzOw8tZD95NnKc8w9DV490M1bmQ/eMTnTi/ga6hAHUqcpdIjRUd5QD851qddsp5VmFwF0/3yveefDNUtjklR7JZOQ7MAmL5ZXiRmhW2DV7L9W3xTlCpv/xM1Ej4faWGGdWCqYtllyPjgGbwmSaSNzx9Wg1yhrpW02bYjLlHeD89SIj5sKCJRzQi/hcDHSzsm+tRy+15/GdzeDj1O06Fo+Rdt/DZMp
x-ms-office365-filtering-correlation-id: 2e09f391-645c-4638-5fdd-08d4b3687b09
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0073;
x-ms-traffictypediagnostic: DM2PR21MB0073:
x-microsoft-antispam-prvs: <DM2PR21MB0073BB2F24C2BBFC34C271A68CC30@DM2PR21MB0073.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)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0073; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0073;
x-forefront-prvs: 033857D0BD
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39840400002)(39410400002)(72206003)(7736002)(10290500003)(25786009)(8936002)(50986999)(86362001)(478600001)(74316002)(14454004)(6306002)(53936002)(6246003)(2950100002)(54896002)(9686003)(8990500004)(38730400002)(6506006)(76176999)(5660300001)(54356999)(6436002)(55016002)(99286003)(93886004)(10090500001)(33656002)(5005710100001)(2906002)(3660700001)(229853002)(790700001)(7696004)(3280700002)(189998001)(2900100001)(6116002)(102836003)(5250100002)(8676002)(81166006)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0073; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR21MB009176844759F65141E1D6EA8CC30DM2PR21MB0091namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 21:01:08.6233 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0073
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dbNbPE_XTKFrn-gFO9A164Pbk0I>
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: Wed, 14 Jun 2017 21:01:15 -0000

  *   What if the server receives data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid?
It appears safe to treat such data as 0-RTT; only the application can make this call, and it needs info from the TLS stack to make this call.


  *   We could say that the application profile should modify the protocol to reject such cases. Now, we’re taking on complexity in every protocol specification and parser.
It would of course be preferable (some would argue, necessary) to secure 0-RTT application_data at the TLS layer, but so far we’ve failed to come up with a way to do so.


  *   Our problem is a server wishes not to process some HTTP requests (or other protocol units) at 0-RTT and needs to detect this case. So check a boolean signal for whether the connection has currently passed the 1-RTT point before any unsafe processing.
I think this would be a valid implementation of #3. There may be other implementation options that make more sense for a different TLS API or a different application protocol, so I’d rather not put a specific implementation option in the RFC.

Cheers,

Andrei

v2.23.0 | Report a Bug | By Email