IETF Logo Mail Archive

Re: Consensus Calls for Transport/TLS issues, post-Cupertino

Nick Banks <nibanks@microsoft.com> Tue, 22 October 2019 01:39 UTC

Return-Path: <nibanks@microsoft.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1588120ACF for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 18:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 XD9GFs-cImJu for <quic@ietfa.amsl.com>; Mon, 21 Oct 2019 18:39:26 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650133.outbound.protection.outlook.com [40.107.65.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E8A120ABF for <quic@ietf.org>; Mon, 21 Oct 2019 18:39:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hsp2DAuQaNZowh3Wkk+ZO9VvN+MHj0p0IQ1oEC0IU56IZrpF84GkBqRQTV1zp5CFQcHiaCZQo5k6rsY7SQeVEv7jSQZSHxk1dnvA5pXh/W/U4VSVJLfQ7OdW417xOrn/5IKqwtrzG52IW9wk+/zrQ3BsaBk3DZfBDn7K+Kn2JGBwcdzysyjm+9eX2DzZMTaLKdhpvB282fXbxxPH0fpIogw8pNTcqM25Gv/a0R5Gtazu0/3cVmiVxAKZHYniYnk9nX8MEMv3viO0qehhevGD8Z6j3GofDag2GZYWrPp1QAZIXDrwbZzlzBsTzUBfvrkJ7wL+5v/4IsOXX+Olxf8kvg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W5/HtlDFsUYknv7mihzE9bWr5/UC34ws8WlBgOQjJCM=; b=OnYopNLjxcQgIY6v4Gu3zvKTfprH6jmJYXchdkpOomEfGxVHNafOEodAYbGGS7P930IgOh3c1VBLqwy8d4N5xLc6N3TH1iRgX+sYNczQvd6rIYQXyGVLGYt+UgndO/62pIWrM+BT+o5lcXgcAOx6P/t5hj7cyeaEXF0liW78+Auj1itO+by3ZHXPCP4HkCikkpFgH/xX43s77oIzyCe8WMZJnYjpen4368w/mEfw6Bynfw9Sk9dEWVJFrx4Jo6yydsEY8yRR/SgTlxVgoELaToYQ6PVywrVgtXcHJBUeFkeJMiHhZMIwFQX3yNfP88Fm8BYk0dMlmHw3cR3aiJ2a3A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W5/HtlDFsUYknv7mihzE9bWr5/UC34ws8WlBgOQjJCM=; b=X+0sweuBSzskZi7ulX1y4LrqDWcO/aNnAzhjFx0rVvslUuOk3djVG3YAk5ggP0wYFAsueCy9/e2CDUmFci/d7kfaeQ+CpjXNAcE6LUnWAhSoZi1lTrm3G00OpApioQ1BwBkucFwCzcHgOlwIcn36bla1illbkfnj9uzpb2cK8Yk=
Received: from BN3PR00MB0083.namprd00.prod.outlook.com (10.167.6.147) by BN3PR00MB0193.namprd00.prod.outlook.com (10.167.6.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.2399.0; Tue, 22 Oct 2019 01:39:23 +0000
Received: from BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::793e:ff6e:5d6a:c8cb]) by BN3PR00MB0083.namprd00.prod.outlook.com ([fe80::793e:ff6e:5d6a:c8cb%9]) with mapi id 15.20.2403.000; Tue, 22 Oct 2019 01:39:22 +0000
From: Nick Banks <nibanks@microsoft.com>
To: Kazuho Oku <kazuhooku@gmail.com>, Mark Nottingham <mnot@mnot.net>
CC: Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Topic: Consensus Calls for Transport/TLS issues, post-Cupertino
Thread-Index: AQHViHGZrlM8wQ569EKq+7NqZ8qSlqdl3+KAgAAB9KM=
Date: Tue, 22 Oct 2019 01:39:22 +0000
Message-ID: <BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680@BN3PR00MB0083.namprd00.prod.outlook.com>
References: <4D6397AF-B411-4E67-AFD2-76E8F2AD462C@mnot.net>, <CANatvzwYA-NN+p5jLu4vpgKY_G-ZoUM03CacZWS2FAPyPqgiiw@mail.gmail.com>
In-Reply-To: <CANatvzwYA-NN+p5jLu4vpgKY_G-ZoUM03CacZWS2FAPyPqgiiw@mail.gmail.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=nibanks@microsoft.com;
x-originating-ip: [24.113.13.203]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 398c02b2-82f3-405a-ed3f-08d75690aa5c
x-ms-traffictypediagnostic: BN3PR00MB0193:
x-microsoft-antispam-prvs: <BN3PR00MB019317BBAD06A1487BFEE6BCB3680@BN3PR00MB0193.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(136003)(376002)(396003)(366004)(39860400002)(199004)(189003)(7736002)(2906002)(54906003)(8676002)(81156014)(22452003)(6436002)(81166006)(256004)(476003)(8936002)(3846002)(6116002)(76116006)(606006)(110136005)(186003)(26005)(316002)(66556008)(486006)(66446008)(64756008)(66946007)(66476007)(86362001)(14444005)(11346002)(561944003)(91956017)(446003)(71200400001)(71190400001)(74316002)(8990500004)(99286004)(4326008)(10290500003)(55016002)(54896002)(102836004)(14454004)(33656002)(6246003)(6306002)(53546011)(6506007)(229853002)(478600001)(966005)(76176011)(25786009)(10090500001)(7696005)(52536014)(9686003)(66066001)(236005)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR00MB0193; H:BN3PR00MB0083.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uBj8wxWImS0CWRTJxVu99oRttGmI5ww2nklgREw64w4gYKoU3sBZo8axN1DgIfqGNpcfPZGDinh/ViOHSE9i/hGnUdfuwwCowsVeVdsN8U/+BLubr7jL2u33TXbX0pZ9A/2UWF0tHlfYk/mnaUwQBNabpsZUs/0oFldfiRD9s8W4rxMRPy022WSF6S99CzVwGWltWk55sHt/k0/JZVdVhdCsP5cBUJ3Ok6kIICd2sPen/lpbxbrNwoNi+Wm3UKL+CbtvccMTGyezY8ZlTJbc/C8FkuhZJzm4iDbS/c5uamcwNeY/A55WYtVpKL86zgq+w5CUA2oL5pVGHmqTmiOu4ShhCAL7koZOpF8qWs2WasIPMJyOhiM9VM8CMOzZWgE9uxACFf04fIvi6wBJv0swxk7QkVRidhH6JODIyUbT5uk=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BN3PR00MB0083E9A10A58F4CCC7B8A5C6B3680BN3PR00MB0083namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 398c02b2-82f3-405a-ed3f-08d75690aa5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 01:39:22.7361 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QSzR3CuQkP6OoTjBwd2DLJrs/rL7rS638VKZxyO3cOK1lgIPUwLCHfq1LqXRsbuLxtnROgD2EfU5hf3sU0CHPg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR00MB0193
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/BBmnEggu3IkkAVyL6F-CswC-ZvU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 01:39:31 -0000

