neqo — Transport parameter carrying a value the specification forbids

Fail

rejected the out-of-range parameter with Code::crypto(2f), where RFC 9000 §7.4 requires TRANSPORT_PARAMETER_ERROR. The violation was detected; the code reported is wrong.

The client did something the clause forbids, or failed to do what it requires.

What was measured

Client

neqo — neqo (Firefox), 0.31.1

Test

Transport parameter carrying a value the specification forbids — q-invalid-transport-param

Clause

RFC 9000 §7.4, §18.2 (MUST)

Class

correctness — Rejected something invalid, with the code the RFC names.

Required behaviour

Close the connection with TRANSPORT_PARAMETER_ERROR. §18.2 makes an ack_delay_exponent above 20 invalid, and §7.4 is a MUST: "An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR." Distinct from a *duplicate* parameter, which the same clause makes only a SHOULD — this port sends one parameter, once, with a value outside its permitted range. The parameter travels in the handshake, so every client that connects here reads it. Only a client that answers with a CONNECTION_CLOSE this endpoint can read is scored: one that simply abandons the handshake is recorded as inconclusive, because a close that was sent and lost looks exactly like one that was never sent.

Measured

2026-09-17

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 neqo at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-invalid-transport-param"]'