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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> +* Initial salt; a 16-byte binary blob that is to be used in place of the initial
+  salt defined in section 5.2 of {{QUIC-TLS}}.
+
+A server advertises these seeds using a NEW_TOKEN frame {{frame-new-token}}.
+The token MUST permit the server to recover these seeds.  This property can be
+achieved for example by embedding these seeds in the encrypted token.
+
+For the non-default seeds to work, all the servers within the scope of a
+NEW_TOKEN token are required to have a shared knowledge of those seeds being
+issued and / or how they can be recovered from the tokens. Certain server
+deployments might have difficulty in meeting such a requirement.
+
+A server (or a set of servers) that cannot satisfy this requirement can stick to
+using the default values by consistently advertising the default version number,
+default initial salt, and a packet type modifier of zero in the NEW_TOKEN frames
+it sends.

Am I correct in assuming that what you are looking for is a clarification that servers can announce a set of alternative versions, each of them tied to a fixed initial salt and packet type modifier?

I think that this is the correct text explaining the multi-CDN use-case, where servers cannot agree on anything.

To paraphrase, we'd be explaining:
1. a server that generates a new initial salt for every connection and embeds it into NEW_TOKEN
2. a server that has a fixed mapping between alternative versions vs. salt (and packet type modifier).
3. a server that does not do greasing at all (multi-CDN).

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