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

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +which is comprised of:
+
+* Version number; a 32-bit unsigned number that is to be presented on wire in
+  place of the version number specified in this document.  This value MUST NOT
+  be a reserved version ({{versions}}).
+
+* Packet type modifier; a two-bit value that obfuscates the Long Packet Type of
+  a long header packet ({{long-header}}).  The long packet type bits of a long
+  header packet is encoded as an bit-wise exclusive or (XOR) of the packet type
+  modifier and the type numbers defined in {{long-packet-types}}.
+
+* 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

That's true as well, but the processing flow is:

- Server recognizes version alias, which permits it to find the token field
- Server is able to obtain the Initial salt using the combination of version and token (whether it needs both is implementation-dependent)
- Server uses salt to decrypt Initial packet contents

I suggested the "permit ... to recover" language to remove the implication that the token *contains* the salt, but a server could certainly send the same version alias to different clients with different salts if the token enables the mapping.

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