Re: [quicwg/base-drafts] Rework Key Update (#2237)

[hardie <[e-mail]>]

hardie commented on this pull request.



> -The KEY_PHASE bit allows a recipient to detect a change in keying material
-without necessarily needing to receive the first packet that triggered the
-change.  An endpoint that notices a changed KEY_PHASE bit can update keys and
-decrypt the packet that contains the changed bit.
+The low bit of the Key Update field (0x04) is the Key Phase bit.  The Key Phase
+is used to indicate which packet protection keys are used to protect the packet.
+The Key Phase bit is initially set to 0 for the first set of 1-RTT packets.  The
+Key Phase is toggled to signal each key update.
+
+The Key Phase bit allows a recipient to detect a change in keying material
+without needing to receive the first packet that triggered the change.  An
+endpoint that notices a changed Key Phase updates keys and decrypts the packet
+that contains the changed value.
+
+The high bit of the Key Update field (0x08) is the Key Update Permitted bit.
+Endpoints set this value to 0 until they successfully process a packet with keys

As written, this seems to imply that Endpoints must set the value to 1 when they successfully process a packet.  I agree with Ian that there will be cases where this is set to 0 and never changed (e.g. when the expected flow size is short).  Perhaps this would work instead:

"The high bit of the Key Update field (0x08) is the Key Update Permitted bit.  Endpoints may set this value to 0 for any reason, forbidding Key Updates.  Endpoint MUST NOT set this value to 1 until they successfully process a packet the largest received packet number with keys from the same key phase as they are using.  They MAY set it to 1 to indicate key update is permitted at any time after that."

-- 
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/2237#pullrequestreview-190968792