[quicwg/base-drafts] [Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN (#3111)

[Kazuho Oku <[e-mail]>]

[Version Ossification] Alternative version and Initial Salt should be part of NEW_TOKEN

At the moment, PR #2753 suggests using a Transport Parameter. That approach has two concerns:
* We are creating another set of resumption information that needs to be retained by the client (we already have NEW_TOKEN token, TLS session ticket, and optionally H3 SETTINGS).
* We cannot have enough space for Initial Salts so that Initial packets would be encrypted (in the cryptographic sense).

I hereby propose (as a separate issue as suggested by https://github.com/quicwg/base-drafts/issues/2496#issuecomment-542889512) to embed the alternative version and the Initial Salt in the NEW_TOKEN frame.

Doing so solves the above two issues:
* The complexity is reduced, as the client can retain the alternative version and Initial Salt along with the NEW_TOKEN token.
* Initials can be encrypted and authenticated in a cryptographically secure way. The Initial Salt to be used can be different for each connection that uses the NEW_TOKEN token. Servers can securely store the salt being used in the token, recover that from the token, then decrypt the Initial packet.

As a side-note, ESNI for QUIC can become a way to generate the alternative version and Initial Salt for non-resuming connections. To paraphrase, this approach would give us the possibility to hide QUIC+ESNI traffic within QUIC+non-ESNI traffic that are resuming. This meets the requirements of ESNI (over TLS over TCP) that the handshake using ESNI should be indistinguishable from those do not.

-- 
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/issues/3111