Re: [quicwg/base-drafts] token-based greasing / initial packet protection (#3166)

[David Schinazi <[e-mail]>]

If I understand the latest text correctly, it's saying:
- NEW_TOKEN carries a lifetime
- if a server wants to use alternative salts, it MUST ensure that it has access to its decryption key for the lifetime of that token, otherwise handshake timeouts could occur

I don't think that'll work for our deployment. We're interested in deploying alternative salts, but our mechanism to share keys across our fleet of servers isn't infallible: it's possible that one server gets a new key before another server, and if a client hits these two servers in the wrong order, they could end up in a state where the server cannot decrypt the token. This is fine for the current uses of QUIC NEW_TOKENs and TLS session tickets, because both of those will resolve themselves in-band (via RETRY, or full handshake).

Therefore I really think we need a graceful mechanism to handle this, similar to what was added to ESNI. The question then becomes: can we design a fallback mechanism that isn't vulnerable to a simple downgrade attack.

Here's a straw-man:
- when the server sees an initial token (the one from NEW_TOKEN, not from retry) that it cannot decrypt, it sends a RETRY.
- the server takes the non-decryptable token it received from the client, and sends it encrypted inside the retry token in the server's RETRY 
- the client tries again, but this time with QUICv1 (no obfuscation) and the retry token, but we add a new transport parameter where the client sends the first token it used on this connection

This would allow the server to detect when someone messed with the token in flight, and would then close the connection. So it mitigates the downgrade attack I described [earlier](https://github.com/quicwg/base-drafts/pull/3166#discussion_r340366571).

This straw-man has many downsides, including:
- we're back to needing a checksum on the token
- an attacker can still see the SNI, but they can't do so without it being detected. This might be acceptable because the attacker can still force a downgrade to TLS/TCP today

Anyway, I'm not sure this straw-man is the way to go, but perhaps the idea of repeating tokens in transport parameters might be worth exploring to help detect this class of attack.

-- 
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/pull/3166#issuecomment-548156716