Re: [quicwg/base-drafts] Output of the discard keys design team (#2673)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -1116,9 +1147,20 @@ TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
 message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
 unexpected_message (see {{tls-errors}}).
 
-An endpoint MUST NOT initiate more than one key update at a time.  A new key
-cannot be used until the endpoint has received and successfully decrypted a
-packet with a matching KEY_PHASE.
+An endpoint MUST NOT initiate the first key update until the handshake is
+confirmed ({{handshake-confirmed}}). An endpoint MUST NOT initiate a subsequent
+key update until it has received an ACK for a packet sent at the previous
+KEY_PHASE.  This can be implemented by tracking the lowest packet number sent
+with the previous KEY_PHASE, and the highest value of the Largest Acknowledged
+field in any received 1-RTT ACK frame: once the latter is higher than the
+former, another key update can be initiated.
+
+Endpoints only need to maintain the two latest sets of packet protection keys

Ahh, my bad.  I added the wrong implication.

```suggestion
Endpoints MAY limit the number of sets 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
```



-- 
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/2673#discussion_r281876435