Change:
NAME confirmed offline that he can live with this PR as-is, so I'm merging it
Currently at says future versions might allow the long header version to be different from the chosen version in the versioninfo transport parameter. But there's nothing about what to do until such a version exists which changes the semantics of the chosenversion. This is in the initial packet, before incompatible version negotiation, and before compatible version negotiation, has happened. Which error should the handshake be closed with? says that version info transport parameter parsing errors should use the transport parameter error.
Thinking about this some more, I think draft-ietf-quic-version-negotiation doesn't need to say anything more, as those details are specific to the compatibility version document. So I opened URL to discuss this there.
I'm a little confused because this document explains which errors should be used with QUIC v1 when closing the connection on failure to parse the transport parameter or invalid versions (i.e. 0). In the absence of another compatibility version document, shouldn't this document specify the error for QUIC v1? Or are you saying this is not an error in QUIC v1, but could be an error in, e.g., QUIC v2?
This only causes an error when there are two versions involved - and therefore that scenario should be covered by the document that defines compatibility between those two versions. Or do you have a scenario in mind where one version is QUICv1 and the other is unknown? I'm noticing that RFC 9000 doesn't say what you're supposed to do if you receive a packet from another version - I think the assumption is that you silently drop it because you don't know how to parse it.
Agreed that I should specify the v1/v2 case. But perhaps the VN draft should handle the behavior when the long header has a known version (certainly v1) and the Chosen Version is unknown? (I imagine that allowing this allows us to have a backdoor for version upgrade if the version field ossifies)
I would recommend that a server sends a VN packet in this case, and a client kills the connection -- there is no valid reason for the server to slip in a version the client didn't advertise.
Rereading what NAME originally wrote along with NAME comments, I think we can tighten up the validation requirements in this spec to prevent tampering. I've written it up as , please take a look. NAME I went with forcing a close instead of your suggestion, because this back door would weaken the protocol (allows tampering) without helping (if the long header ossifies we can use compatible VN as our backdoor).
I'm not sure compatible VN is sufficient. If someone writes a firewall that says "drop all Long Headers with version == 4" I don't see that compatible negotiation solves the problem -- all the long headers have to say v1 and the actual negotiation happens using TPs. Though I haven't fully thought this through, and certainly not any backdoor implications.
Note that the requirement is only for the client's first flight. So you work around that firewall by defining v1-to-v4 compatibility as always setting Version=1 in long headers
Yeah, I think that works.
WFM. David pointed out that this already defines "in use" and the change to "processes" is good.LGTM

Discussion:
packets it receives in response to that connection attempt. Both endpoints MUST parse their peer's Version Information during the <del> handshake.  If parsing the Version Information failed (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version equal to zero, or any Available Version equal to zero, it </del> <ins> handshake.  If that leads to a parsing failure (for example, if it is too short or if its length is not divisible by four), then the endpoint MUST close the connection; if the connection was using QUIC version 1, that connection closure MUST use a transport error of type TRANSPORT_PARAMETER_ERROR.  If an endpoint receives a Chosen Version equal to zero, or any Available Version equal to zero, it MUST treat it as a parsing failure.  If a server receives a Version Information where the Chosen Version is not included in Available Versions, it </ins> MUST treat it as a parsing failure. Every QUIC version that supports version negotiation MUST define a

For QUIC version 1, version negotiation errors are signaled using a transport error of type VERSION_NEGOTIATION_ERROR; see iana-error. <ins> When a server receives a client's first flight, the server will first establish which QUIC version is in use for this connection in order to properly parse the first flight.  For example, the server determines that QUIC version 1 is in use by observing that the Version field of the first Long Header packet it receives is set to 0x00000001.  When the server then processes the client's Version Information, the server MUST validate that the client's Chosen Version matches the version in use for the connection.  If the two differ, the server MUST close the connection with a version negotiation error.  For example, if a server receives the client's Version Information over QUIC version 1 (as indicated by the Version field of the Long Header packets that carried the transport parameters) and the client's Chosen Version is not set to 0x00000001, the server will close the connection with a version negotiation error. If a client receives a Version Information where the server's Chosen Version was not sent by the client as part of its Available Versions, the client MUST close the connection with a version negotiation error. </ins> If the Version Information was missing, the endpoints MAY complete the handshake.  However, if a client has reacted to a Version Negotiation packet and the Version Information was missing, the