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

[Kazuho Oku <[e-mail]>]

kazuho commented on this pull request.



> +* When sending a Retry in response to an Initial packet carrying an alternative
+  version number, the server embeds the NEW_TOKEN token found in the Initial
+  packet within the retry token it issues.  Once the server receives a response
+  from the client carrying that retry token and the path is validated, it
+  decrypts the NEW_TOKEN token embedded in the retry token to recover the
+  alternative initial salt that is to be used for unprotecting the packet
+  payload.
+
+Instead of associating a new alternative initial salt to every NEW_TOKEN token,
+a server might map a fixed salt to each of the alternative version numbers it
+issues.  Such design is not recommended, as an active attacker might build a
+list of known alternative version numbers and their initial salts and use that
+list to decrypt the payload of Initial packets using those alternative version
+numbers.  But still, having a set of version numbers and initial salts used
+concurrently is considered better than just using the default values of QUIC in
+terms of preventing ossification.

> It would be better if the client could be certain that it does indeed sent private information on the wire.

At the moment, we never provide that certainty. The only way to provide that is to send a public key in the NEW_TOKEN frame and do a DH to determine the initial salt.

We can do that, but that's essentially about porting ESNI to QUIC. My assumption has so far been that such an effort would require time, and it would be better to do that as a separet draft (e.g., https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/)

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