Re: Key updates

[Martin Thomson <[e-mail]>]

On Tue, Aug 7, 2018 at 4:10 PM Kazuho Oku <[e-mail]> wrote:
> > There is a problem right now with concurrent updates.  If both peers
> > bump at the same time, then N-1 packets could still be in flight.
>
> I think that we might be having different models in our minds.
>
> My view is that, in principle, an endpoint unilaterally updates its
> epoch that it uses for "sending" packets. An endpoint MUST NOT update
> the send epoch before it sees an acknowledgement for a packet that was
> sent encrypting using the current epoch.
>
> To implement reciprocal key update, we will also state that, if the
> send epoch used by the peer becomes greater than the value used by an
> endpoint, then the endpoint SHOULD increment it's send epoch as well.
>
> If we define the rules this way, I would assume that there is not
> chance of key getting updated twice even in case both the peers decide
> to update at the same moment.
>
> To put it another way, the issue with the reciprocal (D)TLS-style key
> update is that it is defined as a "request" rather than a state change
> with idempotency. The rules above is designed as an idempotent state
> change from N to N+1 that can be implemented by either peer without
> the fear of double update that will lead to potential loss (unless the
> endpoints retains more than two keys).

There is nothing inherently wrong with the current design, but I
recently realized that there is a corner case that is awkward at best
without trial decryption, even if you follow those rules.

A sends N+1
B sends N followed by N+1 around the same time.
0.5 RTT later both receive a packet at N+1, so both update (not
naturally noticing that the response was a little faster than it
should have been).
A receives the packet from B at N, reordered a little (maybe the N+1
was a small packet at the tail of a burst).
A thinks that this is N+2 and discards it.

Now, this isn't a correctness issue.  But it's annoying.  It drives
the congestion controller down more than is ideal and adds a bit of
extra latency for anything depending on the contents of that packet
(or those packets if there is more than one).

You fix this by running trial decryption for N and N+2 for a short
time, or you move to the prepare-commit style of update.

> I think that the described algorithm will work fine, but I am not sure
> if I like the fact that it requires the QUIC stack to remember the new
> encryption key and the fact that a KeyUpdate message has been sent in
> a CRYPTO frame at certain offset, and switch to the new key when all
> the data up to that offset is acknowledged.

The QUIC stack doesn't have to remember anything other than that is
received new TLS data at epoch N and a key change after that.  The
rules for transmitting CRYPTO frames at the same encryption level
ensure that everything works correctly.  Now it has new send keys, but
the only new rule it needs would be that until all crypto frames for N
are acknowledged, you can't starting sending on N+1.  I tend to think
of this as not being a new rule, but instead that there are
exceptional rules for this during the handshake.

The rules for receiving are different: you install N+1 for reading
immediately (discarding N-1 if that is still around).  You can discard
N+1 on a timer (that can start immediately, I think, based on what I
worked out for key expiration timers, which I am about to put up as a
PR).