IETF Logo Mail Archive

Re: [TLS] The case for a single stream of data

Andrei Popov <Andrei.Popov@microsoft.com> Tue, 09 May 2017 17:28 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 D6A2C1294F3 for <tls@ietfa.amsl.com>; Tue, 9 May 2017 10:28:31 -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 dlua_Ttps5S9 for <tls@ietfa.amsl.com>; Tue, 9 May 2017 10:28:30 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1F1127076 for <tls@ietf.org>; Tue, 9 May 2017 10:28:30 -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=JIDU28dNwAZRgTeirApLXMewg3UgqJz+Ae8L8705pDQ=; b=Q+7XI1vnyHF/tmjdBIpVVEPLUEWL9sGIcZK6AL9IurYUfXw/6szTC06bQ9TFjp5uF/pINL+gnfP2nGU5RBtqKDPeyh3/rjRi1YHM9DUGlzGYNMZqwzkla1S2RKWxk0N87OsHbfvt2Ohu/83AVvaP2nA85iDuLBxzNsIaXkFcdIo=
Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0092.namprd21.prod.outlook.com (10.161.141.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1101.0; Tue, 9 May 2017 17:28:27 +0000
Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) by DM2PR21MB0091.namprd21.prod.outlook.com ([10.161.141.14]) with mapi id 15.01.1101.000; Tue, 9 May 2017 17:28:27 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "Salz, Rich" <rsalz@akamai.com>, Colm MacCárthaigh <colm@allcosts.net>
CC: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] The case for a single stream of data
Thread-Index: AQHSxbyr6+FqrvsOD063PUQX/Ho2+aHsL04AgAAHj4CAAAPUgIAAC1hQ
Date: Tue, 09 May 2017 17:28:27 +0000
Message-ID: <DM2PR21MB0091155532C3298513B970508CEF0@DM2PR21MB0091.namprd21.prod.outlook.com>
References: <CAAF6GDfm=voTt_=JrdGtiaYby1JG8ySU2s6myjjpHKeGvi0bMg@mail.gmail.com> <9f5858c8d86742b9aa82bdac46590c92@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDcGQ0YTYFFD+HVD71O9GCW7V3r_UNce1LQsHF1Zs9aBLQ@mail.gmail.com> <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
In-Reply-To: <6ce1dc8757fa4f6693263c8e4f06f277@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: 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: [2001:4898:80e8:3::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM2PR21MB0092; 7:ET6mYxVR2sdoNBeyPib+5P8Fu7pKqiIJy/8hYLIMrqxl0o3ckGxZ+M5H8g3R7yN6QLbnZsFi42r0y7IN8KdfVVa/mtqpOW7vF115I6frG5ps1QH5PhGsTF9mPCFxrEvfiuuzgoGvVw/sQhDlmnesCNNuHs52jA3wzMQzWraG/T0snipilkVMS8bPKRBiij2Dt1O2FR1U0JxBXk/elU/VS7wemU1u7U2euVNl9RcDyKTCwavAiO9+PNbZZXcotU9YlIJJHM4x3YYmnDk+fBcUbSr0o76+0+p7qcWXS5R9l0H1yY4D4PARaTb3OflNpjod76HIjg3kzcXOFUR7MZTz5Ka9olhry7Ea6r2nRTHgkVI=
x-ms-traffictypediagnostic: DM2PR21MB0092:
x-ms-office365-filtering-correlation-id: 04ca2c15-9950-449c-40a7-08d49700cdbe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR21MB0092;
x-microsoft-antispam-prvs: <DM2PR21MB009261C9E2BB8663E766C1028CEF0@DM2PR21MB0092.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703036)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:DM2PR21MB0092; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:DM2PR21MB0092;
x-forefront-prvs: 0302D4F392
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39860400002)(39450400003)(39410400002)(39400400002)(39850400002)(33656002)(3660700001)(77096006)(93886004)(6116002)(6506006)(2950100002)(3280700002)(2906002)(8936002)(81166006)(8676002)(229853002)(2900100001)(86362001)(5660300001)(189998001)(9686003)(74316002)(38730400002)(478600001)(99286003)(10290500003)(122556002)(76176999)(7696004)(54356999)(6436002)(50986999)(53936002)(5005710100001)(10090500001)(6246003)(7736002)(305945005)(55016002)(4326008)(25786009)(8990500004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0092; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2017 17:28:27.1799 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0092
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pnk_2SmYGlhtYXHmYvTXi7tp8_M>
Subject: Re: [TLS] The case for a single stream of data
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, 09 May 2017 17:28:32 -0000

> To me, the argument against this comes down to this:  The 0RTT data has different security properties than the post-handshake data, and TLS implementations should not hide that difference from applications.
This is true, and early on there seemed to be general agreement that 0-RTT data would require explicit opt-in from the caller, e.g. via new API surface.

> Once the initial SSL_write_early_data() call has completed successfully the client may interleave calls to SSL_read_ex(3) and SSL_read(3) with calls to SSL_write_early_data() as required.
I'm curious why the client does not have to call SSL_read_early_data instead of the normal SSL_read in this case.

Cheers,

Andrei

v2.23.0 | Report a Bug | By Email