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

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.



> @@ -1162,19 +1162,24 @@ number sent with each KEY_PHASE, and the highest acknowledged packet number
 in the 1-RTT space: once the latter is higher than or equal to the former,
 another key update can be initiated.
 
-Endpoints MAY limit the number of keys they retain to two sets for removing
-packet protection and one set for protecting packets.  Older keys can be
-discarded.  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.
-
-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

During *a* key update. Or during key update*s*.

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

s/can detect/determines

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

s/derives/installs.

We don't want to change any state before authenticating the packet, as discussed in #2792.

-- 
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#pullrequestreview-250312383