-
-
Notifications
You must be signed in to change notification settings - Fork 389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accept connections with unrecognized address validation tokens #1790
Conversation
265d098
to
3106520
Compare
Hm. Please tell me if I'm missing context, but my understanding is that the spec forbids this. 8.1.2. Address Validation Using Retry Packets
17.2.5.1. Sending a Retry Packet
Also relevant context:
I need to look more into how exactly quinn is handling retries, but I think the appropriate way to facilitate clustering like this would be to make the important part of retry tokens be an encrypted and signed message containing the client's address, and allow the key which encrypts and signs that message to be configured so it can be set the same between different servers in a cluster, so that their retry tokens will be intercompatible |
My incorrect word choice in the PR/commit message may have made this needlessly confusing, and has been revised. It is true that we must never perform a repeated Retry. However, we may receive address validation tokens that the peer obtained from a previous connection's
|
Hmmmm. Ah, ok, I guess that, in the phrase "If a server receives a client Initial that contains an invalid Retry token but is otherwise valid", they mean to imply by the phrase "Retry token" that it is an address validation token which is valid enough to be unambiguously identified as having been minted as for a retry rather than a new_token frame but which is otherwise in some way invalid? That makes sense, although in my opinion the RFC's language is a bit confusing there. Sounds good though. |
Yeah, this came up as an ambiguous case in the implementers' slack. Perhaps we'll get an errata for it. |
Retry source CIDs are under our control and are already required to be unpredictable, so they make a fine basis for key derivation.
Rebased, and dropped the "factor out token decoding" commit since |
MSRV failure is not related. |
Disabled the flag that requires all status checks to pass before merging for a bit. |
If we share an identity with a different QUIC implementation, e.g. across an update or through a load balancer, and retries are enabled, we might receive address validation tokens generated by it and fail to decode them. Restarting address validation with a fresh Retry packet allows the connection attempt to proceed.
This involves refactoring of the Retry-mediated address validation cryptosystem, for which particularly careful review is required. In particular, we ditch the random plaintext in favor of directly encrypting the client address, and instead use the (server-chosen) retry source CID to derive a unique token key.
The circumstances where this matters are niche, so no particular rush to get this in before 0.11.