Re: [TLS] Comments on EndOfEarlyData

Markulf Kohlweiss <markulf@microsoft.com> Tue, 23 May 2017 11:50 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 1DC7C129AEB for <tls@ietfa.amsl.com>; Tue, 23 May 2017 04:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.802
X-Spam-Level:
X-Spam-Status: No, score=-4.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 n_-RZCEy8EMc for <tls@ietfa.amsl.com>; Tue, 23 May 2017 04:50:33 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00130.outbound.protection.outlook.com [40.107.0.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DB5129AFC for <tls@ietf.org>; Tue, 23 May 2017 04:50:08 -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=M+xLu0wTzZAkx11IFitCltVZA6MMnqi845Iq8J+frao=; b=mVJkLHJ3r7Y+x+jMFsq3fDsl1U760VI9HR5RNRxR9DpLWGR14CCjjKG5Qa5MAWwcEyJPRUGdouNtjqwCgkJLfbaza2OIZwje2nW52WOfUEITtn9699mfgw/Q1VKIfAfhU0i7rVWfrk/JGbKaX1xZ0Yx0Mg9Eh69xYPCt8GuQYBw=
Received: from DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) by DB6PR8303MB0069.EURPRD83.prod.outlook.com (129.75.139.20) 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 11:50:04 +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 11:50:01 +0000
From: Markulf Kohlweiss <markulf@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
CC: Eric Rescorla <ekr@rtfm.com>, Britta Hale <britta.hale@item.ntnu.no>, Cedric Fournet <fournet@microsoft.com>, Antoine Delignat-Lavaud <antdl@microsoft.com>, Santiago Zanella-Beguelin <santiago@microsoft.com>, Samin Ishtiaq <Samin.Ishtiaq@microsoft.com>, "karthikeyan.bhargavan@inria.fr" <karthikeyan.bhargavan@inria.fr>
Thread-Topic: [TLS] Comments on EndOfEarlyData
Thread-Index: AdLTtEU8p75Loa4ER0+xBa7xoDxY0Q==
Date: Tue, 23 May 2017 11:50:01 +0000
Message-ID: <DB6PR8303MB0069F9DF083276C426975D80ABF90@DB6PR8303MB0069.EURPRD83.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [167.220.196.154]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR8303MB0069; 7:60Hix8B+siC5ouAc6G+ivNjbYjC4XqEzJ4tlJTbJkPY8E7YAvxBkyNlfRjc81fHYsRZvBdD9kNpEWuyCD3PzrcDmRUOkazIN1/5zxzPsWiJ2f8wSU9xy84/3jmxmD0lpeHG/kVlDnqTNc7po1WFBllbnNe0fg16RMkXznUh9qNPI6KDwBVZbPqX9jhdCAgCP+e2akBjaYW55FulS80ja19xj5C/IBrShPznNT15WrvrdOFBd2JYzUHxCq+XO5Xpa60JVqU9S70Uw+kUW3oL5zRF6pnN02Wgh3DQ5r+uEQoWI1Z2sK5L+9930jEUEEUrNQYUocZHYkU0e1S0q9qQYGfJ2DxSVV36L7AXhiBQDRsY=
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(979002)(6029001)(6009001)(39850400002)(39840400002)(39860400002)(39450400003)(39400400002)(39410400002)(377454003)(24454002)(5640700003)(7736002)(6506006)(305945005)(6436002)(2351001)(6916009)(229853002)(86362001)(7696004)(2900100001)(86612001)(478600001)(2906002)(413944005)(3660700001)(10290500003)(25786009)(53546009)(3280700002)(33656002)(66066001)(189998001)(4326008)(2501003)(5250100002)(102836003)(6116002)(3846002)(6246003)(38730400002)(10090500001)(110136004)(5660300001)(54906002)(99286003)(55016002)(9686003)(54356999)(74316002)(50986999)(53936002)(5005710100001)(8676002)(1730700003)(81166006)(8936002)(8990500004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR8303MB0069; H:DB6PR8303MB0069.EURPRD83.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
x-ms-traffictypediagnostic: DB6PR8303MB0069:
x-ms-office365-filtering-correlation-id: 785a160f-05d2-466b-e9c7-08d4a1d1d887
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DB6PR8303MB0069;
x-microsoft-antispam-prvs: <DB6PR8303MB0069D27E838BDDC6F83D2F24ABF90@DB6PR8303MB0069.EURPRD83.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700043)(100105000095)(100000701043)(100105300095)(100000702043)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703043)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(6072148)(100000704043)(100105200095)(100000705043)(100105500095); SRVR:DB6PR8303MB0069; BCL:0; PCL:0; RULEID:(100000800043)(100110000095)(100000801043)(100110300095)(100000802043)(100110100095)(100000803043)(100110400095)(100000804043)(100110200095)(100000805039)(100110500095); SRVR:DB6PR8303MB0069;
x-forefront-prvs: 0316567485
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2017 11:50:01.4105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR8303MB0069
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CNp0RbSGVezj_rifcbcQOrdBmE4>
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 11:50:35 -0000

Dear Eric, Britta,

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.

==Scenario with EOED as Handshake message==

After the Client sends 0RTT data the Server gets 

CH, APP_C1, APP_C2

and typically responds with 

SH, ... SFIN, APP_S1

But wait, the server doesn't actually know that early data is
terminated. A conservative server would instead send only

SH,... SFIN and wait of EOED

The Client receives SH,... SFIN

Only now the Client knows that the server accepts 0RTT and he can
send and hash the EOED into the transcript hash.

The server receives EOED, CFIN

Only now such a conservative Server can send APP_S1. 

This results in an additional round trip for conservative
servers, and thus discourages the use of EOED as a stream
termination signal.  ---


==Scenario with EOED as Alert==

With an Alert based design for EOED we can instead have the
following flow, where the client immediately sends the EOED after
his request without waiting for the SFIN. Here the client makes the 
conscious choice not to send any additional early data.

The server gets 

CH, APP_C1, APP_C2, 
respond with SH,...SFIN

The server continues reading EOED and is notified about termination 
of 0RTT traffic .

The server can now immediately sends  APP_S1, ....

It is important that the server would send SH regardless of
receiving EOED to avoid deadlock due to clients that wait until
receiving SFIN before sending EOED.  ---


Maybe the implicit assumption is that applications, e.g., HTTP/2
have to do their own termination of requests, and that EED serves
a different purpose? What would be the justification for
providing such a mechanism for 1RTT traffic but not for 0RTT
traffic. And why not enable different usage profiles?

Overall, I find the design based on Alert messages cleaner and
more consistent. From colleagues I heard folklore that it would
also ease verification and reduce the implementation complexity
for modular implementations that want to separate Record Layer
and Handshake Layer concerns.

This is related to verifying the handshake without relying on 
encryption at all but I will let them comment on this if they deem 
it necessary.

--markulf


> On 16. mai 2017 23:28, Eric Rescorla wrote:
>
>> On Tue, May 16, 2017 at 2:41 PM, Britta Hale <britta.hale@ntnu.no> wrote:
>>
>> EOED signals the end of data encrypted with early traffic keys, yes, 
>> and the next message is the Finished message encrypted with the 
>> handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic 
>> key is signaled by the Finished message, not EOED. The Finished 
>> message, like a KeyUpdate message, are handshake messages, and both 
>> signal the start of a new key use for application data.
>>
>> In comparison, EOED signals the end of key use for application data - which
>> correlates
>> to alert behavior.
>
> This seems like a point where reasonable people can differ, especially as ultimately the motivation for this change 
> was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some analytic difficulty, or do you just find it > > unaesthetic?
>
> -Ekr