Subject: [quicwg/base-drafts] QUIC Invariants don't specify ordering semantics of Version Negotiation packets (#4743)

From: David Schinazi <[email-masked]>
Date: Wed, 13 Jan 2021 17:50:44 -0800

Apologies for filing an issue so late in the game, but I think this should be an easy fix.

As I was working on draft-ietf-quic-version-negotiation, I realized that I was assuming that the Supported Version fields of a Version Negotiation packet are ordered by decreasing preference. Google servers also send Version Negotiation packets that way. But our drafts do not specify this. draft-ietf-quic-invariants specifies the format of Version Negotiation packets, but this is all it says about the Supported Versions field:
> After the Source Connection ID field, the Version Negotiation packet contains a list of Supported Version fields, each identifying a version that the endpoint sending the packet supports. A Version Negotiation packet contains no other fields. An endpoint MUST ignore a packet that contains no Supported Version fields, or a truncated Supported Version.

It would be unfortunate if a server ordered versions by decreasing preference, and a client parsed them as increasing preference and respected its understanding of the server's preference.

I see three paths forward here:
1. State in draft-ietf-quic-invariants that the ordering has no semantics
2. State in draft-ietf-quic-invariants that the Supported Version fields are ordered by decreasing preference
3. Do nothing and leave this ambiguous

I personally prefer 2, as it follows our design goal to clearly define the semantics of QUIC's wire format. This would also be consistent with Alt-Svc, which is [explicitly ordered by decreasing server preference](https://tools.ietf.org/html/rfc7838#section-3).

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 13 Jan 2021 18:06:35 -0800

I'm not sure if we should have semantics in invariants.

The problem here is that there's no guarantee that Supported Versions will be authenticated in any version of QUIC. QUIC v1 does not have such authentication.

If a version of QUIC applies semantics to the ordering of Supported Versions, it would be susceptible to version downgrade attacks, as [acknowledged in Section 6.2 of the transport draft](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-handling-version-negotiatio).

I tend to think that the semantics should be defined in the version negotiation draft. At the same time, I think it might make sense to move the discussion in Section 6.2 of the transport draft to the invariants draft.

-- 
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/4743#issuecomment-759876437

---

From: Martin Thomson <[email-masked]>
Date: Wed, 13 Jan 2021 18:09:20 -0800

Option 3 is fine.  It was always my understanding that this was deliberately done.  That is, order carried no explicit semantics.

I don't see any value in the server signalling its preferences. It isn't a feature in TLS that has ever really worked.

-- 
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/4743#issuecomment-759877317

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 14 Jan 2021 10:46:48 -0800

I agree with both @kazuho and @martinthomson. I'll say that Option 3 is not an accurate reflection of the state of affairs -- draft-ietf-quic-transport unambiguously conveys no preference.

There are two discussions to be had:
- Is conveying this information useful? (@martinthomson says no, but this does seem useful to me; I am interested in having this discussion)
-  How do you authenticate this information? @kazuho is exactly on point here -- applying any semantics to ordering will mean that the ordering will need to be authenticated.
 
Given the apparent complexity of the authentication, I don't think the ordering semantics need to be an invariant. But I would like to see the discussion on the VN draft.

I don't think we should move 6.2 of the transport draft to invariants. Of the text there, the only normative text is about client action on VN packets, and I don't think that is an invariant.

-- 
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/4743#issuecomment-760395727

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Jan 2021 11:48:35 -0800

@kazuho could you elaborate on what the concern is for authenticating ordering? For the Supported Version list to be useful it needs to be authenticated whether it is ordered or not. I think authentication is orthogonal to ordering. I'll also note that the mechanism in draft-ietf-quic-version-negotiation that authenticates Supported Versions happens to also authenticate the ordering, because it just copies Supported Versions to somewhere in a transport parameter.

@janaiyengar given that the VN packet format is part of invariants, it's not possible to add ordering semantics later - what if two different versions of QUIC (or two different extensions) apply different ordering semantics, how do you know which one is in use?

I also believe that conveying server preference is useful, we use it actively in Alt-Svc and the whole point of version negotiation is for use-cases where you don't have Alt-Svc.

-- 
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/4743#issuecomment-760435984

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 14 Jan 2021 14:10:15 -0800

Given that the client initiates the connection, it's up to the client to pick a compatible version. As such, I would expect the client to treat the server's list as an "unordered set". I would then expect the client to chose the client most preferred version that is in the server's set. So I think order is not important here.

-- 
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/4743#issuecomment-760507567

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2021 14:56:15 -0800

