Return-Path: 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 3F8BC128CE4 for ; Thu, 14 Feb 2019 09:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.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 JBqSb4_h8tje for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB5312867A for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n22so3469307pfa.3 for ; Thu, 14 Feb 2019 09:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WnwusM2M4J0YHNmFijlsdXfmdWexIMXVo1Zl7xvSsqA=; b=cACxjy0rqeKdxtERHTyux2/54ZyUk7+HpwXgU0ME8rvwWJSjAkBZXXc4EIKFXoJtLt h1RTYRZCkkRrJHXiYTbAl19nixyg9ombcoRFRVDTFOmR5Xy42c/yzOfmhsoKjZYGH6RI ubY7UcZDLa/uwJw0YwtpE+sDJiNiVrFXypxltYpmREGwOay6e+lTqJ9KaqENt83joiXU xIyEunh9WKCkDzEjE88SsxOBa31t5EDsGDnS4fNTHbX0cUDYGY5krs6J34i6K1kvWbfW tl6v02hoMXuluag7UyIg+Q//GT3Yq6FaNMgBC3nuEfj1fWcV7To6WOHUwrrKgHh0d3NO NRVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WnwusM2M4J0YHNmFijlsdXfmdWexIMXVo1Zl7xvSsqA=; b=ZG84gusQG09KOGXrvUMqn3PwdayeX5tIVrwQHEHrFGNHKe/rXG7gvhIId+1qhieBoU A0AJCkPCKjkNgrmoFKT7Z188o1pCsjFQkmhSNmdVqx9H93oLS1l7pA7Esj33cPJtYcq8 LmqnK7dFJUYBrYTLl3cOt5CbH47SlZQ2RhLn/sqTBUQRLOsLg6nZY5lPAbQSrvOlvcvY bYa8e8e3rW2p0Xc+oe0F95Mkd15gQRdLIsyH67vxeK4pZaqVNRfChuUeCj05rwOrx5j/ 04H1WTKXi/dJQJWvrTWcQIKR6XeCIX0cM6g8H+OqzPG1dEUfIJReJHh+iVzoSo/Vpudq AM0w== X-Gm-Message-State: AHQUAuZJTVNxNq6ubaoPomGdd6wsTJbSCKik9bJtOEkgNqBxTtMxDSs4 aY5FbCgssUOhPkp7zWIpuG9rr5oXhC2C0TtwZSI= X-Google-Smtp-Source: AHgI3IYT6lT7TFFmtJdxC4xlWS5vf7tbch0X1qxKErhOiN77esHji4aTFieQrkgGZgiY1BoU3gk5cGG3xHLDaIC+9PI= X-Received: by 2002:a63:1753:: with SMTP id 19mr1045892pgx.439.1550167034426; Thu, 14 Feb 2019 09:57:14 -0800 (PST) MIME-Version: 1.0 References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com> <1550117510.928793.1657684264.41D049FA@webmail.messagingengine.com> <1550120733.954579.1657700168.72A8F92A@webmail.messagingengine.com> In-Reply-To: From: David Schinazi Date: Thu, 14 Feb 2019 09:57:02 -0800 Message-ID: Subject: Re: KEYS_READY To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Marten Seemann , Martin Thomson , Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="0000000000006dfc000581de63b6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:57:17 -0000 --0000000000006dfc000581de63b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. David On Wed, Feb 13, 2019 at 9:44 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I guess because ACK? > > > ------------------------------ > *Fra:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Sendt:* torsdag, februar 14, 2019 6:42 AM > *Til:* Marten Seemann; Martin Thomson > *Cc:* Jana Iyengar; QUIC WG > *Emne:* Re: KEYS_READY > > Why do keys need to be in sync? > Disregarding handshake, if each peer has a separate key index counter, at > change in phase bit ought to be sufficient. > > The endpoints can have vastly different consumption rates. > > With sync keys the peer can prevent you from updating while uou can updat= e > after ca 3 PTO in the async design. Neither design can force the peer to > update. > > > ------------------------------ > *Fra:* QUIC p=C3=A5 vegne af Marten Seemann < > martenseemann@gmail.com> > *Sendt:* torsdag, februar 14, 2019 6:27 AM > *Til:* Martin Thomson > *Cc:* Jana Iyengar; QUIC WG > *Emne:* Re: KEYS_READY > > > I was OK with that PR, and while we might go back and forth on the > merits of using a bit vs. a frame, the consensus in Tokyo was that the > frame was superior. Also, this solves more problems. > > In my understanding, the consensus in Tokyo was based on the assumption > that the bit and the frame were basically signaling the same thing - at > least I wasn=E2=80=99t aware of the additional retransmission logic neces= sary, and > I would=E2=80=99ve opposed this solution if I had known. > > > The PR changes how Initial keys are retired. Instead of relying on the = delivery > of Handshake packets, it relies on the delivery of KEYS_ACTIVE frames. > However, we do not require KEY_ACTIVE frames to be included in every > Handshake packet being sent. > > This is again the problem of a discrete vs. a continuous signal. Using > another bit in the first byte solves this problem. > After the handshake completes, we want the peer to advance from handshake > mode to normal mode in the loss recovery logic, since in handshake mode w= e > don=E2=80=99t have PTOs. The only way to achieve this using the KEYS_ACTI= VE frame > is to include it in multiple (all packets for one RTT?) after the handsha= ke > completes. > > That being said, adding a generation number as Kazuho suggested seems to > be the second best solution, since it at least removes the necessity to > implement separate retransmission rules. > > On Thu, Feb 14, 2019 at 13:05 Martin Thomson wrote: > >> On Thu, Feb 14, 2019, at 15:24, Jana Iyengar wrote: >> > (I've left this comment on the PR as well, but seeing that this >> discussion >> > is happening here as well, echoing it here) >> > If the peer hasn't acked the previous KEYS_ACTIVE, it may not have see= n >> it >> > yet. It is possible that it simultaneously did a key update and sent a >> > KEYS_ACTIVE however. Under this condition, the endpoint wouldn't be >> able to >> > update its keys again, since the peer may close the connection, right? >> >> This is not a problem, but it requires thinking the process through. >> >> An endpoint can only initiate a key update if it has received >> KEYS_ACTIVE. It can only send KEYS_ACTIVE if it has received a key upda= te >> (and is either responding, or initiated that). >> >> Take the example where an ACK is lost, so a key update occurs when one >> peer is retransmitting KEYS_ACTIVE: >> >> C: Update to Key Phase 1. >> S: Update to Key Phase 1. Send KEYS_ACTIVE. >> C: Send packet containing ACK for the server packet containing >> KEYS_ACTIVE, plus KEYS_ACTIVE. That packet is lost. >> C: Update to Key Phase 0. >> S: Update to Key Phase 0. Send KEYS_ACTIVE. >> >> The server might believe that its KEYS_ACTIVE hasn't been acknowledged, >> but it has to be prepared for a key update as soon as it sends the frame= . >> >> If there is a simultanous update it looks like this: >> >> C: Update to Key Phase 1. >> S: Update to Key Phase 1. (Concurrent with previous.) >> C: Receive packet with KP1. Send KEYS_ACTIVE. Lost. >> S: Receive packet with KP1. Send KEYS_ACTIVE. >> >> At this point, both peers are fine, they are on the same keys, and a key >> update can be triggered by the client. The server can't update until th= e >> client repairs the lost KEYS_ACTIVE frame. This continues: >> >> C: Update to Key Phase 0. >> S: Receive KP0. Update to Key Phase 0. Send KEYS_ACTIVE. >> >> As you can see, the client stops sending when it updates again, but >> that's OK. >> >> It's also safe if the KEYS_ACTIVE frames get through, but acknowledgment= s >> for them don't. >> >> --0000000000006dfc000581de63b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think the proposed PR matches what we discusse= d in Tokyo, and it seems less robust than what we discussed.

