lsquic — Server negotiates only the post-quantum hybrid X25519MLKEM768

Pass

Decoded it and completed the request.

The client did what the clause requires.

What was measured

Client

lsquic — LiteSpeed lsquic + BoringSSL, 4.9.4

Test

Server negotiates only the post-quantum hybrid X25519MLKEM768 — t-hybrid-only

Clause

RFC 8446 §4.1.4, draft-ietf-tls-hybrid-design (MUST)

Class

interoperability — Correctly decoded something valid but demanding.

Required behaviour

Complete the handshake. A client whose first key share was classical must recover through HelloRetryRequest, which §4.1.4 requires it to answer with a second ClientHello carrying a share for the named group. A client that does not offer the group at all must abandon the attempt cleanly rather than stall — that is a correct outcome for a client without post-quantum support. A client that cannot negotiate the group at all never establishes a connection, so the server records no verdict and the result is `not run` rather than a pass or a failure. On this tier that reads as "no post-quantum key exchange", which is itself the finding: every other tier reaches `not run` only when the runner skipped something. curl/ngtcp2 1.11.0 lands here. This is the round trip that breaks first in a real migration, because it is the one that never happens until a server somewhere stops offering the classical group.

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 lsquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["t-hybrid-only"]'