Subject: [quicwg/base-drafts] QUIC Ossification (#2496)

From: martinduke <[email-masked]>
Date: Mon, 04 Mar 2019 14:09:29 -0800

There is a long conversation happening in the mailing list about QUIC version number ossification:
https://mailarchive.ietf.org/arch/browse/quic/?gbt=1&index=ytjKHacss9s3i3nualU2tbU9Jco
I'm adding it here to bring in others and consider it on the agenda for a WG meeting.

I won't try to summarize everyone's position from the thread. Given the status quo, it would be easy for someone to write a dumb middlebox that drops QUIC version > 1, or indeed version > 2. This appears to have happened with TLS v1.2. Given all of our effort to counter ossification, it would be tragic if we fell down on this rather simple hurdle.

There is disagreement as whether obfuscation is valuable or not. Though I have no answers, I personally would like to explore a few questions:
1) Are there any changes to VN we can make to reduce the chance of ossification happening?
2) If ossification happens anyway, do we have strategy to do something to overcome it?
3) If we are going to end up with some more obscure mechanism, does it make sense to lock in on bytes 2-5 of every long header to be 0x00000001 in perpetuity?

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Mar 2019 22:29:39 -0800

I originaly thought this is pointless. The registry key story both confirms that it is pointless but also, along with TLS version history, that it is a real concern.

So weak obfuscation will not work. Random values that are public will not work. Genersted values that are easy to compute will not work.

I was thinking challenge response, which is the same as init packet encryption. But that is version specific.

There need to be a time or implementation complexity component like key derivation.

But that is costly to the peers, but perhaps not too costly compared to 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/issues/2496#issuecomment-469556764

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 04 Mar 2019 23:01:06 -0800

> Are there any changes to VN we can make to reduce the chance of ossification happening?

We only have obfuscation to protect the payload format of Initial packets from ossification. Therefore, IMO the question is if we can have something similar for the version number field, without making the protocol complex.

As some have pointed out, using multiple version numbers on wire to designate "version 1" is one way to go. That would be sufficient as a protection against middlebox vendors who try to use the version number field in some ways in negligence. I also think that that might be the only thing that we can do without making the "version number obfuscation scheme" an invariant.

We could do various things if we think that it is a good idea to make the obfuscation scheme an invariant. For example, we could set the version number field to a XOR value of the version number and four octets that follow the DCIL/SCIL fields (i.e. `version_number_field = version_number XOR packet[6..9]`). Such scheme would IMO require the middlebox vendors to actually consult the specification when they try to detect the QUIC protocol version. In other words, it would be as reliable as the AES-based ossification scheme we use for Initial packet payload.

-- 
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/2496#issuecomment-469563881

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Mar 2019 17:47:11 -0700

There's clearly appetite to consider this in the WG, so marking as `design`.

-- 
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/2496#issuecomment-472236255

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Sat, 23 Mar 2019 04:07:40 -0700

I like to re-state my earlier proposal to solve this issue by Introducing a new "Version Alias" Frame:
 - the server includes a list which other version numbers it also accepts for the currently used QUIC version
 - it also includes a timeout telling the client how long it may use these aliases.

This design allows to grease the whole version number range, e.g. by generating the aliases based on time windows and a local salt, without risking version clashes, as the alias numbers timeout. The only limitation of this scheme is that the server must make sure that the alias versions do not clash with version numbers the server is going to support within the timeout.

-- 
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/2496#issuecomment-475860714

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Mar 2019 01:47:46 -0700

Discussed in Prague; hum supported closing (with impact on applicability statement), but was not unanimous. Will try to establish consensus on-list; people who want to continue should focus on establishing a threat model.

-- 
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/2496#issuecomment-477042002

---

From: Brian Trammell <[email-masked]>
Date: Wed, 27 Mar 2019 08:48:49 +0000 (UTC)

See also quicwg/ops-drafts#62

-- 
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/2496#issuecomment-477042428