IETF Logo Mail Archive

Re: [TLS] Comments on EndOfEarlyData

Markulf Kohlweiss <markulf@microsoft.com> Tue, 23 May 2017 18:17 UTC

Return-Path: <markulf@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 5557E12E03B for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.391
X-Spam-Level:
X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 xPcw_0S_oQ7d for <tls@ietfa.amsl.com>; Tue, 23 May 2017 11:17:48 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8A112DDD2 for <tls@ietf.org>; Tue, 23 May 2017 11:17:47 -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=LYHL/T+8M5XPwbrlsG4q8peQwd3ctwVyM54MAus1UEQ=; b=e0fh0voOUWRGzoin3VrEBmIgPf2oDTdkQ8yNuULDi4BxBxRA03gX4YGkeiJwTf5J98F9Ui4SByOCFIb0RsTZGbaQU2j0/RITV+0uqzYw/XhiaHBF+zoNXIkmTT+tQHjHtWxLCQrMFhiq4IELsZPIO45hHUBvYeKsz62S/7N9Vdg=
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) by DB5PR83MB0038.EURPRD83.prod.outlook.com (129.75.21.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.0; Tue, 23 May 2017 18:17:42 +0000
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6]) by DB6PR8303MB0069.EURPRD83.prod.outlook.com ([fe80::ac56:1e73:9b19:5ba6%18]) with mapi id 15.01.1143.000; Tue, 23 May 2017 18:17:41 +0000
From: Markulf Kohlweiss <markulf@microsoft.com>
To: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
CC: Samin Ishtiaq <Samin.Ishtiaq@microsoft.com>, Antoine Delignat-Lavaud <antdl@microsoft.com>, Britta Hale <britta.hale@item.ntnu.no>
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0QANphQAAAFEp8A=
Date: Tue, 23 May 2017 18:17:40 +0000
Message-ID: <DB6PR8303MB00697808B11F2DB538106038ABF90@DB6PR8303MB0069.EURPRD83.prod.outlook.com>
References: <DB6PR8303MB0069F9DF083276C426975D80ABF90@DB6PR8303MB0069.EURPRD83.prod.outlook.com> <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
In-Reply-To: <9a52562a-d4cd-3344-de4e-8c798887f451@akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2a01:110:8012:1010::35d]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR83MB0038; 7:JxKwrYAecOI1ktXeS3P4MiEVSTrMF4AMglsJdI6w7OA5SBop42nCTiiaH30SSkrptgiBukI3fmi3Yzzm4gxAiBU//w/90umBk0HyvesP/vshhwLe5MfVnVGSuCnpz9Py27oRfvme7l+Vl84LbUjieEmrmd0HycvFBGAHYdCM8NvlJM7hpMlOoGyFiNfaolQXfpStcNzXd4O764/dXzZfg0BOXRGnxqVws17DWatEb8gQTnEIeKFizPt4Hq/gC+rrJCf1tqq3TzKyJKxbmcEJvrhT1yA4CpzJFEsRHo9URYaRDDgMog0ArEHfzhBFFWhitLeXL+pJYkuXpN5k39viCC+/4E9oAT5eNiuYS3RNmLo=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6029001)(6009001)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(39410400002)(24454002)(377454003)(6436002)(6506006)(7736002)(2900100001)(229853002)(86362001)(7696004)(86612001)(2906002)(3660700001)(478600001)(10290500003)(25786009)(53546009)(3280700002)(33656002)(189998001)(2501003)(2950100002)(4326008)(5250100002)(6116002)(790700001)(10090500001)(53936002)(38730400002)(5660300001)(74316002)(54906002)(9686003)(76176999)(54356999)(6246003)(99286003)(55016002)(81166006)(5005710100001)(8936002)(8676002)(6306002)(54896002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR83MB0038; H:DB6PR8303MB0069.EURPRD83.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-ms-traffictypediagnostic: DB5PR83MB0038:
x-ms-office365-filtering-correlation-id: a41a29e7-2d81-4a51-a122-08d4a208002b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DB5PR83MB0038;
x-microsoft-antispam-prvs: <DB5PR83MB0038AB2B7B8994B10C2E62CEABF90@DB5PR83MB0038.EURPRD83.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700043)(100105000095)(100000701043)(100105300095)(100000702043)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703043)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704043)(100105200095)(100000705043)(100105500095); SRVR:DB5PR83MB0038; BCL:0; PCL:0; RULEID:(100000800043)(100110000095)(100000801043)(100110300095)(100000802043)(100110100095)(100000803043)(100110400095)(100000804043)(100110200095)(100000805039)(100110500095); SRVR:DB5PR83MB0038;
x-forefront-prvs: 0316567485
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB6PR8303MB00697808B11F2DB538106038ABF90DB6PR8303MB0069_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 18:17:40.9723 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR83MB0038
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rPO0aUqOBJ22nVGo-YqDAAVwHn8>
Subject: Re: [TLS] Comments on EndOfEarlyData
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, 23 May 2017 18:17:51 -0000

Given that 0-RTT and 1-RTT guarantees are very different, it seem important to distinguish the two streams and model them separately.

Of course that does not prevent applications that want to treat them as a single stream, but it is harder to understand the security one gets from such a mixed channel, e.g. some requests may have strong replay protection, others won’t.

--markulf

From: Benjamin Kaduk [mailto:bkaduk@akamai.com]
Sent: 23 May 2017 18:35
To: Markulf Kohlweiss <markulf@microsoft.com>; tls@ietf.org
Cc: Samin Ishtiaq <Samin.Ishtiaq@microsoft.com>; Antoine Delignat-Lavaud <antdl@microsoft.com>; Britta Hale <britta.hale@item.ntnu.no>
Subject: Re: [TLS] Comments on EndOfEarlyData

My initial thoughts...

On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:


I am paraphrasing a long thread on the issue that we had within

the miTLS development team, and I am primarily commenting on the

analysis aspects. I also hope that it will clarify any remaining

problems of understanding that I have on the issue.



If we see EOED as a stream termination signal, then there seems

to be a difference in performance for conservative servers that

want to wait until receiving all 0RTT data before responding to

the client's request in 0.5RTT communication.



Said otherwise, we want servers to be able to respond with application

data based on application data from the client and know that that

that data was not truncated.

Thanks, the keyword of "truncated" caused me to understand the intended point.

I think this question ends up tying into the more philosophical one of whether early data and 1-rtt data are considered "separate streams" or not -- if they are separate streams with distinct end/start, then of course one wants to detect possible truncation as it happens.  But, if they are conceptually the same stream and the boundary between them is "just" a bookkeeping operation of key change, then there is no need to be concerned about detecting truncation; the application just continues reading in data and replying when complete application protocol requests are received.

-Ben

v2.23.0 | Report a Bug | By Email