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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> -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.  The
-next packet sent by the endpoint MUST then use the new keys.  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.
+While only one send key is used at a time, an endpoint MUST retain at least two
+receive keys.
+
+Packets received with the current key phase are unprotected using the
+corresponding receive 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 key phase.  If a packet is

```suggestion
number among the packets received with the current key phase.  If a packet is
```

> +
+Packets received with the current key phase are unprotected using the
+corresponding receive 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 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 receive key of the previous key phase for
+unprotecting the packet, if that key is available.  If the packet has a higher
+packet number, the endpoint derives the receive key of the next key phase by
+calculating the next secret (see Section 7.2 of {{!TLS13}}), the corresponding
+read key and IV using the KDF function provided by TLS, unless the next receive
+key has already been derived.  The header protection key is not updated.
+
+Once derived, an endpoint retains the receive key of the next key phase, to
+prevent attackers from targeting the calculation process of the next receive key
+as an attack vector.  An endpoint that retains only two receive keys drops the

An attack on what?

> +corresponding receive 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 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 receive key of the previous key phase for
+unprotecting the packet, if that key is available.  If the packet has a higher
+packet number, the endpoint derives the receive key of the next key phase by
+calculating the next secret (see Section 7.2 of {{!TLS13}}), the corresponding
+read key and IV using the KDF function provided by TLS, unless the next receive
+key has already been derived.  The header protection key is not updated.
+
+Once derived, an endpoint retains the receive key of the next key phase, to
+prevent attackers from targeting the calculation process of the next receive key
+as an attack vector.  An endpoint that retains only two receive keys drops the
+receive key of the previous key phase in favor of retaining the next receive
+key.

This has to happen *after* you successfully use the new key.

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