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