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

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> -discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
+While only one send key is used at a time, an endpoint SHOULD retain at least
+two receive keys during key update so that it can unprotect packets arriving
+out-of-order.
+
+An endpoint can detect 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 old receive keys for unprotecting the
+packet, if these keys are still available.  If the packet has a higher packet
+number, the endpoint installs the new receive keys by calculating the next

I think what I'm suggesting is compatible with the current text (and therefore also necessary to keep this PR editorial):
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and 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 updated key and IV, then the keys the endpoint uses for packet protection are also updated.

-- 
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#discussion_r294157131