[Bug]: Retention of Unused Encryption Keys

[QUICTester]

What happened?

I am a member of a group investigating automated testing of QUIC protocol implementations. During our tests involving a XQUIC implementation with the commit version 00f6228, we identified 1 fault:

The unused encryption keys, such as the Initial key, should be discarded once QUIC has moved to the Handshake encryption level (https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys), same as the Handshake key after moving to the 1-RTT encryption level. An attacker can obtain the Initial key by capturing the Initial packets sent between the client and server during the connection establishment. If the server/client still accepts and processes Initial packets after they moved to the Handshake encryption level (after the server processes the first Handshake packet from the client), an attacker can disrupt the connection by sending a CONNECTION_CLOSE frame in an Initial packet to the server/client, causing a connection close that is not initiated by either the client or the server (DoS attack).

We believe this is a security vulnerability (according to the threat model in RFC9000) and we have sent our report to xquic@alibaba-inc.com and alibaba-cna@list.alibaba-inc.com 3 months ago (7 July 2023). However, we still haven't get any reply yet. We have also reported on 19 October 2023 and 2 February 2024. However, there is no progress in addressing this vulnerability.

Thank you for your time.

Steps To Reproduce

For Initial key:

1. Send an Initial packet carrying a CRYPTO frame with Client Hello message
2. When the server replies with Server Hello, Encrypted Extension, Certificate, Certificate Verify and Finished, send ACK to these messages.
3. Send an Initial packet carrying a CONNECTION_CLOSE frame (this should close the connection, but according to RFC 9001, the Initial key needs to be discarded once the server receives a Handshake packet carrying an ACK frame in step 2).

This also applies to Handshake keys:

1. Send an Initial packet carrying a CRYPTO frame with Client Hello message
2. When the server replies with Server Hello, Encrypted Extension, Certificate, Certificate Verify and Finished, send ACK to these messages.
3. Send a Handshake packet carrying a CRYPTO frame with Finshed message. The server will reply with HANDSHAKE_DONE frame.
4. Send a Handshake packet carrying a CONNECTION_CLOSE frame (this should close the connection, but according to RFC 9001, the Handshake key needs to be discarded once the server sent the HANDSHAKE_DONE frame in step 3).

Relevant log output

No response

[QUICTester]

Hi @yangfurong @Kulsk ,

How is the progress on resolving this vulnerability?

We reported this bug via the MITRE CVE program today (although we know that Alibaba is a CNA partner). We believe this is a vulnerability that should be addressed (as described in RFC 9001 https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys) and prioritized. If you need help in reproducing the vulnerability, please let us know. At a minimum, we would like an acknowledgment of our findings.

Thank you.