The run did not exercise this test: the endpoint refused the connection before a handshake existed (the cryptographic handshake failed: error 40: peer is incompatible: NoKxGroupsInCommon). On this tier that is what a client offering no key exchange group this port will negotiate looks like -- a fact about the client, not a gap in the run.
The suite could not establish what this client does here. That is a shortcoming of the run rather than anything about the client, and every one of these is on our list to remove.
What was measured
- Client
- aioquic — aioquic, 1.3.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 aioquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["t-hybrid-large-hello"]'