Original text:
Supported Version. Version Negotiation packets do not use integrity or confidentiality <del> protection.  Specific QUIC versions define mechanisms to authenticate the packet as part of the connection establishment process. </del>  An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID The Version Negotiation packet described in this document is not integrity-protected; it only has modest protection against insertion <del> by off-path attackers.  QUIC versions MUST define a mechanism that authenticates the values it contains. </del>  8.

Reviewer comments:
This clarifies that it is a mechanism in the target QUIC version that authenticates the information. This also lifts the strong requirement on authenticating the contents of Version Negotiation. QUIC version 1 does not do this and so does not comply with this requirement. The intent was always that only information that is used needs to be authenticated in this way. (This is a tiny bit of evasion as Version Negotiation is used in QUIC version 1 as a signal that a version is not supported, which results in clients abandoning connections.)
This is for -invariants-09: Section 6 says: Version Negotiation packets do not use integrity or confidentiality protection. A specific QUIC version might authenticate the packet as part of its connection establishment process. Is the second not contradicting what is said in previous paragraph: A Version Negotiation packet contains no other fields. So to my understanding the authentication that the paragraph above talks about needs to be done in another QUIC packet, it can't be done in a QUIC packet that is Version Negotiation. Can this be made more explicit or do I misunderstand and can you then clarify why this is not a contradiction?
I don't see this as contradictory. The sentence here: Implies that the version fields might be authenticated. Indeed, the document says that they MUST be authenticated (somehow). It doesn't say how. However, this ... means that it can't use any fields that are included in a Version Negotiation packet to do that. If you look at the current proposal for , that uses transport parameters.
Ok, then I would request a very minor tweak in this sentence: A specific QUIC version might authenticate the packet as part of its connection establishment process. So that it is explicit that is in another packet(s) than the Version negotiation packet. For example: A specific QUIC version might authenticate the version negotiation packet as part of its connection establishment process outside of this packet.
I have made a slightly larger tweak.

Revised text:
Supported Version. Version Negotiation packets do not use integrity or confidentiality  <ins> protection.  Specific QUIC versions might include protocol elements that allow endpoints to detect modification or corruption in the set of supported versions. </ins> An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID The Version Negotiation packet described in this document is not integrity-protected; it only has modest protection against insertion  <ins> by off-path attackers.  An endpoint MUST authenticate the contents of a Version Negotiation packet if it attempts a different QUIC version as a result. </ins> 8.