Re: KEYS_READY

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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]<mailto:[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.