Subject: Tacking stuff on to VN packets

From: Martin Duke <[email-masked]>
Date: Tue, 11 May 2021 10:10:49 -0700

Section 6 of invariants
<https://quicwg.org/base-drafts/rfc8999.html#name-version-negotiation>
sayeth:

"Version Negotiation packets do not use integrity or confidentiality
protection. Specific QUIC versions might include protocol elements that
allow endpoints to detect modification or corruption in the set of
supported versions."

I also vaguely remember ekr batting around the idea of tacking some data
onto the packet  to solve a problem we were discussing.

*Maybe we just don't want to do this at all and we can safely ignore this
text in invariants.*

If we *do* want to do it, the design is a little problematic. There is no
length field in VN packets to signal that the supported version list is
ending and other stuff is beginning.

The only way I can think of to make this work is to use the VN draft to
reserve a magic version number to mean "this is the end of the supported
version list". That version is not a real version, MUST be the last one
listed, and perhaps can be followed by another magic number to indicate the
content that follows.

Leaving aside legacy stuff negotiating pre-standard versions, which will
hopefully go away someday, someone supporting multiple versions would be
REQUIRED to support the VN draft and therefore incorporate this change.

Thoughts?
Martin

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 May 2021 10:18:21 -0700

Unfortunately that won't work. Supporting multiple versions of QUIC does
not require supporting any document, apart from the QUIC invariants. And
the invariants don't reserve space for a trailer after the Supported
Versions field. What problem are you trying to solve with this trailer? I
suspect there are easier ways of solving it.

David

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 May 2021 10:28:28 -0700

> What problem are you trying to solve with this trailer?

For the purposes of this discussion, I'm wondering about this idle
speculation in the invariants draft. Having this field would simplify some
problems in an individual draft I'm working on, but there are other ways to
fix it.

If no one is going to say "Yes we should have this capability" then we can
either excise the text from invariants or, at this late stage, at least
have an understanding that this text doesn't mean anything.

Martin

---

From: David Schinazi <[email-masked]>
Date: Tue, 11 May 2021 10:43:27 -0700

Can you clarify why you want to remove that text from invariants? It seems
correct to me: it states that the VN packet conveys Supported Versions
without a way to authenticate this data. Other protocol elements can
authenticate the data. For example,  draft-ietf-quic-version-negotiation
does allow endpoints to detect modification or corruption in the set of
supported versions.

David

On Tue, May 11, 2021 at 10:28 AM Martin Duke <[email-masked]>
wrote:

>>> *Maybe we just don't want to do this at all and we can safely ignore
>>> this text in invariants.*
>>>
>>> If we *do* want to do it, the design is a little problematic. There is
>>> no length field in VN packets to signal that the supported version list is

---

From: Martin Duke <[email-masked]>
Date: Tue, 11 May 2021 13:30:27 -0700

Ah, perhaps I'm misinterpreting this to mean that that data  is in the VN
packet itself. I accept that your reading probably makes more senese.

On Tue, May 11, 2021 at 10:43 AM David Schinazi <[email-masked]>
wrote:

>> If no one is going to say "Yes we should have this capability" then we
>> can either excise the text from invariants or, at this late stage, at least
>>>> I also vaguely remember ekr batting around the idea of tacking some
>>>> data onto the packet  to solve a problem we were discussing.
>>>>
>>>> Leaving aside legacy stuff negotiating pre-standard versions, which
>>>> will hopefully go away someday, someone supporting multiple versions would
>>>> be REQUIRED to support the VN draft and therefore incorporate this change.
>>>>
>>>> Thoughts?
>>>> Martin
>>>>
>>>>
>>>>