Re: [quicwg/base-drafts] Provide guidelines on token validation (#2132)

[MikkelFJ <[e-mail]>]

> What do you believe are the principles that we should be applying here?

I believe this requires careful analysis on especially possible attacks - some work is already happening elsehere.

These are just my immediate suggestions, but I'm sure I'm missing something:

- Tokens that pass integrity checks and which have not expired are accepted and require no further path validation, but must be treated as failed integrity checks if reused within a short time frame. (This may not work if a client retries a connection attempt with the same token - so clients can retransmit a packet with a token verbatim, but not reuse it in a new connection attempt - some would retransmit with a higher PN for RTT estimates, but I'm not convinced about this in context of attacks).
- Token integrity checks should include verifying that a token was created by the entity controlling the endpoint and that IP matches, but due to replay this is only a minimum requirement. (Since a client can have multiple IP's and both IPv4 and IPv6 on separate paths, I'm not sure it is that simple?).
- Tokens that pass integrity checks but have expired either due to a built-in timestamp or due to an old validation key grace period should be treated as a missing token, forcing new path validation. A server might have a grace period for old token keys during rollover, if it still has the old key.
- Tokens that fail integrity checks should result in dropped packets unless the server has lost state, in which case it should ignore the token (or perhaps issue a retry if the token is not already a retry token?).
- Tokens that cannot be verified due to server upgrade or other loss of context should be treated as a missing token, forcing new path validation, but only for a limited grace period after which they are treated as failed integrity checks. This period may be different for Retry and NEW_TOKEN tokens. If a server does not eventually drop packets with invalid tokens, it is vulnerable to attacks. If it always drops invalid tokens, a client might never be able to connect. (Perhaps a client should be advised to drop all tokens after a few failed connection attempts?).


There are probably some simpler underlying formulation that can be used to condense these guidelines.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2132#issuecomment-446885628