Re: Tacking stuff on to VN packets

[Martin Duke <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]>
> wrote:
>
>> > 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
>>
>> On Tue, May 11, 2021 at 10:18 AM David Schinazi <[e-mail]>
>> wrote:
>>
>>> 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
>>>
>>> On Tue, May 11, 2021 at 10:11 AM Martin Duke <[e-mail]>
>>> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>>