IETF Logo Mail Archive

RE: KEYS_READY

Mike Bishop <mbishop@evequefou.be> Thu, 14 February 2019 20:38 UTC

Return-Path: <mbishop@evequefou.be>
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 66E2A1311B6 for <quic@ietfa.amsl.com>; Thu, 14 Feb 2019 12:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=evequefou.onmicrosoft.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 2WU0npzWzFYX for <quic@ietfa.amsl.com>; Thu, 14 Feb 2019 12:38:53 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760093.outbound.protection.outlook.com [40.107.76.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A085612D4F2 for <quic@ietf.org>; Thu, 14 Feb 2019 12:38:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g6vvXxJ8tQRJGMwzUpgLHfSTW4oTfE/tpxFsZJbG0/I=; b=Yi+XxJlYSPlTgHnv0IN6yR6YNiDlnV00K6UXZkGfBEQkB25HBa3zAX7zqr5qUQxS712pXk7CXBiQgoc58DarR3s7PmU9FAxErgxL2seJJEyI2dx9dSOohNVkCuJHC2M9ripjhr4ol/tgnmCwWtEF0UUVoKVFlxHg51YdHmWd4lQ=
Received: from MWHPR22MB0991.namprd22.prod.outlook.com (10.171.145.21) by MWHPR22MB0093.namprd22.prod.outlook.com (10.168.249.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.22; Thu, 14 Feb 2019 20:38:49 +0000
Received: from MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e]) by MWHPR22MB0991.namprd22.prod.outlook.com ([fe80::31b1:b2c0:74a2:772e%5]) with mapi id 15.20.1601.023; Thu, 14 Feb 2019 20:38:49 +0000
From: Mike Bishop <mbishop@evequefou.be>
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>
CC: Marten Seemann <martenseemann@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>
Subject: RE: KEYS_READY
Thread-Topic: KEYS_READY
Thread-Index: AQHUwz3pxR+WCqZrW06dl1IlLgtz0aXdOu0AgAAs74CAAEmagIAAIpCAgAAGk4CAAAC7AIAABWuAgAAB3gCAACgNgIAAQIGAgABJrACAABS8gIAABsIAgAADhICAAAt+gIAABh+AgAAENYCAAABqAIAAzM8AgAAr64CAAACDUA==
Date: Thu, 14 Feb 2019 20:38:49 +0000
Message-ID: <MWHPR22MB0991FCD3ADA97790B238E491DA670@MWHPR22MB0991.namprd22.prod.outlook.com>
References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <CANatvzy_juza_meGR_-KuBV9FA=F754mv54aawxMb8hYWxb1gA@mail.gmail.com> <CAN1APdcVYKWuapZ3XHxXa_nVACwkRD-xeF3ub-5ROttE7QVrmQ@mail.gmail.com> <CAOYVs2ooxAuwu_zr2XZ-y9UqUP5kTbjoFrckAOi40bF9vODGOg@mail.gmail.com> <CAKcm_gNk=jKrnXM4Ht4yF0RX25wtVifjxz0c1gay0uie7PMw6A@mail.gmail.com> <CANatvzxBYzEaDZ1Ftt=o1zT5zVcVTd1EwtGiJOC-mkrNUWzVAQ@mail.gmail.com> <CAN1APdfzepc9DE98UsWw=hB4dM38qKLxdAjpsYuddDBatcscDA@mail.gmail.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <CAN1APddWLdmRo+ZZDnmvrBEFQk4TTcS3UK_9AU4KqAeSkiBvJQ@mail.gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <CANatvzxoOFzpkcH_4VpQscpZq8ak0QL0D6REvyJVjE+ga97SVQ@mail.gmail.com> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <ae018a6d-4c9a-acc7-4213-21d1670f9dad@huitema.net> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <CACpbDcfbEcg70RwpFrCQ2X6WA0Dd7ygd=Q0w7iwKc-ZgZQbZ0w@mail.gmail.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> <CAOYVs2qQJgGNhXJNjhE8L=wxBgq+3qs144WYXs0JoWNBrK_a6A@mail.gmail.com> <DB6PR10MB1766128EAD7248F02C1EAFA5AC670@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <DB6PR10MB176684E61A66BF01C66008F6AC670@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <CAPDSy+5MSST-Nkoi+oaRzSLDJCYqhUmKw1nP_p4fOyq7cfK17w@mail.gmail.com> <CAJ_4DfRKrYOyozbp4GmPNODnZ_sKTECXbMa5Vsuxa4zmubERHQ@mail.gmail.com>
In-Reply-To: <CAJ_4DfRKrYOyozbp4GmPNODnZ_sKTECXbMa5Vsuxa4zmubERHQ@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=mbishop@evequefou.be;
x-originating-ip: [38.134.241.6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b0946074-be9f-45e1-5fa0-08d692bc6cc7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0093;
x-ms-traffictypediagnostic: MWHPR22MB0093:
x-microsoft-antispam-prvs: <MWHPR22MB0093A972AFBB7BDC20895664DA670@MWHPR22MB0093.namprd22.prod.outlook.com>
x-forefront-prvs: 09480768F8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39830400003)(396003)(376002)(136003)(366004)(199004)(189003)(3846002)(561944003)(66066001)(7116003)(25786009)(26005)(790700001)(6116002)(7736002)(53936002)(229853002)(86362001)(66574012)(55016002)(6506007)(53546011)(97736004)(6246003)(316002)(102836004)(106356001)(33656002)(6436002)(9686003)(105586002)(54896002)(6306002)(236005)(4326008)(256004)(446003)(11346002)(14454004)(476003)(2906002)(71200400001)(71190400001)(68736007)(54906003)(110136005)(74482002)(8936002)(14444005)(74316002)(81156014)(8676002)(76176011)(81166006)(486006)(508600001)(186003)(93886005)(7696005)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR22MB0093; H:MWHPR22MB0991.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts)
x-microsoft-exchange-diagnostics: 1;MWHPR22MB0093;23:ORMAYvlUZD/u0Hs6F5lm08SXsx9ZmJ77xUnXcHRj/DAbyZcQbIGmdt6/7tjn9F+JiXhFMuxSS0SVUHnLyCLbs0frJGwaE7qktIKU09nB9IbgGCDvqRgscSvEBgWvIzCi/y6nR3v4td2x8n39sCMElFAdeH/ANDlD4lVlPAWQ6zdU26oVMuNEl8M0n/2BMpUeNb3UlgwmoNC9rDvLrW5+cDu+I6qDXnbMHxxK5vyO7bDduC7mdDcpny3Wykf8l3LMHwIlh3tHmbNdvXO5ukh7Qy+LLmeEUfQJlHOlZFqOTMzTPuG8JcAFD4F0qsPhr50fotw7LrwN9BwSWyPM0drNdoeqfFY9uRTkl69669jCOOpLvaNJzvsLrV0r6qhCHdye2GqO1PalQs2dXFCFmaDIum3Mfb9fPBsSsTX41KVPCssYieDdn3wPnicBMZAIiX5J30Gar2RyytvQ7Z1cYqatuLp2I109hKo7F8z4uxH0YD9HFX+RxzMi2QgeyoN0tXRl/LqYM+dDP2JLWpOru0tCdvOkp4kN3y1WM8DM1m+yjSfE7MVJFX6TiiWI4oscAXRvAgPajB/WNW/ogBJKiClhkF31GcMeopRPxX5VCyXQgvZss4zS9urGyPeQgo3w8zTeFR1Hk/bJBFXWIrCSYx0iFzkyDK2S24/qaIIELGH/tyrelkS4dL/TdTInE3hCurrNYDK9elUnbnsmyarYnrVaAuKey3lP/StJel9KweSKxxCDgSrJ7YHjBY0oXufvAc6ZyqLuHxrd+rXeEL+e2tewVff3MUz8ATVWPhVm6xP+1NLZAt7tT5mXfQsfEACQn1ZLdifpW1oa1NHqzjpc7V/VL5hDFzRCm+d/gPrpG8hPbCZQb9B/i3eFocxxPjkElUPjf6YgX9CCPg4+7xOdXKSPQ/t8yZI5vX5UJtmJmFnV+Bm5lLtWrNvPVdVHSlFP4/1+Ps6SIxxhlvPc814IKsxiGZFRzni5rD/HF7pWYDavpPxA/rbbOzg/ifhtdDpvKSIw8H5VbhLQ/na7SM/Oo3pC8iDlRkdPeQ6YMllm6B0267BB4WX1bYwEIKPkYbTWnmrz5Fe0N3eBgoLUgQLEz6gij0PgA6iW1VUNT/f1sxMe3s09wkI++0pVONJ9biA/TDN5RyTnEHjqvIA5INeaaM/+Ax+C0l/k3Bg1Tyms+VIWSfuV5JcHJsLwV9JO6piw0d2IOXndjd+Dlry/SE7swvVDvlBSZlgPZr/bzSBD2X/lM4ag2ZlxkQd8pZEKyTyxyfrwqXKuV536d1Jqx0fBITC2sgEwn9K2XXmdiCdknoyxiRTuyEbbJBJg5vHQ501jjTu8Lpt1wnJ8vgzM2hc88xAv01SDFafo8V36UU9h+qfR/Y4=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ZH8ZPFOjf3l0VzlB8xRYPYFzsr4B/1HmN7aNJsFMOkZIB2qQoKLetOWAeLua4ieal0ucMzibb+KUvXPW81nc8GUTdJ0JHFT45VotHJUxkmNzY05KxYozY2yKq6cumju8Y0NYDlbfu4yAfWZdc0SHCOB4hUn2F9SuUHFaxKkS3OksjgZzle3GsqmGHdKkrzhgZkBuoWDANqg0ekp5q8+ZHUUKF3fbzFfn90BVGxiX+lZJGYH3zDgoGgtylNwGv9UC2HZRZo0ENQAKRbJtRjC3iRzRk5poXVBajiqIuLBpM7s0DHmCO5Nu0AVfKXMjrK+sgqtkXV1FprrL9rAV3RA7xBwY5LqJnnrx3JWRxpTga7D2uMh3eZS82UUP87OdUKR6wAyQmcV0heopVJxA9VctLWDUR+AI1Nvj7ig5iL7Gl40=
Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0991FCD3ADA97790B238E491DA670MWHPR22MB0991namp_"
MIME-Version: 1.0
X-OriginatorOrg: evequefou.be
X-MS-Exchange-CrossTenant-Network-Message-Id: b0946074-be9f-45e1-5fa0-08d692bc6cc7
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2019 20:38:49.3964 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0093
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/f1HXrRRrXl2yTdr12VaNhroQ9Ds>
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: Thu, 14 Feb 2019 20:39:00 -0000

