Change:
parameters to validate that the server sent the Retry and the connection IDs used in the exchange, as described in QUIC. <del> 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 </del> <ins> 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 </ins> 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.

Discussion:
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 doesn'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
Shouldn't the server have the LongHeaderVersion=v2 on its HANDSHAKE packets, once it has upgraded the connection to the negotiated version?
Yes the server isn'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. David's suggestion might have made sense earlier in the process, but I don'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.