I= n Tokyo we had discussed a RETIRE_KEYS frame with the following properties:=
1) You send RETIRE_KEYS when both (a) you have sent everything y= ou wanted with those keys AND (b) that has been ACKed
=C2=A0 =C2= =A0 In particular, the client sends a 1RTT packet with RETIRE_KEYS(Handshak= e) when the server ACKs the packet containing the crypto frame with the Cli= entFinished
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, be= cause 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 t= he client infinitely retransmitting ClientFinished issue, PR#2237 has the s= erver delay its 1-RTT KEYS_READY until it believes the handshake is complet= e.
It would be more robust to have the endpoint who is sending de= cide when it is done sending, instead of having the peer assume it knows.

David



On Wed, Feb 13, 2019 at 9= :44 PM Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
I guess because ACK?

=C2=A0
Fra: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Sendt: torsdag, februar 14, 2019 6:42 AM
Til: Marten Seemann; Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
=C2=A0
Why do keys need to be in sync?
Disregarding handshake, if each peer has a sep= arate key index counter, at change in phase bit ought to be sufficient.

The endpoints can have vastly different consum= ption rates.

With sync keys the peer can prevent you from u= pdating while uou can update after ca 3 PTO in the async design. Neither de= sign can force the peer to update.

=C2=A0
Fra: QUIC <quic-bounces@ietf.org> p=C3=A5 vegne af Marten Seeman= n <martense= emann@gmail.com>
Sendt: torsdag, februar 14, 2019 6:27 AM
Til: Martin Thomson
Cc: Jana Iyengar; QUIC WG
Emne: Re: KEYS_READY
=C2=A0
> I=C2=A0was OK with that PR, and while we= might go back and forth on the merits of using a bit vs. a frame, the cons= ensus in Tokyo was that the frame was superior.=C2=A0 Also, this solves more problems.