The question is whether the same mechanism can/should be used for post-handshake key updates or if two separate mechanisms are needed.  They’re very similar problems, but it seems as if the requirements are slightly different.

From: QUIC <quic-bounces@ietf.org> On Behalf Of Ryan Hamilton
Sent: Thursday, February 14, 2019 12:34 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Marten Seemann <martenseemann@gmail.com>; Jana Iyengar <jri.ietf@gmail.com>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; Martin Thomson <mt@lowentropy.net>
Subject: Re: KEYS_READY

On Thu, Feb 14, 2019 at 9:57 AM David Schinazi <dschinazi.ietf@gmail.com<mailto:dschinazi.ietf@gmail.com>> wrote:
I don't think the proposed PR matches what we discussed in Tokyo, and it seems less robust than what we discussed.

In Tokyo we had discussed a RETIRE_KEYS frame with the following properties:
1) You send RETIRE_KEYS when both (a) you have sent everything you wanted with those keys AND (b) that has been ACKed
    In particular, the client sends a 1RTT packet with RETIRE_KEYS(Handshake) when the server ACKs the packet containing the crypto frame with the ClientFinished
2) You can discard keys (and congestion control state if applicable) when you've both sent and received RETIRE_KEYS

The proposal in PR#2237 does not have these properties, because it focuses on the new keys being ready instead of focusing on when an endpoint is done sending with previous keys.
In order to avoid the client infinitely retransmitting ClientFinished issue, PR#2237 has the server delay its 1-RTT KEYS_READY until it believes the handshake is complete.
It would be more robust to have the endpoint who is sending decide when it is done sending, instead of having the peer assume it knows.

I completely agree with this. The usage of RETIRE_KEYS, as outlined here and in summaries of the discussion in Tokyo that I read, seems simple and clear.

v2.23.0 | Report a Bug | By Email