Subject: [quicwg/base-drafts] introduce a version alias transport parameter (#2573)

From: Marten Seemann <[email-masked]>
Date: Sun, 31 Mar 2019 19:07:54 -0700

This is an attempt to solve the QUIC version ossification that was discussed in Prague.

Servers can announce a list of version aliases in the transport parameters. A version alias can be any valid QUIC version number, and the server guarantees to accept this version number as an alias for the currently used version. Each version alias comes with a lifetime for which it is valid, as well as a salt for the encryption of the Initial.
On subsequent connections, clients can use a version alias to establish a connection to the same server.

If widely deployed, middleboxes will get used to version numbers from the whole version number space being used for QUIC connections. Since they are unaware of the Initial salt being used for alias versions, they can't even decrypt the Initial packet.

In the current form, this PR lacks some text about the privacy implications of this proposal. A version alias is (yet another) cookie, so it should have the same properties as a token, i.e. a client shouldn't use the same version alias more than once, in order to avoid being identifiable to on-path observers.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2573

-- Commit Summary --

  * draft some text about the version_aliases transport parameter
  * add an initial secret to the version alias
  * make the version alias lifetime a varint

-- File Changes --

    M draft-ietf-quic-transport.md (36)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2573.patch
https://github.com/quicwg/base-drafts/pull/2573.diff

-- 
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/2573

---

From: martinduke <[email-masked]>
Date: Sun, 31 Mar 2019 19:27:07 -0700

martinduke approved this pull request.

This is a great technical solution, far better than one I hoped to achieve when I launched the issue. I strongly believe we should move forward with this and hope that enough major players will support it to make it viable.

There is a bit of an unfortunate corner case: a v1-only server might pick an alias that matches v2 or some experimental version in the internet. A client that asks for the non-alias version to that server will send an Initial that the server can't decrypt, which will result in connection failure rather than Version Negotiation. I think we should proceed even if we can't mitigate this.

> @@ -4115,6 +4130,25 @@ preferred_address (0x000d):
 ~~~
 {: #fig-preferred-address title="Preferred Address format"}
 
+version_aliases (0x000e):
+
+: A list of version numbers that the server accepts as an alias for the
+  currently used versions. This transport parameter is only sent by the server.
+  Every version alias contains a lifetime in seconds. The alias is only valid
+  for that lifetime, clients MUST NOT use it after expiry.
+
+~~~
+   struct {
+     uint32 VersionNumber;
+     varint Lifetime;

I think we should put some sort of limit on the Lifetime. A server accidentally configured to send out very long lifetimes may create long-term problems for itself. Far better for a client to reject it as invalid! I suggest something on the order of days -- certainly no more than 10^6 seconds.

> @@ -3246,7 +3246,21 @@ Implementors are encouraged to register version numbers of QUIC that they are
 using for private experimentation on the GitHub wiki at
 \<https://github.com/quicwg/base-drafts/wiki/QUIC-Versions\>.
 
-
+## Version Aliases
+
+In order to avoid ossification of the version number defined by this draft,
+servers announce a list of version numbers that they interpret as an alias for
+the version number used in this draft. Alias versions MUST NOT be a reserved
+version. Servers SHOULD send at least one version alias, and SHOULD frequently
+change the value that they announce. Each version alias contains a lifetime,
+which indicates how long the server will accept this version alias. It also
+contains an initial salt, which is used instead of the initial salt as defined

We should think hard about using a special salt vs. the v1 salt. Marten has, almost incidentally, engineered a weak form of SNI encryption: if you _really_ want to decode the initial, you can connect to the server yourself and likely get the salt. But a typical firewall won't be able to read the SNI anymore. This is a victory for the end-to-end principle, but perhaps a Pyrrhic one if firewalls just give up and drop QUIC.  I don't have a particularly strong opinion on how to proceed, but want the WG to make this decision deliberately.

-- 
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/2573#pullrequestreview-220902998

---

From: MikkelFJ <[email-masked]>
Date: Sun, 31 Mar 2019 21:42:46 -0700

Interesting, but middleboxes can scan for known unsalted versions and block some of these. This effectively stops these versions because salting isn’t reliable. Furthermore a middlebox can drop any initial packet it doesn’t understand to force unsalted version on retry.

It can still work for less aggressive middleboxes, but perhaps it is better to wait for the fully encrypted solution Kazuho and Huitema has been working on.

-- 
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/2573#issuecomment-478433519

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 31 Mar 2019 22:18:48 -0700

In addition to what @mikkelfj points out, a middlebox can inject a VN and force the client to retransmit the Initial packet in the version the middlebox prefers. Note that such an attack would not be noticed, because we are removing downgrade prevention from the VN design.

I think that the proposed approach works as an anti-ossification mechanism, but I do not think it's anything more than that.

-- 
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/2573#issuecomment-478439064

---

From: Marten Seemann <[email-masked]>
Date: Sun, 31 Mar 2019 22:26:24 -0700

> In addition to what @mikkelfj points out, a middlebox can inject a VN and force the client to retransmit the Initial packet in the version the middlebox prefers. Note that such an attack would not…

That's correct, *until* we define a QUIC version that has downgrade protection (assuming that this version contains the version alias mechanism proposed here). It seems to be the desire of many people I've spoken to quickly define a QUIC v2 that's identical to QUIC v1, with version negotiation being the only addition to the protocol. In that case, this attack would become infeasible as soon as v2 is deployed, because middleboxes have no way of distinguishing between a v1 and a v2 alias version.

-- 
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/2573#issuecomment-478440248

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 31 Mar 2019 22:47:20 -0700

Then, I might prefer calling this a v2 issue.

If we are to start running v2 as soon as (or even before) v1 gets finalized, possibly with an anti-ossification scheme like this, then I do not think we need to discuss inclusion of this PR in v1?

-- 
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/2573#issuecomment-478443891

---

From: Marten Seemann <[email-masked]>
Date: Sun, 31 Mar 2019 23:04:39 -0700

> If we are to start running v2 as soon as (or even before) v1 gets finalized, possibly with an anti-ossification scheme like this (that comes along with downgrade protection), then I do not think we need to discuss inclusion of this PR in v1?

I disagree with that. Just because this mechanism isn't perfect, doesn't mean that it's not valuable in preventing ossification. And, as @mikkelfj pointed out, middleboxes can **always** just drop packets they don't like, so no mechanism will ever be perfect.
Preventing ossification of the version number is valuable no matter if v1 or v1 and v2 are rolled out at the same time. In addition, should designing v2 take longer than we hope now, this mechanism will hopefully get middleboxes used to the fact that valid QUIC traffic actually uses the whole range of version numbers.

-- 
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/2573#issuecomment-478447188

---

From: MikkelFJ <[email-masked]>
Date: Sun, 31 Mar 2019 23:57:56 -0700

mikkelfj commented on this pull request.

-
+## Version Aliases
+

If we have this, is there any point to the concept of reserved versions at all? Perhaps this depends on future version negotiation.

 ~~~

Also, while seconds are fine, do we have seconds as a unit anywhere else - otherwise milliseconds may be a better unit.

-- 
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/2573#pullrequestreview-220944442