The client offers no key exchange group this port will negotiate, so it was refused before a handshake existed (the cryptographic handshake failed: error 40: peer is incompatible: NoKxGroupsInCommon). That is a capability this client does not have, rather than something the run failed to measure.
The client does not do this, and said so itself — by what it advertised, or by refusing outright. A definite answer about the client, not a failure and not a gap.
What was measured
- Client
- xquic — Alibaba xquic + BoringSSL, 2060a44
- 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-10-27
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 xquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["t-hybrid-large-hello"]'