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

[Mike Bishop <[e-mail]>]

@MikeBishop commented on this pull request.

I'm a bit uncomfortable tying the trigger to the peer's own key update, even though they're required to update in step.  Would it make more sense to say you don't discard until you've received an acknowledgement for a packet sent with the new keys?  That already has to be tracked for the maximum frequency of key updates, so it would make sense to hang this mechanism on it as well.  If you know the peer has received a packet from you in the new phase, they'll be updating soon enough, but you know they have read keys which is the real issue.

> @@ -1617,9 +1619,9 @@ after receiving an acknowledgment that confirms that the previous key update was
 received.  Failing to allow sufficient time could lead to packets being
 discarded.
 
-An endpoint SHOULD retain old read keys for no more than three times the PTO.
-After this period, old read keys and their corresponding secrets SHOULD be
-discarded.
+An endpoint SHOULD retain old read keys for no more than three times the PTO
+afer having received a packet protected using the new keys. After this period,

```suggestion
after having received a packet protected using the new keys. After this period,
```

> @@ -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.

It *is* a performance issue provided the peer keeps sending.  You just lose some reordered packets and have spurious detection of some extra packet loss.  Where the connection hard-fails is when the peer never updates / learns about the update because the initiator stops sending.

-- 
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#pullrequestreview-484485061