Re: KEYS_READY

"Martin Thomson" <mt@lowentropy.net> Fri, 01 March 2019 03:37 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 DA29B130F5F for <quic@ietfa.amsl.com>; Thu, 28 Feb 2019 19:37:29 -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=j6mhtZSX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q5t+AjlF
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 3STftZo7Q3tX for <quic@ietfa.amsl.com>; Thu, 28 Feb 2019 19:37:27 -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 393C0130F15 for <quic@ietf.org>; Thu, 28 Feb 2019 19:37:27 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4C46A22291 for <quic@ietf.org>; Thu, 28 Feb 2019 22:37:26 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 28 Feb 2019 22:37:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=M8kxfLSOxVtKy j0ZaToFy4Nkkp31PlPJfwqndOtz59Y=; b=j6mhtZSXzv9wUKYtN1/g5hyroRoVn OHXwVz61ZsSUjxspVOmCebAs/1sYBHfvcfTrX2EXCaDR1Bt5zSQ+qp7g6r75EBfL q245I7G0QAc7iPQ3l/Hw9p4wztPF8ij+u97Ubm1l5hn9tSXnb1IMmwZWrue5PeiS Zlp625zUl4R0gsrwFzLi+cUVO1QTx6a2KS2ugpqkrXPbEPS1xw5G8oNTDlczgDNI eMHcpkVQQqv+wUo0qL+W8wr/PdrkIWxdum8Zes85VCPJaDSB5rUShBE5YUR9cGnE 1fha+/5kREylG7j/xyK6T97j+E1ijS0ka7r2FV0ZV840Mq/RViApDef3A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=M8kxfLSOxVtKyj0ZaToFy4Nkkp31PlPJfwqndOtz59Y=; b=q5t+AjlF 0fA67eRVoqvTe/duQdb/raFeQfPOylcOhZg1s8A12UXkg40KoTbd4wstvL6BdYbc 6Aux9/v7Pia+2S9BPPpMQUp4JxvTsv4aJ+WeOEtHXkRpMogWnAD6+qKgxoQwx66m tEfWnpLtX66rYQ4JruCpki8VEoiNbUAUtuFe0kwtx/cRRtI2WTFSR33AIo1jGw7u qc4Gr0YpVe0Pga9ZrlwHWlBYuFN1o/ttifQMFwiL1gOSA+xZPSxrpwwrQaZH9Ugv mRtl2GtTuFpQ7KAQRzLx1Zuy3WWebVfp+Uq/4YP+V4dzi6lqxSnC3Eek2QzuTSIh oKO3GH2U9lw0oQ==
X-ME-Sender: <xms:9ah4XEn_-1HEkdqoofAqP7v082pQwapQrx6-QyQR_YOj7Ke1pemx2Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdeggdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:9ah4XCRFtsg5b13CuxbhiOqQ162Y442eJ9K3WJQDhnm_eJeohHr5yQ> <xmx:9ah4XFZTn0nxyWkVhSRP2ZUTvU9RaU2X_Xi-1i1Lpx32tH0vICGTag> <xmx:9ah4XFaFdDxMhoaA6OEGy8Y7oKMEl0RzBjQm-5lUaPoYGGlXHhGtqA> <xmx:9qh4XBQcW4paz232U3hrnSus84YViv341Rg97h3Xu1fXV2r82JmGzg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id BD42F7C1EB; Thu, 28 Feb 2019 22:37:25 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 92534000
Message-Id: <7879ac68-5a8e-4b5e-a81f-03b851be8328@www.fastmail.com>
In-Reply-To: <CAPDSy+4kFMhpyHrvcQhT+rwnwfraOb0eBs=eOQPTNGWWJV51Kg@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> <f2e59f1c-b7d5-49ce-affc-7d16684a048a@www.fastmail.com> <CAPDSy+4sKR99Fwqt+08JevAmC7E4LUSohUrQgVc+5BA56CLEkQ@mail.gmail.com> <b4364dee-a429-45c5-8b56-b82269f1ab2e@www.fastmail.com> <CAPDSy+4idHMDpNya42K5fxRQ6tFUoOXz9bi8K2eU8u-xRiOB3g@mail.gmail.com> <045bbf5b-04e4-4f9f-886b-f7ff9254bdab@www.fastmail.com> <CAPDSy+4iTM1wYpr04fmqOULct5LrB4UnDiPz_K9vGSd3oB=4eg@mail.gmail.com> <CANatvzyoEJZBWhBEBLMcysv_GTEKHup02++RAj_XX+SztVQm1g@mail.gmail.com> <CAPDSy+4kFMhpyHrvcQhT+rwnwfraOb0eBs=eOQPTNGWWJV51Kg@mail.gmail.com>
Date: Thu, 28 Feb 2019 22:37:25 -0500
From: Martin Thomson <mt@lowentropy.net>
To: 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/7Z6Pjatf8XaoO_ldXmwLRhIHSNA>
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: Fri, 01 Mar 2019 03:37:30 -0000