I'd also prefer to fix the problem, even if it means bringing back something like RETIRE_KEY.

- Nick

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: QUIC <quic-bounces@ietf.org> on behalf of Kazuho Oku <kazuhooku@gmail.com>
Sent: Monday, October 21, 2019 6:31:11 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: Lars Eggert <lars@eggert.org>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Consensus Calls for Transport/TLS issues, post-Cupertino



2019年10月22日(火) 9:42 Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>:
The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!). Absent any pushback, we'll direct the editors to incorporate them next week.

See <https://github.com/quicwg/base-drafts/projects/5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fprojects%2F5&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982835221&sdata=jB%2B7jce%2F4Qj7CRUvUK7OQBLcZwUiQ2ugPJNA2SnDlZ0%3D&reserved=0>> for the current state of issues in the Late Stage process, itself defined at <https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fblob%2Fmaster%2FCONTRIBUTING.md&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982845173&sdata=9lmxgxO8gS8NAyxPDilwgn1LeBqgoBABEh4h7zoyHeE%3D&reserved=0>>.

* #3097: Is CONNECTION_CLOSE ACK-eliciting?
   The proposal is <https://github.com/quicwg/base-drafts/issues/3097<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F3097&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982845173&sdata=ywG1Tb9q4fUHIwRDOnRFmab1bY%2B4uCwQesA111%2FXAWA%3D&reserved=0>>

