Re: Key updates

[Kazuho Oku <[e-mail]>]

2018-08-07 15:37 GMT+09:00 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).

My point is that the issue within the current design is that we
require the endpoint to update if the peer initiates an update.

I am suggesting to change that to "an endpoint updates its epoch if
the peer starts using an epoch that is higher than it uses."

Taking the example,

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, and they will stay using
N+1, because each of them initiated an update and because the epoch
that one uses is not smaller than the value used by the peer

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



-- 
Kazuho Oku