IETF Logo Mail Archive

Re: KEYS_READY

"Martin Thomson" <mt@lowentropy.net> Thu, 14 February 2019 21:02 UTC

Return-Path: <mt@lowentropy.net>
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 AB3AF1311DD for <quic@ietfa.amsl.com>; Thu, 14 Feb 2019 13:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=gB1hQY8v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wtvkGwju
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 gj9UvoCB90OM for <quic@ietfa.amsl.com>; Thu, 14 Feb 2019 13:02:53 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DE41311F2 for <quic@ietf.org>; Thu, 14 Feb 2019 13:02:52 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 23FF62054D; Thu, 14 Feb 2019 16:02:51 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 14 Feb 2019 16:02:51 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:cc:subject :content-type:content-transfer-encoding; s=fm1; bh=mYdzX4idUy26U uK7M+QSGAmxX7UdiBm7x8wBwTJOAqU=; b=gB1hQY8v0MPrIs+rtNjlS5eM5/i21 TnSBDdiTKWmKWWLkwIMLaD9BW1MZwUFmifyxAMYts5QqS3l/blsa4sk8AFLbUcNR iJbpMci/9K6z6uAOhNc4vV3AZ5SIe0UVezssREe+mDU9wauEkIuO8LCLEn9qQ/zF iI5YQ++gHqB83073pU/azbyMAeINhQErcIC27dlz4gVxzbftKPu9bw2CSPdnioLL XGfTccIgdeMDkbDhhGFVpD7TNiQ2I6QTS3OvwZ6q3Q0cVQLWj7rOOQ1y5Y0mUPmo dJeStNtiUc+TTDgd3po9FeVH/ukYYyYXNYETr5z4jr3iW8Ht4DnHxLFlQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=mYdzX4idUy26UuK7M+QSGAmxX7UdiBm7x8wBwTJOAqU=; b=wtvkGwju atYgHQE2hlZifwWpSRYQyQV/9DwMw4KnYFvsaOmeHcMF2L5LAwKHtN6XpdXGI0JY LgX2/5kYV0W59fjd3lHF5es45XNujA81xsKUdlJmW4pvY64/ydvz65KaWrznHrwi lleEiczN3KhnijXu2sDWdreHeKr91XLQcs7G0M3mYZPor7nYeSCGDIgMXw70kq3V mD6YwhGznpBOpFAJtIUddL+1/e1KpqaRYPVztGsHqd0fh03CvK9EZ7nFPzeSwwH0 y3ZJH9Rw0gnjGNBf4/bBkU34KG5f7wpVmyEukENoCTQXC6TdIcGMEwurcEfjVWro Zfq7OTFvpX4q2g==
X-ME-Sender: <xms:etdlXH1TcwVxvfmefdVGD6-djaSMFSKq3vgTVnFjWV6fOP9ESdpBMQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfh ffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshho nhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfh hrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgep td
X-ME-Proxy: <xmx:etdlXBf5l2pUwUFFhGDXo29TRmFyeNZMtj2rz3nOHdlPMMnZUhEUyA> <xmx:etdlXBS_ZKxutaeZ3UydBZNzNm7Ng7KebP8q6ogjxfE3VVL-tGo3gQ> <xmx:etdlXEmbbNxDSSBOPzM67etB_-TZMqo3ChxODLWSZhQ9IUk51RiBwg> <xmx:e9dlXKrazvDRmTEKhxN0g9ePPZjt6VsvOx-T7Dsi9lYMLCQvkBjvSA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 24F317C1EB; Thu, 14 Feb 2019 16:02:50 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1
X-Me-Personality: 92534000
Message-Id: <f2e59f1c-b7d5-49ce-affc-7d16684a048a@www.fastmail.com>
In-Reply-To: <CAPDSy+4=YYyTe5=85X09e1kAB7TrmmNXK-2wnLZubfS1ekWRJA@mail.gmail.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> <MWHPR22MB0991FCD3ADA97790B238E491DA670@MWHPR22MB0991.namprd22.prod.outlook.com> <CAPDSy+4=YYyTe5=85X09e1kAB7TrmmNXK-2wnLZubfS1ekWRJA@mail.gmail.com>
Date: Thu, 14 Feb 2019 16:02:50 -0500
From: Martin Thomson <mt@lowentropy.net>
To: Mike Bishop <mbishop@evequefou.be>, David Schinazi <dschinazi.ietf@gmail.com>
Cc: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, Marten Seemann <martenseemann@gmail.com>, Jana Iyengar <jri.ietf@gmail.com>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>
Subject: Re: KEYS_READY
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DADiY_yuXxGAApbYSKcGegEK3hI>
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 21:03:02 -0000

Please explain how the two differ, because I'm not seeing a difference.

On Fri, Feb 15, 2019, at 07:42, David Schinazi wrote:
> I think RETIRE_KEYS solves both problems. I don't think KEYS_READY does.
> 
> On Thu, Feb 14, 2019 at 12:38 PM Mike Bishop <mbishop@evequefou.be> wrote:
> >  
> >  
> >  
> > 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> 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