Change:
The draft currently states: I think we should weaken this to only require the downgrade prevention aspect of QUIC-VN. Chrome doesn't currently support incompatible version negotiation and we don't plan to change that when we add support for v2.
I agree that 'fully support' is too onerous. However, it is not really clear to me what the minimum set of VN support is. The VN draft doesn't really envision partial support. If a client includes the version information TP, it MUST support compatible negotiation. A server that sends VN packets (as they all should!) MUST support incompatible negotiation. So for clients, AFAICT there are three levels of support: 1) No support: do not the send the TP. If you get a VN packet, switch to TCP 2) Compatible only - send the TP, be prepared to accept an upgrade 3) Full: respond to VN packets with incompatible negotiation. For servers, it would be 1) Send the TP and support incompatible negotiation 2) Support compatible negotiation
I don't think that's right. The client can just always send Therefore, for clients, the options are: No support: do not the send nor parse the TP. If you get a VN packet, fail the QUIC connection Downgrade prevention only: send the TP with only one other version, also parse and validate the TP. If you get a VN packet, fail the QUIC connection Compatible only: downgrade prevention and be prepared to accept an upgrade Incompatible only: downgrade prevention and retry with new version when receiving VN Full: downgrade prevention, compatible VN and incompatible VN I agree with what you said about servers.
I don't understand 2. If only one version is advertised, what downgrade are we preventing? Also, I don't see how (4) works if the server decides to do a compatible VN. Is the idea that the client only advertises support for one version in its TP?
Let's say the client tries version B and the server supports both versions A and B. An active network attacker can intercept the client's version B packets and rewrite them as version A before forwarding them to the server - then you would end up with a connection where the client thinks it's speaking version B and the server thinks it's speaking version A. If version A is vulnerable to an attack that B isn't, the attacker managed to downgrade the security from version B to version A. In practice this attack doesn't work with v1 and v2 because we changed the HKDF labels, but the attack could work on other versions. This entire class of problem goes away if you add the Chosen Version to the TLS transcript, so there's some value in the downgrade-prevention-only mode. That's right.
(2) Offline, David clarified that the attack doesn't work in v1/v2 because the handshake packets authenticate the version field. but this is not generalizable to all QUIC versions. as for (4), thanks, makes sense.
I filed URL I think the right language for this draft is something to the effect of "Endpoints that support multiple versions MUST meet the minimum requirements described in {{QUIC-VN}}."
It's not entirely clear what minimal support is, but we have an issue for that :-)

Discussion:
4. QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any <del> QUIC endpoint that supports multiple versions MUST fully implement QUIC-VN to prevent version downgrade attacks. </del> <ins> QUIC endpoint that supports multiple versions MUST meet the minimum requirements described in QUIC-VN to prevent version downgrade attacks. </ins> Note that version 2 meets that document's definition of a compatible version with version 1.  Therefore, v2-capable servers MUST use