What Ryan said.  The only entity that can express an opinion is the server as it sends the message.  But the client's opinion is the only relevant one as it is the one that has to act on the information.

You might think that the client might allow its opinion to be informed by the server, but I can think of just one example of where that was arguably useful in TLS.  It's not worth it.

-- 
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/4743#issuecomment-760528586

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Jan 2021 15:22:45 -0800

@DavidSchinazi The only case where ordering might become of some value is when clients support multiple versions. But for clients to support multiple versions, authenticating Supported Versions is essential, because otherwise they would be susceptible to version downgrade attacks.

IIRC, our deliberate decision was to not define downgrade attack prevention in QUIC v1, because it is the first version of QUIC. Assuming that clients support only _one_ version of QUIC, there is no need for downgrade attack prevention, or ordering in Supported Versions.

> given that the VN packet format is part of invariants, it's not possible to add ordering semantics later

I'm not sure if agree with this statement. Invariants is what we promise at this point to not change. I do not think it forbids us from making new promises as we make progress.

-- 
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/4743#issuecomment-760540652

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2021 15:32:18 -0800

> Invariants is what we promise at this point to not change. I do not think it forbids us from making new promises as we make progress.

I don't think that this is a statement that is safe to make in general.  By declaring some things invariant, we have constrained what we can do.

In this specific case, we might have a little bit of wiggle room, as there are no versions of QUIC that rely on these fields.  However, it might need an update to the document to effect.

-- 
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/4743#issuecomment-760544183

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Jan 2021 15:40:55 -0800

Right. We cannot remove or change existing constraints, but we can add new one if doing so does not break anything. That is where adding semantics to Supported Versions falls into.

That can be an option that we can take _if_ we think in the future that there's value in having ordering semantics.

-- 
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/4743#issuecomment-760547041

---

From: David Schinazi <[email-masked]>
Date: Thu, 14 Jan 2021 16:18:43 -0800

I'd argue that it's easier to remove a constraint than to add one - because someone could already be violating a constraint we'd want to add.

-- 
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/4743#issuecomment-760559736

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2021 16:19:41 -0800

It would be, but then you still need to establish why it is the right constraint to be adding.

-- 
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/4743#issuecomment-760560113

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Jan 2021 17:00:23 -0800

Or, a less-intrusive option to introduce ordering semantics at a later moment would be to specify a QUIC version that changes how Supported Versions is to be interpreted. For example, the version negotiation draft might define a magic version number that is used to indicate to the client that the rest of the versions that are provided in the order of server's preference.

Regarding which entity should drive protocol selection, I tend to think that it should be the one that is better maintained. If we compare major web browsers vs. servers, I agree with others that it is the client for sure. But in the future, we might see application protocols using QUIC that have different characteristics.

Therefore, I tend to think that we should leave the decision up to future documents (i.e. option 3). And that is possible, as I have been arguing.

-- 
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/4743#issuecomment-760574432

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Jan 2021 03:26:35 -0800

@DavidSchinazi any further comments? Or can this be closed?

-- 
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/4743#issuecomment-767480955

---

From: David Schinazi <[email-masked]>
Date: Tue, 26 Jan 2021 13:22:35 -0800

@larseggert from the discussion on the issue, it appears I am in the rough here. But since this is not an editorial issue, and since we will not be able to fix this cleanly later because it's in the invariants, I think it would make sense to have a consensus call on list where the proposed outcome is close with no action. But it's definitely the chairs' responsibility to decide how they wish to assess consensus here :)

-- 
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/4743#issuecomment-767836097

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 26 Jan 2021 16:10:09 -0800

We're late in the document lifecycle and I'm not seeing support for taking on a design change. The constituency interested in the QUIC drafts has been widened via IETF last call and IESG review, changes to how things interoperate risks invalidating their review and setting us back.

-- 
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/4743#issuecomment-767913770

---

From: David Schinazi <[email-masked]>
Date: Tue, 26 Jan 2021 16:23:11 -0800

@LPardue that's fine by me. As we say in this WG, "No, I will absolutely not die on this hill!"

-- 
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/4743#issuecomment-767918227

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 26 Jan 2021 17:01:00 -0800

IIRC the [precise phrase](https://github.com/quicwg/wg-materials/blob/master/interim-20-02/minutes.md) is

> Dmitri: I refuse to die. [applause] 

Either way, thanks for the confirmation @DavidSchinazi

-- 
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/4743#issuecomment-767934410

---

From: Lars Eggert <[email-masked]>
Date: Tue, 26 Jan 2021 23:52:43 -0800

Closed #4743.

-- 
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/4743#event-4254426670