I don't get it.  This is the same proposal.  With fewer editorial changes, perhaps.

On Fri, Mar 1, 2019, at 11:30, David Schinazi wrote:
> Since this conversation has quieted down for two weeks, I went ahead 
> and wrote up the RETIRE_KEYS proposal:
> https://github.com/quicwg/base-drafts/pull/2492
> 
> I believe this is simpler to reason about than the KEYS_ACTIVE proposal 
> and safer as it makes less assumptions about the handshake protocol.
> 
> Please let me know what you think, and I believe we should keep the 
> discussion here instead of on the PR.
> 
> David
> 
> On Thu, Feb 14, 2019 at 5:51 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
> > 2019年2月15日(金) 9:18 David Schinazi <dschinazi.ietf@gmail.com>:
> >  >
> >  >
> >  >
> >  > On Thu, Feb 14, 2019 at 3:45 PM Martin Thomson <mt@lowentropy.net> wrote:
> >  >>
> >  >> On Fri, Feb 15, 2019, at 09:47, David Schinazi wrote:
> >  >> > This means that the server sends KEYS_ACTIVE(1-RTT) not when the 1-RTT
> >  >> > keys are active,
> >  >> > but instead when the handshake finishes, which is when the server has
> >  >> > received the client finished.
> >  >> > Those are two different moments in time.
> >  >>
> >  >> Yes, because the keys aren't active when the server starts sending 1-RTT packets. They are only active when the server starts reading 1-RTT. The server can't activate its 1-RTT reading keys until the handshake is complete.
> >  >
> >  >
> >  > Ah, thanks. Looking at it this way it makes sense to me - we may want to make the text clearer in case I'm not the only one who was confused.
> >  >
> >  >>
> >  >> That's why I chose to name this KEYS_ACTIVE(this), not RETIRE_KEYS(prev), but I don't really mind what it is called.
> >  >
> >  >
> >  > I don't feel strongly about names either as long as they make sense - and now KEYS_ACTIVE also makes sense to me - so either name is fine by me.
> >  >
> >  >>
> >  >> > My proposal is to have the client decide when it is done with the
> >  >> > handshake keys by having the client
> >  >> > delay sending RETIRE_KEYS(Handshake) instead of the server delaying
> >  >> > sending KEYS_ACTIVE(1-RTT).
> >  >>
> >  >> This requires that the client send more Handshake packets. And it adds a lot of delay because the client has to wait until all its packets are acknowledged. We previously agreed that any such signal from the server is more direct and effective.
> >  >
> >  >
> >  > I don't think it means more handshake packets. And it's still a direct signal between endpoints. The only difference is that the client-to-server RETIRE_KEYS message is delayed by one RTT compared to its KEYS_ACTIVE message so the server will wait one RTT before throwing away handshake keys. But it has the advantage of not requiring any implicit ACKs. So the tradeoff we're facing is between allowing the server to throw away keys sooner at the cost of making implicit decisions. This implicitness means KEYS_ACTIVE does not allow the client to be able to send anything in Handshake after the ClientFinished. I'm worried that might prevent protocol changes down the road.
> >  >
> >  > I'm still in favor of paying the one RTT before key deletion to make the protocol more explicit.
> > 
> >  I share the same view.
> > 
> >  Admittedly, it means that then the frame would no longer be useful for
> >  dropping the Initial keys, assuming that we want to drop them ASAP as
> >  we do now.
> > 
> >  But even with that downside, I think it makes sense to delay when the
> >  handshake and each generation of 1-RTT keys are dropped. After all, we
> >  can argue that the requirement for when to drop the Initial keys is
> >  exceptional due to security concerns.
> > 
> >  Hence something like
> > https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw.
> > 
> >  -- 
> >  Kazuho Oku