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

[Kazuho Oku <[e-mail]>]

@DavidSchinazi Re downgrade prevention, I think we are converging on the same design (my design being the one that I had on this PR before dropping the downgrade).

Regarding the attack, I do not think we need to require the original token to be sent in a TP. Let me explain why:
* This PR requires the server that sends a Retry token to embed the the alternative sets of a NEW_TOKEN token in the Retry token (i.e. typically, NEW_TOKEN token found in an Initial packet that triggered the Retry would be embedded as-is in the Retry token).
* This PR used to require the client to continue sending the NEW_TOKEN token when downgrade happens. We can resurrect that requirement.

If we combine these two requirements, it would be possible for the server to detect a downgrade even if Retry was sent after downgrade, as the Retry token would convey the NEW_TOKEN token that the client originally submitted.

Re checksum, one way to solve this is to suggest servers advertising alternatives sets to embed a checksum to the tokens, using an key-less algorithm. For example, a server can build a NEW_TOKEN token as a combination of AES-CBC (encryption) and SHA256 (checksum).

Anyways, I think I might open a separate PR that describes the design with downgrade prevention, as having a PR would help us discuss the issues.

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