In my understanding, the consensus in Tokyo w= as based on the assumption that the bit and the frame were basically signal= ing the same thing - at least I wasn=E2=80=99t aware of the additional retransmission logic necessary, and I would=E2=80= =99ve opposed this solution if I had known.

>=C2=A0The PR changes h= ow Initial keys are retired. Instead of relying on the=C2=A0delivery of Handshake packets, it relies on= the delivery of=C2=A0KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be=C2=A0included in every Handshake packet being sent.

This is again the problem of a discrete vs. a= continuous signal. Using another bit in the first byte solves this problem= .
After the handshake completes, we want th= e peer to=C2=A0advance from handshake mode to normal mode in = the loss recovery logic, since in handshake mode we don=E2=80=99t have PTOs. The only way to achieve this using the KE= YS_ACTIVE frame is to include it in multiple (all packets for one RTT?) aft= er the handshake completes.=C2=A0

That being said, adding a generation number as Kazuho sug= gested seems to be the second best solution, since it at least removes the = necessity to implement separate retransmission rules.

On Thu, Feb 14, 2019 at 13:05 Martin = Thomson <mt@lowen= tropy.net> wrote:
On Thu, Feb 14, 2019, at 15:24, Jana Iyen= gar wrote:
> (I've left this comment on the PR as well, but seeing that this di= scussion
> is happening here as well, echoing it here)
> If the peer hasn't acked the previous KEYS_ACTIVE, it may not have= seen it
> yet. It is possible that it simultaneously did a key update and sent a=
> KEYS_ACTIVE however. Under this condition, the endpoint wouldn't b= e able to
> update its keys again, since the peer may close the connection, right?=

This is not a problem, but it requires thinking the process through.

An endpoint can only initiate a key update if it has received KEYS_ACTIVE.= =C2=A0 It can only send KEYS_ACTIVE if it has received a key update (and is= either responding, or initiated that).

Take the example where an ACK is lost, so a key update occurs when one peer= is retransmitting KEYS_ACTIVE:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 Send KEYS_ACTIVE.
C: Send packet containing ACK for the server packet containing KEYS_ACTIVE,= plus KEYS_ACTIVE.=C2=A0 That packet is lost.
C: Update to Key Phase 0.
S: Update to Key Phase 0. Send KEYS_ACTIVE.

The server might believe that its KEYS_ACTIVE hasn't been acknowledged,= but it has to be prepared for a key update as soon as it sends the frame.<= br>
If there is a simultanous update it looks like this:

C: Update to Key Phase 1.
S: Update to Key Phase 1.=C2=A0 (Concurrent with previous.)
C: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.=C2=A0 Lost.
S: Receive packet with KP1.=C2=A0 Send KEYS_ACTIVE.

At this point, both peers are fine, they are on the same keys, and a key up= date can be triggered by the client.=C2=A0 The server can't update unti= l the client repairs the lost KEYS_ACTIVE frame.=C2=A0 This continues:

C: Update to Key Phase 0.
S: Receive KP0.=C2=A0 Update to Key Phase 0.=C2=A0 Send KEYS_ACTIVE.

As you can see, the client stops sending when it updates again, but that= 9;s OK.

It's also safe if the KEYS_ACTIVE frames get through, but acknowledgmen= ts for them don't.

--0000000000006dfc000581de63b6--