External DDoS Support for Retry Token Timestamp Disablement

[kmmago]

Describe the feature you'd like supported

MsQuic Retry Token mechanism uses Timestamp to identify the Key phase. Ask is to make use of Timestamp as an option that can be disabled i.e. if disabled timestamp is not used to get key phase, but rather all active keys (currently 2) are used to decrypt.

Proposed solution

For Ddos and MsQuic shared key Retry Token mechanism to work effectively, it is crucial that the two systems are clock synchronized. This should not be an issue for solutions running within Azure as NTP should take care of that, but can we make this configurable so that it can be disabled when any discrepancies are found with clock synchronization and it starts affecting customers because ddos generated tokens are not correctly verified by msquic server because of drift in timestamps.

Additional context

No response

[ProjectsByJackHe]

Tagging our crypto SME @anrossi

Just clarifying:

You're saying that purely using timestamp as a source of truth for synchronizing cryptography is not enough / can be wrong when there is clock drift.

I am having some trouble understanding the proposed solution (not the biggest expert in crypto/RSA).
Is it possible to run through an example scenario?

[nibanks]

We could build on my proposal for #5005 and change the proposed QUIC_PARAM_GLOBAL_RETRY_CONFIG parameter take an additional parameter to indicate "manual" or "rolling" mode, and if manual mode is specified, N secrets (should we hard code to 2?) may be supplied instead of the base one.

The big downside of manual mode is the requirement to do trial decryption (i.e., try all secrets).