Re: KEYS_READY

[David Schinazi <[e-mail]>]

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øe Jørgensen <[e-mail]>
wrote:

> I guess because ACK?
>
>
> ------------------------------
> *Fra:* Mikkel Fahnøe Jørgensen <[e-mail]>
> *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 update
> after ca 3 PTO in the async design. Neither design can force the peer to
> update.
>
>
> ------------------------------
> *Fra:* QUIC <[e-mail]> på vegne af Marten Seemann <
> [e-mail]>
> *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’t aware of the additional retransmission logic necessary, and
> I would’ve 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 we
> don’t have PTOs. The only way to achieve this using the KEYS_ACTIVE frame
> is to include it in multiple (all packets for one RTT?) after the handshake
> 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 <[e-mail]> 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 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 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 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.  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 the
>> 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 acknowledgments
>> for them don't.
>>
>>