Server Initial Read Key is discarded on Compatible Version Negotiation

[anrossi]

Describe the bug

The QUIC version 2 draft says that a server which upgrades a client to Version 2 via Compatible Version Negotiation (CVN)

The server MUST NOT discard its original version Initial receive keys until it successfully processes a packet with the negotiated version.

Source

This was not implemented yet, and is difficult to test

Affected OS

• [ ] All
• [ ] Windows Server 2022
• [ ] Windows 11
• [ ] Windows Insider Preview (specify affected build below)
• [ ] Ubuntu
• [ ] Debian
• [ ] Other (specify below)

Additional OS information

No response

MsQuic version

main

Steps taken to reproduce bug

1. Client sends an Initial packet with all the crypto payload in it. Client VersionInfo starts with Version 1, but supports Version 2.
2. Server processes client Initial packet and uses CVN to upgrade client to Version 2. Server discards both read and write initial keys for Version 1, and replaces them with Initial keys for Version 2.
3. Client sends a second Initial packet with padding(??), before processing the Server's flight.

Expected behavior

The Server should still be able to read the Client's second Initial packet until the Client acknowledges the CVN by sending a Handshake flight with the new version.

Actual outcome

Server fails to decrypt client's second Initial packet and drops it.

Additional details

No response

[nibanks]

Let's look at this and discuss next month.