Re: [quicwg/base-drafts] forbid key discarding before receiving a packet protected with new keys (#4079)

[Marten Seemann <[e-mail]>]

@marten-seemann commented on this pull request.



> @@ -1496,10 +1496,11 @@ The endpoint that initiates a key update also updates the keys that it uses for
 receiving packets.  These keys will be needed to process packets the peer sends
 after updating.
 
-An endpoint SHOULD retain old keys so that packets sent by its peer prior to
-receiving the key update can be processed.  Discarding old keys too early can
-cause delayed packets to be discarded.  Discarding packets will be interpreted
-as packet loss by the peer and could adversely affect performance.
+An endpoint MUST retain old keys until it has successfully unprotected a packet
+sent using the new keys.  An endpoint SHOULD NOT discard old keys immediately
+after unprotecting a packet sent using the new keys.  Discarding old keys too
+early can cause delayed packets to be discarded.  Discarding packets will be
+interpreted as packet loss by the peer and could adversely affect performance.

So here's what happens when you initiate a key update from key phase N to N+1: You start using N+1 for encrypting packets. As it's not guaranteed that those packets are received by the peer, it's not safe to drop keys for key phase N yet. You only know that the peer received a packet protected with N+1 keys once you successfully unprotect a packet encrypted with N+1 keys (as the peer is required to update its keys immediately once it receives your N+1 packet).
>From this point on, it is **safe** to drop key N. However, it's not recommended, as there might be reordering, so keeping the key for a bit longer allows you to process delayed packets. At this point, this is just a performance optimization.

-- 
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/4079#discussion_r485313351