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

[Marten Seemann <[e-mail]>]

marten-seemann commented on this pull request.

I agree with @ekr. At least in my implementation, the coupling between acknowledgements and key management would create *a lot* of additional complexity.
I proposed a different solution in https://github.com/quicwg/base-drafts/issues/2214#issuecomment-449219993.

> +
+Endpoints maintain separate read and write secrets for packet protection.  An
+endpoint initiates a key update by updating its packet protection write secret
+and using that to protect new packets.  The endpoint creates a new write secret
+from the existing write secret as performed in Section 7.2 of {{!TLS13}}.  This
+uses the KDF function provided by TLS with a label of "quic ku".  The
+corresponding key and IV are created from that secret as defined in
+{{protection-keys}}.  The header protection key is not updated.
+
+The endpoint uses the key and IV to protect all subsequent packets, and inverts
+the value of the KEY_PHASE bit to signal the change of keys.
+
+An endpoint MUST NOT initiate more than one key update at a time.  A new key
+cannot be used until the endpoint has received an acknowledgment for a packet it
+sends with the new keys.  An endpoint that receives a packet protected with old
+keys that includes an acknowledgement for a packet protected with newer keys MAY

I don't understand this error condition. Are you implying that key updates effectively create separate packet number spaces, and ACKs are only valid for the space that they're sent with?
I know that there was a lot of discussion about which packets to include in an ACK frame, but as a high-level strategy it should be allowed to include all packets received within the last one to two RTTs. This would lead to ACK frames that span multiple key phases.

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