tokio-quiche: Add SCID to retry token HMAC #2256
Conversation
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.
TheJokr
force-pushed
the
lblocher/OXY-1677
branch
from
76a3b1f to
4a4239c
Compare
|
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 |
|
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 Alternatively, we could also validate the CID using What do you think? |
| debug_assert_eq!(tag.len(), HMAC_TAG_LEN); | ||
|
|
||
| token.into_inner() | ||
| // Drop the non-payload parts of the HMAC and reuse the storage for the |
There was a problem hiding this comment.
If we are dropping the non-CID parts of the buffer anyway I think we can just use the Hasher::update() API instead to avoid having to allocate the whole token_buf and then truncating it https://docs.rs/boring/latest/boring/hash/struct.Hasher.html#method.update
There was a problem hiding this comment.
That's what I wanted to do originally, but boring's Hasher doesn't do HMACs natively. The rust crate only exposes the one-shot API.
3 participants
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.