Draft: draft-ietf-quic-v2

Commentary: The draft currently states : I think we should weaken this to only require the downgrade prevention aspect of QUIC - VN . Chrome does n't currently support incompatible version negotiation and we do n'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 does n'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 do n't think that 's right . The client can just always send Therefore , for clients , the options are : support : do not the send nor parse the TP . If you get a VN packet , fail the QUIC connection 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 only : downgrade prevention and be prepared to accept an upgrade only : downgrade prevention and retry with new version when receiving VN : downgrade prevention , compatible VN and incompatible VN I agree with what you said about servers . 
 I do n't understand 2 . If only one version is advertised , what downgrade are we preventing ? Also , I do n'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   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 is n't , the attacker managed to downgrade the security from version B to version A. In practice this attack does n'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 ,  clarified that the attack does n'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 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 :-)
QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any
QUIC endpoint that supports multiple versions MUST fully implement
QUIC-VN to prevent version downgrade attacks.
QUIC version 2 endpoints SHOULD also support QUIC version 1.  Any
QUIC endpoint that supports multiple versions MUST meet the minimum
requirements described in QUIC-VN to prevent version downgrade
attacks.