Re: [quicwg/base-drafts] Retire My Own CID (#2645)

[David Schinazi <[e-mail]>]

@nibanks the issue is that an attacker can close the connection if the stateless reset tokens are the same for different CIDs. Perhaps this wording gets you what you want:

```
An endpoint can request that its peer retire connection IDs by sending
a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  
Upon receipt, the peer SHOULD retire the corresponding connection IDs
and send the corresponding RETIRE_CONNECTION_ID frame in a timely
manner.  Failing to do so can cause packets to be delayed or lost and
harm connection performance as the original endpoint might not route
those connection IDs optimally after some delay.

The sender of the Retire Prior To field MUST keep track of the connection
IDs it wishes to retire until it has received a corresponding
RETIRE_CONNECTION_ID frame, with one exception: if the sender of the
Retire Prior To field has used distinct stateless reset tokens for all of
their issued connection IDs, and 3 times the PTO has elapsed since it
received an acknowledgment for its Retire Prior To field, then it MAY lose
track of that connection ID, and respond to packets with that connection
ID with the corresponding stateless reset token.
```

This allows you to implement the enforcement you want while keeping the spec written in such a way that most implementations don't accidentally allow this attack by being overly enthusiastic in enforcing this.

-- 
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/issues/2645#issuecomment-501041204