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

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 May 2019 04:39:36 -0700

Question in London: Do you believe that we need to ship a mechanism to mitigate version ossification prior to v1? result -- strongly in favour of addressing.

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

---

From: ekr <[email-masked]>
Date: Wed, 22 May 2019 04:42:42 -0700

I'm not a huge fan of this particular design, as it involves some odd state stuff.

Here's another possibility, borrowed from a design by david benjamin:

1. Each version has a random seed.
2. The version number field is computed as H(seed, <parts of the packet>)

The receiver then iterates through all the potential version numbers and checks the version number.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 04:44:39 -0700

The field is short, so collisions will happen.  The client won't necessarily know about all the versions that the server supports, so it can't know that a collision has occurred.

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

---

From: ekr <[email-masked]>
Date: Wed, 22 May 2019 11:46:22 +0000 (UTC)

Well, collisions will be quite rare unless there are a *lot* of versions. And even once there is a collision, you can test-decrypt.

Actually, it's worth noting that you could just remove the QUIC version entirely.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 May 2019 04:48:33 -0700

If we go for trial decryption (which isn't that crazy), then we can drop the version number field.

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

---

From: ekr <[email-masked]>
Date: Wed, 22 May 2019 04:50:13 -0700

The trial-decryption version is also compatible with the ESNIKeys approach.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 05:12:09 -0700

I like the trial decryption approach. The only problem is that random garbage sent to the server will now require not one 1200 byte trial decryption, but N such, where N is the number of supported versions. However, any trivial way to speed this up makes it equally cheap for middle boxes to filter.

There is a risk that future QUIC versions will reuse salts for initial keys to reduce the trial decryption load and encode the version information by other means.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 06:03:52 -0700

As a software developer I'm happy with trial decryption. The cost is so trivial compared to public key crypto.

It could be an issue for hardware offload, though I think we can live without hardware assistance for Initial packet processing.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 22 May 2019 14:14:32 +0000 (UTC)

If we are to remove the version number field in favor of trial decryption, we need to figure out how a server would figure out a packet that failed to decrypt was a connection establishment attempt, so that  it can send a Version Negotiation packet. Otherwise, a client would no longer be possible to fallback to a different version.

One way of resolving the problem is to use the QUIC bit as a SYN bit. If the server fails to trial-decrypt the packet in any of the versions it supports, the server would send a Version Negotiation packet.

Having a SYN bit also helps the server, because trial decryption would only be required for packets that have the flag set.

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 22 May 2019 07:35:36 -0700

The version field could also be replaced with zero padding and encrypted with a version 0 salt (QUIC invariant the rules that packet) and packet content nonce. If the field does not decode to 0, it was not a QUIC packet, at least not one using expected invariants.

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2019 03:20:34 -0700

I am trying to summarize the set of version obfuscation proposals. I believe we have:

1) Natural versions. Just define a version 2, maybe 1bis, very quickly, and actually use version negotiation.

2) Server specific version aliases,as specified in #2573

3) Version based obfuscation and trial decryption, as proposed by David Benjamin and explained on this thread

4) Introduce a "QUIC Version" TLS extension, sent either in the clear or passed as an encrypted extension to the ESNI content.

There are pros and cons to each of those:

proposal | Pros | Cons 
--- | --- | ---
Natural version | Very little code required | Still risk of ossification
Server defined aliases | Robust prevention | Does not protect 1st packet; Requires caching code; May enable tracing
Version based obfuscation | Robust prevention | Requires trial decryption
TLS extension | Can be encrypted | Requires ESNI

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2019 03:57:49 -0700

Thinking some more, I believe that David Benjamin's "version based" solution does not actually prevent ossification. The middle boxes will be programmed with the seeds of version 1. They will try decrypt with V1, and if the result is not "version = version 1" they will just say "this is not QUIC" or otherwise drop the packet.

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2019 05:18:59 -0700

About the QuicVersion TLS extension: I think that EKR had a proposal already. Basically, encode the proposed version number as a TLS option. Optionally, encode the supported options in the client message, ordered by preference, and the selected option in the server response.

The client *could* send the option as a ClientHello extension, but that is not encrypted, so it does nothing t prevent ossification. But if the client sends the ESNI extension, then the TLS extension can be encrypted as part of the ESNI content, and so it is safe.

There is a downside to encoding the version in a TLS extension: it is only readable if the Initial message can be parsed. Parsing requires understanding the format of the Initial message, and that requires understanding the version used for encoding the message. That probably means accepting ossification of the Initial format, which is close to "conceding defeat".

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 05:28:10 -0700

TLS versioning assumes that all QUIC versions use TLS, which I'm not sure is a good idea.

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 May 2019 06:22:21 -0700

What if the middle-box just replies with a Version Negotiation message to any message for which it does not understand the version field? This will defeat the "natural version" and "server based obfuscation" options. For example, in the server based obfuscation case, the client will immediately repeat the request with Version 1. The middle box will cause a delay penalty, but a fairly minimal one.And we removed the protection against version downgrade from the transport spec.

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

---

From: MikkelFJ <[email-masked]>
Date: Thu, 23 May 2019 06:27:54 -0700

We cannot prevent that if the middelbox drops the initial packet. That is an unsolvable problem because the middle box can be a valid endpoint up to and excluding TLS cert validation. But I think I have argued earlier that we should quarantine version and retry packets to see of the something better shows up before taking action.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 23 May 2019 06:29:28 -0700

@huitema 
> And we removed the protection against version downgrade from the transport spec.

That would be an easy thing to re-add to the transport.

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