validation token is currently naive

[Sashan]

This issue refers to draft PR #25842. The prototype uses simple openssltoken string as a validation token. This is not sufficient to provide protection against spoofing. The token needs to serve as proof it comes from server and it must be impossible (computationally expensive) to anyone to generate valid token. I believe it must be conceptually similar to TCP syn-cookies.

The devil here is hiding on how long the validation token we sent out should remain valid, this really depends on how strong the cryptographic mechanism is. I think it also depends on bandwidth potential attacker can utilize to eventually brute force the token. Perhaps the expiration token time needs to be tunable. Best answer here is to learn from other QUIC stacks.

[t8m]

IMO handling the validation token can be fully stateless - just make it a HMAC of the new destination connection ID with a random key set during the library or SSL_CTX initialization. No need to expire anything as this cannot be really brute-forced and expiration happens naturally when the server is restarted and a new key is generated.

[mattcaswell]

Our DTLS implementation uses a "cookie" for much the same purpose as QUIC's validation token:

https://github.com/openssl/openssl/blob/59f5f6c73cd2e1e2bd8ef405fdb6fadf0711f639/ssl/d1_lib.c#L623-L671

For DTLS the cookie (i.e. validation token) is actually generated via an application callback. We have an implementation of this in our apps:

https://github.com/openssl/openssl/blob/59f5f6c73cd2e1e2bd8ef405fdb6fadf0711f639/apps/lib/s_cb.c#L833-L925

We might draw some inspiration from how this works.

[vavroch2010]

Include tests