cloudflare
tokio-quiche: Add SCID to retry token HMAC
Due to tokio-quiche's stateless address validation via RETRY packets, we rely on the client to reflect our chosen SCID back to us. We should make sure that we actually generated that SCID by binding the retry token to the SCID.
I didn't want to duplicate the SCID inside the token, so I refactored the code a bit to only include data that is not available from elsewhere. This means we also don't need to include the client IP address in it anymore.
I think this would cause some issues for the potential future use of NEW_TOKEN frame, so needs some consideration. Possibly just a TODO comment so we dont forget but needs a little bit of thought
https://datatracker.ietf.org/doc/html/rfc9000#section-19.7
There are some alternatives to fix the issue, this one is just the first one I thought of without re-reading RFC 9000 in detail.
We could just generate a new SCID when receiving a valid retry token. My understanding is that the RFC explicitly allows this. However, quiche doesn't expose an interface to specify the initial SCID and the retry SCID separately, so I'd have to add that. How do you feel about something like quiche::accept_retry(scid, rdcid, odcid, local, peer, config)?
Alternatively, we could also validate the CID using ConnectionIdGenerator::verify_connection_id. This isn't as robust as the retry token (32 byte HMAC vs <=20 bytes shared with other info). It's also limited by whatever format ConnectionIdGenerator implements, but may provide sufficient guarantees.
What do you think?