Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

[David Schinazi <[e-mail]>]

Thanks @kazuho. I still think we can improve this, the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets. Perhaps something like the following?

```
While only one send key is used at a time, an endpoint MUST retain at least two
receive keys (the "current" key and "future" key) during a key update to prevent
attackers from triggering key updates. An endpoint SHOULD retain a third
receive key (the "past" key) so that it can unprotect older packets that arrive
out-of-order.

Packets received with the current active key phase are unprotected using the
"current" key. When a packet arrives with the opposite key phase, an endpoint
determines which receive key to use by tracking the lowest packet number
among the packets received with the currently active key phase.  If a
packet is received that has a different KEY_PHASE bit and a lower packet number
than this value, the endpoint uses the "past" receive key for unprotecting the
packet, if that key is available.  If the packet has a higher packet number, the
endpoint derives the "future" receive key by calculating the next secret
(see Section 7.2 of {{!TLS13}}), the corresponding read key and IV using the KDF
function provided by TLS.  The header protection key is not updated.

If the packet can be decrypted and authenticated using the "future" receive key
and IV, then the endpoint switches to the next key phase, installs the "current"
key as its "past" key, and installs the "future" key as its "current" key.  The
endpoint also updates its send key to match its "current" receive key. The next
packet sent by the endpoint MUST then use the new send key.  Once an
endpoint has sent a packet encrypted with a given key phase, it MUST NOT
send a packet encrypted with an older key phase.

Updating keys multiple times rapidly can cause packets to be effectively lost if
packets are significantly reordered.  Therefore, an endpoint SHOULD NOT initiate
a key update for some time after it has last updated keys; the RECOMMENDED time
period is three times the PTO.  This avoids valid reordered packets being
dropped by the peer as a result of the peer discarding older keys.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791#issuecomment-503234742