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 protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> >>>> >>>>
