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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.

Thank you for writing this down.

It was easy to read. I like the discussing immediate updates first then about delaying permission to restrict the number of keys. LGTM modulo the following comments.

>  
-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 the low bit of the Key Update field (0x04) is the Key Phase bit.  The Key

"The the"

>  
-A packet that triggers a key update could arrive after successfully processing a
-packet with a higher packet number.  This is only possible if there is a key
-compromise and an attack, or if the peer is incorrectly reverting to use of old
-keys.  Because the latter cannot be differentiated from an attack, an endpoint
-MUST immediately terminate the connection if it detects this condition.
+An endpoint SHOULD retain old read keys for a period of no more than three times
+the Probe Timeout (PTO, see {{QUIC-RECOVERY}}).  After this period, old read
+keys and their corresponding secrets SHOULD be discarded.  An endpoint MAY keep
+the Key Update Permitted bit set to 0 until it discards old read keys to limit

How about explicitly stating "until it discards the 0-RTT key or the previous 1-RTT read key" here, to be clear that we can have the Key Update Permitted bit set to zero until the 0-RTT key is discarded when 0-RTT is used.

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