Subject: [quicwg/base-drafts] Add length field to version negotiation packet (invariants) (#1247)

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Mar 2018 07:13:26 -0700

Add a length field to the list of versions in the version negotiation packet and allow future versions to extend the field, for example with a public signature as suggested in #1246 

```
 0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |1|X X X X X X X|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Version (32) = 0                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |DCIL(4)|SCIL(4)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Destination Connection ID (0/32..144)         ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Source Connection ID (0/32..144)            ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Version count (8)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Supported Version 1 (32)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   [Supported Version 2 (32)]                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   [Supported Version N (32)]                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Mar 2018 07:18:42 -0700

I talked about exactly this with @siyengar last night. I think it makes sense to have a way to future-proof the vneg packet, since it is part of the invariants.

We might even want to go as far as defining some TLV scheme for UDP payload space past the included options.

-- 
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/1247#issuecomment-374952757

---

From: ianswett <[email-masked]>
Date: Wed, 21 Mar 2018 07:21:36 -0700

We can always pick a new version number and define a version negotiation packet v2.  This does not require a change in the existing version negotiation packet with version number 0.

-- 
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/1247#issuecomment-374953827

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Mar 2018 07:33:11 -0700

I expect the network to ossify that 0 for us

-- 
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/1247#issuecomment-374958027

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Mar 2018 11:16:21 -0700

This isn't an issue, it's a proposed solution.

The problem with trying to sign version negotiation is that you don't have an existing relationship with the server to enable any kind of signing key.  So the method that invariants already calls out, in which the contents of the VN packet are authenticated after the fact, seems the most reasonable.

-- 
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/1247#issuecomment-375045348

---

From: Lars Eggert <[email-masked]>
Date: Wed, 21 Mar 2018 11:20:46 -0700

True on this being a solution. And, I don't actually care about the signing part, which is in another issue.

I care about potentially being able to stick stuff other than versions into a vneg response in the future.

-- 
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/1247#issuecomment-375046839

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Mar 2018 18:31:07 +0000 (UTC)

> The problem with trying to sign version negotiation is that you don't have an existing relationship with the server to enable any kind of signing key

That is an assumption. You can easily have a relation with the host even if that model does not match the current TLS 1.3 / HTTP/QUIC model. For example that Verisign says that it isn't evil. It just requires a 64 bit verisign identifier, and signature. Or you it could be your own server, but vneg is still a thing due to cluster upgrades.

More generally, this is about being able to add to the vneg for unforseen issues in future 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/issues/1247#issuecomment-375050082

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Mar 2018 18:39:52 +0000 (UTC)

But both Mike and Ian are right - it is a proposed solution to an extension issue - changing the version number from 0 to something else is another option.

I just worry that people will start to hack pseudo version numbers in the version table to carry additional data (a sort of TLV as Lars suggests), so overall, adding a length field seems to be the least intrusive form - it would allow random data to follow and it could ossify, but so could pseudo versions.

-- 
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/1247#issuecomment-375052842

---

From: ianswett <[email-masked]>
Date: Wed, 21 Mar 2018 12:11:39 -0700

I'm ok with adding a length and leaving the remaining payload for future use, such as signatures.

-- 
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/1247#issuecomment-375062598

---

From: hardie <[email-masked]>
Date: Thu, 22 Mar 2018 09:42:33 +0000 (UTC)

Noting the discussion in London, interpreting the data after the versions will be difficult, unless you get into things like combining the versions in a specific order having a specific meaning for the follow-on data.  It's going to end up getting very crufty very fast. See also the experience with TLS 1.0 on this.

-- 
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/1247#issuecomment-375235922

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2018 02:43:54 -0700

Closing this in deference to #1246 (this is a specific proposal for that issue, and better expressed as a comment on that issue, or a PR).

-- 
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/1247#issuecomment-375236268

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2018 02:43:55 -0700

Closed #1247.

-- 
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/1247#event-1535134978