* #3085: Stateless reset detection should be datagram-based
   The proposal is <https://github.com/quicwg/base-drafts/pull/2993<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F2993&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982855130&sdata=PGbEbWSbA%2BsMiaN8PNv96Bt1fF%2Fj%2F6wSplJuBRml7vc%3D&reserved=0>>

* #3054: Label for key updates
   The proposal is <https://github.com/quicwg/base-drafts/pull/3050<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3050&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982855130&sdata=b5WqdtRz1t%2FKfH4QWudxqnuKET9CL2p1YuTQ5p4rhUQ%3D&reserved=0>>

* #3046: Handling of Retire Prior To field
   The proposal is <https://github.com/quicwg/base-drafts/pull/3096<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3096&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982855130&sdata=YRIcwVV9sR9Yn%2FKPqw%2Fv9tds07rU4r9awQKKtHyg%2FKs%3D&reserved=0>>

* #3037: Require peers to check if RETIRE_CONNECTION_ID sequence number is valid
   The proposal is <https://github.com/quicwg/base-drafts/pull/3036<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3036&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982865085&sdata=0yIMdKA5L5GVX%2Bn0fwd57VX%2FPeQteXWo7rG3QKUVb9o%3D&reserved=0>>

* #3027: Codes for frame encoding errors
   The proposal is <https://github.com/quicwg/base-drafts/pull/3042<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3042&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982865085&sdata=xAFv60554CFXTY2skAcJbLdj%2BxnhvJJI9FsrQUIG9Ws%3D&reserved=0>>

* #2944: Layout of PreferredAddress
   The proposal is to close with no action.

* #2928: Lift single-packet ClientHello requirement?
   The proposal is <https://github.com/quicwg/base-drafts/pull/3045<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3045&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982865085&sdata=3oZHg77Z%2Fk0e8E8O9rZdlStcvN%2BhqEd3e3kEXPyNW9s%3D&reserved=0>>

* #2863: unrecoverable loss pattern leads to deadlock
   The proposal is <https://github.com/quicwg/base-drafts/pull/3121<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F3121&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982875044&sdata=2Hcsmy6VVVeZwWTRCcPm%2F9NfjXGgYctNw%2FktWswy4e4%3D&reserved=0>>

I feel sorry but I object to the proposed approach. As I have pointed out in my comments in #2863, not discarding the Handshake key forever breaks our assumption that no Handshake packets will be sent or received once the handshake is confirmed. We missed that there are these side effects when we rush to the conclusion at the end of the interim.

Specifically, we'd be required to define how Handshake packets deal with migration (does the path for Handshake packets change? If it does, how do we fill in the SCID field of the Handshake packet? If it does not, until when do the endpoints need to retain the original path?).

I think we should fix the deadlock, rather than changing other parts of the protocol that currently depend on the Handshake key being discarded at some point.


* #2823: Do Initial secrets change after Retry packet?
   The proposal is <https://github.com/quicwg/base-drafts/pull/2870<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F2870&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982875044&sdata=4boCzjNG9GOOIhdxKzuJVMvxK4UANTkFApQsSVexoaU%3D&reserved=0>>

* #2741: Re-visit initial keys discard
   The proposal is to close with no action.

* #2152: Why does stateless reset have to be checked after MAC failure
   The proposal is <https://github.com/quicwg/base-drafts/pull/2993<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F2993&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982884999&sdata=4t3wu7IoW44SjJNkxJSKJZ8Lo23YtF%2FCM4%2FE%2B%2FW89FY%3D&reserved=0>>

--
Mark Nottingham   https://www.mnot.net/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mnot.net%2F&data=02%7C01%7Cnibanks%40microsoft.com%7C792ac24eb30d48387a8508d7568f93de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637073046982884999&sdata=YlH%2BenfkuPhwh0GMcRkRlpqxG%2BChyG9bGtYQ9huP6wo%3D&reserved=0>



--
Kazuho Oku

v2.23.0 | Report a Bug | By Email