Re: KEYS_READY

[Martin Thomson <[e-mail]>]

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.