Draft: draft-ietf-quic-v2

Commentary: pending the discussion on the list . 
 Let 's assume the current scenario : the client sends and the server decides to do compatible VN v1 - to - v2 . Then the server send its ServerHello in an INITIAL at v1 ( the draft explicitly allows this by making it a SHOULD and not a MUST : ) . At this point , there have only been QUICv1 packets exchanged . So the client can install handshake send keys for either version , but it is supposed to meet this requirement : even though the client does n't yet know what the negotiated version is . We have text in the right direction : but that 's not quite enough , we need to explain that the client learns about the version switch form the long headers and then validates it when it receives the server 's ChosenVersion 
 Since we 've closed , let me reiterate a test case here that we need to make sure is handled by the resolution of this issue : Client sends an INITIAL(ClientHello ) where LongHeaderVersion = v1 , ChosenVersion = v1 , and OtherVersions = v1,v2 Client receives server INITIAL(ServerHello ) where LongHeaderVersion = v1 Client receives server HANDSHAKE(EncryptedExtensions ) where LongHeaderVersion = v1 , ChosenVersion = v2 , and OtherVersions = v1,v2 
 Should n't the server have the LongHeaderVersion = v2 on its HANDSHAKE packets , once it has upgraded the connection to the negotiated version ? 
 Yes the server is n't supposed to do that ( sorry I should have made the clear ) . The question is : what should the client do when it sees the server misbehaving like this ? 
 If we 're in agreement the server is misbehaving , then I would suggest the client close the connection . 
 I 'm broadly OK with the shape of this change .  's suggestion might have made sense earlier in the process , but I do n't think that it works now . I 'm not sure that it worked ever , but I 'm less inclined to get precious about that sort of thing than I used to . LGTM but please wait until we 've agreed on what to do in the VN draft before mergingWorks for me . Crypto frames sing new VN makes sense .
The server SHOULD start sending its Initial packets using the
negotiated version as soon as it decides to change.  Before the
server is able to process transport parameters from the client, it
might need to respond to Initial packets from the client.  For these
packets the server uses the original version.
Once the client has processed a packet using the negotiated version,
it SHOULD send subsequent Initial packets using that version.  The
server MUST NOT discard its original version Initial receive keys
until it successfully processes a packet with the negotiated version.
Both endpoints MUST send Handshake or 1-RTT packets using the
negotiated version.  An endpoint MUST drop packets using any other
version.  Endpoints have no need to generate the keying material that
would allow them to decrypt or authenticate such packets.
The server cannot send CRYPTO frames until it has processed the
client's transport parameters.  The server MUST send all CRYPTO
frames using the negotiated version.
The client learns the negotiated version by observing the first long
header Version field that differs from the original version.  If the
client receives a CRYPTO frame from the server in the original
version, that indicates that the negotiated version is equal to the
original version.
Before the server is able to process transport parameters from the
client, it might need to respond to Initial packets from the client.
For these packets, the server uses the original version.
Once the client has learned the negotiated version, it SHOULD send
subsequent Initial packets using that version.  The server MUST NOT
discard its original version Initial receive keys until it
successfully processes a Handshake packet with the negotiated
version.
Both endpoints MUST send Handshake and 1-RTT packets using the
negotiated version.  An endpoint MUST drop packets using any other
version.  Endpoints have no need to generate the keying material that
would allow them to decrypt or authenticate such packets.