Re: KEYS_READY

[Marten Seemann <[e-mail]>]

> 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.
>
>