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

From: MikkelFJ <[email-masked]>
Date: Wed, 12 Dec 2018 09:57:54 -0800

When receiving a token during handshake, several scenarios are possible following the same overall pattern even when the implementation and deployment decides the algorithmic and encoding details.

1. injection attack - replay etc.
2. valid token
3. valid token, but expired, based on servers internal algorithm
4. invalid token, fails servers integrity check

It would be helpful with guidance on how to approach these scenarios.

A token might be valid but timed out because there is an embedded timestamp, but it could also be because the server farm is being upgraded and new instances cannot validate old tokens thus potentially allowing a grace period where they ignore tokens they can verify at all.

Attacks are not trivially known to be attacks, or they wouldn't be attacks, but their existence affect how safe it is to reject a token with a closed connection vs ignoring the token. #2097 discusses injection attacks.

-- 
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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 16:19:32 -0800

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

-- 
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-446794712

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 00:38:30 -0800

> 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