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

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Oct 2019 10:37:15 -0700

[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

---

From: martinduke <[email-masked]>
Date: Thu, 17 Oct 2019 13:59:50 -0700

Would alternate version still be optional?

-- 
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#issuecomment-543359615

---

From: Marten Seemann <[email-masked]>
Date: Thu, 17 Oct 2019 14:20:03 -0700

@martinduke You certainly could make those fields optional in the NEW_TOKEN frame.

On the other hand, you could also make it required, and even forbid servers from sending NEW_TOKEN frames with the same version number as they're currently using, effectively forcing them to implement greasing.
Note that a server could still decide not to implement greasing, but would then be prevented from using NEW_TOKEN (which itself can be considered an optional feature of the QUIC protocol).

-- 
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#issuecomment-543366531

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 17 Oct 2019 14:44:32 -0700

@martinduke 
> Would alternate version still be optional?

I do not think there is a reason to make it optional. It can be mandatory, while the server deployments wanting to use a specific version, initial salt can specify those in every NEW_TOKEN frames that they send.

-- 
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#issuecomment-543374390

---

From: martinduke <[email-masked]>
Date: Sat, 19 Oct 2019 16:40:27 -0700

A NEW_TOKEN frame is always optional, but is seems weird to link something that is desirable-but-optional (handing out tokens) with something that some may find undesirable.

-- 
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#issuecomment-544206256

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2019 18:54:54 -0700

If we make this a mandatory part of NEW_TOKEN, then we increase the number of connections that deploy ossification defenses.  I'm slightly in favour of doing that.  A mandatory coupling also makes the encoding slightly simpler.

-- 
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#issuecomment-544777016

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 19:12:18 -0700

One nit on your first point:
> 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).

Aren't clients required to store transport parameters when doing resumption already, so this is moving it from one place they store to another?

There are servers that will want to use NEW_TOKEN and not do version greasing, so I believe this really should be optional if you put it into NEW_TOKEN, just like it would be in transport params.

-- 
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#issuecomment-544779814

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Oct 2019 19:20:40 -0700

@ianswett 
> Aren't clients required to store transport parameters when doing resumption already, so this is moving it from one place they store to another?

That's a good point. I admit that the only one benefit of bundling the alternative version-salt is that the server can store and recover that from the token. That said, please let me reiterate that that is a huge benefit, as it provides the servers the capability of protecting the Initial packets from on-path intermediary in a cryptographically secure way.

Regarding if the alternative fields should be a mandatory field of a NEW_TOKEN frame, I think it's just about a matter of encoding. As I have stated in https://github.com/quicwg/base-drafts/issues/3111#issuecomment-543374390, a server that is not willing to do greasing (or Initial protection) can advertise version 1 and the Initial salt of version 1 in those fields.

-- 
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#issuecomment-544781126

---

From: ianswett <[email-masked]>
Date: Mon, 21 Oct 2019 19:41:52 -0700

> That's a good point. I admit that the only one benefit of bundling the alternative version-salt is that the server can store and recover that from the token. That said, please let me reiterate that…
To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token.  But if these were in transport params, then the client might decide not to send the subsequently transmitted token with the version and salt or the corresponding token might not get delivered in time?

-- 
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#issuecomment-544784567

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 21 Oct 2019 20:00:40 -0700

@ianswett 
> To clarify what you're getting from this that isn't achieved in TPs is that here you're guaranteed that when the client comes back with the version and salt, they'll also specify the Token. But if…

That's correct.

Unless we require the token and the alternative salt to be used together, the only source that we could use to determine the initial salt would be the version number field. That means that there can be at most 2<sup>32</sup> salts, therefore we'd see a birthday problem once we handle 2<sup>16</sup> connections. That's more than enough for ossification, but not as a way to encrypt Initial packets.

If we bundle the token and the alternative salt, and require them to be used together, then the value space of the alternative salt becomes 2<sup>128</sup> that can be unique to each connection.

Note also that being possible to deduct the alternative salt from the NEW_TOKEN tokens simplifies the deployment, because servers dealing with NEW_TOKEN tokens are expected to have a way to deduce other information from the token. The complexity becomes to just adding one more information (which is the alternative salt) to that set of information, whereas we'd be required to retain a map (or define a way to a map) that lists the alternative version numbers and salts, if we do not require the token and the alternative salt to be used together.

-- 
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#issuecomment-544787363

---

From: ianswett <[email-masked]>
Date: Wed, 23 Oct 2019 09:02:58 -0700

Question: Can we put this information in Alt-Svc as well, so the first time a user uses QUIC, they have an encrypted client Initial?

-- 
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#issuecomment-545516377

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Oct 2019 14:02:13 -0700

I would say that copying NEW_TOKEN (not just the version+salt+2bits) would be the way to go.  We might need to identify the base version as well though to prevent cross-version errors, though that identification might be implicit.

-- 
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#issuecomment-545635039

---

From: Mike Bishop <[email-masked]>
Date: Mon, 28 Oct 2019 13:59:29 -0700

The ability to cryptographically secure Initials is extremely compelling.  The base version is tricky -- the obvious answer is that it's the version you're speaking now, but that might complicate our upgrade story.  We're getting to the point where we need a sane outline of the answer to "How does a client discover that it and the server both speak a higher/better version of QUIC than the one currently being used?" even if we leave the details for later.

-- 
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#issuecomment-547143353