msquic — Hybrid key share large enough to split the Initial across packets

Not run

Not attempted.

This client was not driven through this test.

On the TLS tier this usually means more than it says. Each of these ports will negotiate exactly one key exchange group, so a client that cannot negotiate that group never completes a handshake, never establishes a connection, and leaves the server nothing to judge. For a hybrid-only port that reads as no post-quantum key exchange offered — which is a finding about the client rather than a gap in the run.

What was measured

Client

msquic — .NET HttpClient + msquic, 2.7.0

Test

Hybrid key share large enough to split the Initial across packets — t-hybrid-large-hello

Clause

RFC 9000 §8.1, §14.1, RFC 9001 §4.4 (MUST)

Class

resilience — Recovered rather than giving up.

Required behaviour

Complete the handshake with a ClientHello that does not fit one QUIC Initial packet. An ML-KEM-768 key share is 1,216 bytes, which pushes a ClientHello past the 1,200-byte floor RFC 9000 §14.1 sets for an Initial, so the flight must be spread over more than one packet and every one of them padded to the full size. This is the concrete reason post-quantum TLS deployments fail in the field, and it interacts with the §8.1 anti-amplification limit: the server may not send more than three times what it has received, so a client that under-pads its Initials can stall the handshake without either side doing anything invalid.

Measured

2026-09-18

Reproduce it

The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.

SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive msquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["t-hybrid-large-hello"]'