57Pass
0Fail
2Unsupported
100%of 57 conclusive
Stack: quico + lemon-tls ·
Language: JavaScript ·
Version: 0.7.0 (npm)
· Measured 2026-10-15
Badge for a README:
https://pqcrypta.com/conformance/badge/quico.svg
By class
Rolled up by what the clause requires rather than into one number. A client that ignores unknown extensions correctly but never emits the right error codes has a specific, nameable problem, and an average is exactly what hides it.
| Class | Passing means | Pass | Fail | Inconclusive |
|---|---|---|---|---|
| correctness | Rejected something invalid, with the code the RFC names. | 23 | 0 | 0 |
| discretionary | The RFC permits either behaviour; the report says which was chosen. | 13 | 0 | 0 |
| extensibility | Ignored something unknown and carried on. | 5 | 0 | 0 |
| interoperability | Correctly decoded something valid but demanding. | 8 | 0 | 0 |
| resilience | Recovered rather than giving up. | 8 | 0 | 0 |
Every result
| Test | Clause | Verdict | What happened |
|---|---|---|---|
| Version Negotiation offering a reserved version alongside v1 | RFC 9000 §6 | Pass | Responded correctly: sent Version Negotiation for 2 datagram(s); the client did not persist with an unsupported version. |
| Retry packet for source-address validation | RFC 9000 §8.1.2 | Pass | Responded correctly: echoed the Retry token and completed the handshake. |
| Reserved transport parameter (31·N+27) | RFC 9000 §18.1 | Pass | Ignored the unrecognised element and carried on: completed a handshake carrying a reserved transport parameter. |
| Unknown frame type in a 1-RTT packet | RFC 9000 §12.4 | Pass | Responded correctly: closed with FRAME_ENCODING_ERROR, which is the code §12.4 requires for a frame of unknown type. |
| NEW_CONNECTION_ID followed by RETIRE_CONNECTION_ID | RFC 9000 §5.1 | Pass | Recovered: rotated connection IDs and retired 6 of them. |
| Stateless reset | RFC 9000 §10.3 | Pass | Responded correctly: was sent a Stateless Reset and went quiet — nothing further arrived in the 3 seconds that followed, which is the draining period §10.3.1 requires (0 datagram(s) were already in flight when the reset went out and are not counted against it). |
| Deliberately tight MAX_DATA and MAX_STREAM_DATA | RFC 9000 §4 | Pass | Handled it: respected the window without sending a BLOCKED frame, which §4.1 permits. |
| ACK Frequency extension offered | draft-ietf-quic-ack-frequency | Pass | Handled it: ignored the extension, which the specification permits. |
| Packets marked ECT(0) | RFC 9000 §13.4 | Unsupported | does not report ECN counts. Another peer has echoed the markings this same port sent, so the codepoint demonstrably survives the path from here -- this client simply reported nothing, which §13.4.1 permits where the ECN field is not accessible to it. |
| Path MTU black hole above a threshold | RFC 9000 §14, RFC 8899 | Pass | Recovered: detected the black hole 1 time(s) and settled on a 1293-byte path MTU (0 datagram(s) swallowed). |
| Server-initiated PATH_CHALLENGE | RFC 9000 §8.2 | Pass | Responded correctly: answered with 1 PATH_RESPONSE. |
| 0-RTT rejected after the client sends early data | RFC 9001 §4.6.2 | Pass | Recovered and completed the follow-up request. |
| A second path offered mid-connection | draft-ietf-quic-multipath | Pass | Handled it: declined the multipath offer and stayed on one path, which is conformant. |
| Spontaneous 1-RTT key update | RFC 9001 §6.2 | Pass | Decoded it and completed the request. |
| Stream limits set to the minimum a request needs | RFC 9000 §4.6 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| One datagram in twelve dropped once the path is established | RFC 9000 §2.2, §13.3 | Pass | Recovered and completed the follow-up request. |
| Datagrams arriving from a second server address | RFC 9000 §9.6 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| Transport parameter carrying a value the specification forbids | RFC 9000 §7.4, §18.2 | Pass | Responded correctly: closed with TRANSPORT_PARAMETER_ERROR, which is the code §7.4 requires for a parameter carrying an invalid value (ack_delay_exponent = 21, where §18.2 permits at most 20). |
| 425 (Too Early) in answer to a request sent as early data | RFC 8470 §5.2 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| Path marking packets CE, not just ECT(0) | RFC 9000 §13.4 | Unsupported | does not report ECN counts, so the congestion signal had nowhere to be seen. 1 datagram(s) were marked CE and the codepoint demonstrably survives this path, so nothing here was lost in transit -- §13.4.1 requires reporting only where the ECN field is accessible to the endpoint, and for this client it is not. |
| A second key update after the first is acknowledged | RFC 9001 §6.1, §6.5 | Pass | Decoded it and completed the request. |
| No stream credit at first, then MAX_STREAMS mid-connection | RFC 9000 §4.6 | Pass | Rejected it (closed at the QUIC layer: received a frame for a stream identifier that exceeded advertised the stream limit for the corresponding stream type). The specification permits this but does not require it; a client that ignored it would also be conformant. |
| Reserved SETTINGS identifier (0x1f·N+0x21) | RFC 9114 §7.2.4.1 | Pass | Ignored the unrecognised element and completed the follow-up request. The client process had already exited 4359ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| Reserved frame type on the response stream | RFC 9114 §7.2.8 | Pass | Ignored the unrecognised element and completed the follow-up request. |
| Unidirectional stream with a reserved stream type | RFC 9114 §6.2.3 | Pass | Ignored the unrecognised element and completed the follow-up request. The client process had already exited 4409ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| SETTINGS containing the same identifier twice | RFC 9114 §7.2.4 | Pass | Rejected with error 0x109. The specification permits this but does not require it; a client that ignored it would also be conformant. |
| A DATA frame on the control stream | RFC 9114 §7.2.1 | Pass | Rejected with the required error code 0x105. |
| Control stream whose first frame is not SETTINGS | RFC 9114 §6.2.1 | Pass | Rejected with the required error code 0x10a. |
| A second control stream opened by the server | RFC 9114 §6.2.1 | Pass | Rejected with the required error code 0x103. |
| Field lines referencing dynamic table insertions | RFC 9204 §4.3.3, §4.5.2 | Pass | Decoded it and completed the request. |
| Huffman-coded field lines with maximal padding | RFC 9204 §4.1.2, RFC 7541 §5.2 | Pass | Decoded it and completed the request. |
| Field section larger than the client's advertised maximum | RFC 9114 §4.2.2 | Pass | Decoded it and completed the request. |
| Trailing field section after the body | RFC 9114 §4.1 | Pass | Decoded it and completed the request. |
| 103 Early Hints before the final response | RFC 9110 §15.2, RFC 8297 | Pass | Recovered and completed the follow-up request. |
| GOAWAY sent mid-connection | RFC 9114 §5.2 | Pass | Recovered and completed the follow-up request. The client process had already exited 4410ms in, before this test's reaction point at never observed, so the silence after that is not evidence either way. |
| MAX_PUSH_ID sent by the server | RFC 9114 §7.2.7 | Pass | Rejected with the required error code 0x105. |
| SETTINGS frame on a request stream | RFC 9114 §7.2.4 | Pass | Rejected with the required error code 0x105. |
| DATA frame before any HEADERS on the response stream | RFC 9114 §4.1 | Pass | Rejected with the required error code 0x105. |
| CANCEL_PUSH for a push ID that was never promised | RFC 9114 §7.2.3 | Pass | Rejected with the required error code 0x108. |
| Field section that blocks until the encoder stream catches up | RFC 9204 §2.1.2, §2.2.1 | Pass | Decoded it and completed the request. |
| Response stream reset mid-body with H3_REQUEST_CANCELLED | RFC 9114 §8, §4.1 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| PRIORITY_UPDATE sent by the server | RFC 9218 §7.2 | Pass | Rejected with error 0x105. The specification permits this but does not require it; a client that ignored it would also be conformant. |
| SETTINGS_ENABLE_CONNECT_PROTOCOL with a value outside 0 and 1 | RFC 9220 §3, RFC 8441 §3 | Pass | Rejected with error 0x109. The specification permits this but does not require it; a client that ignored it would also be conformant. |
| PUSH_PROMISE for a push the client never allowed | RFC 9114 §7.2.5, §4.6 | Pass | Rejected with the required error code 0x108. |
| SETTINGS_H3_DATAGRAM with a value that is neither 0 nor 1 | RFC 9297 §2.1.1 | Pass | Rejected with the required error code 0x109. |
| Encoder stream setting a dynamic table capacity above the client's limit | RFC 9204 §4.3.1, §6 | Pass | Rejected with the required error code 0x201. |
| A second GOAWAY naming a larger identifier than the first | RFC 9114 §5.2 | Pass | Rejected with the required error code 0x108. |
| Push stream opened for a push nobody allowed | RFC 9114 §6.2.2 | Pass | Rejected with the required error code 0x108. |
| Field line indexing a static table entry that does not exist | RFC 9204 §3.1, §4.5.2 | Pass | Rejected with the required error code 0x200. |
| Datagrams delivered out of order | RFC 9000 §2.2 | Pass | Recovered and completed the follow-up request. |
| Encoder instruction naming a static index that does not exist | RFC 9204 §3.1, §4.3.2 | Pass | Rejected with the required error code 0x201. |
| Server negotiates only the post-quantum hybrid X25519MLKEM768 | RFC 8446 §4.1.4, draft-ietf-tls-hybrid-design | Pass | Decoded it and completed the request. |
| Server negotiates only classical X25519 against a hybrid offer | RFC 8446 §4.1.1, draft-ietf-tls-hybrid-design §5 | Pass | Tolerated it and continued. The specification permits this but does not require it; a client that rejected it would also be conformant. |
| Hybrid key share large enough to split the Initial across packets | RFC 9000 §8.1, §14.1, RFC 9001 §4.4 | Pass | Recovered and completed the follow-up request. |
| Server selects a key exchange group the client never offered | RFC 8446 §4.1.3, §4.2.8, RFC 9001 §4.8 | Pass | Responded correctly: aborted with illegal_parameter (alert 47) over a key_share naming a group it never offered, which is exactly what RFC 8446 §4.1.3 requires. |
| Hybrid key share with an intact X25519 half and a corrupt ML-KEM half | draft-ietf-tls-hybrid-design §3.2, RFC 8446 §4.1.3 | Pass | Responded correctly: did not complete the handshake (timed out). The shared secret is both halves through the key schedule, so a corrupt ML-KEM half must break it -- and this client did not fall back to the intact X25519 half. |
| Hybrid key share whose length does not match the group named with it | draft-kwiatkowski-tls-ecdhe-mlkem §3.1.2, RFC 8446 §6.2, RFC 9001 §4.8 | Pass | Responded correctly: aborted with illegal_parameter (alert 47) over a server share of the wrong length for X25519MLKEM768, which is the check §3.1.2 asks the client to make and the code it names. |
| Post-quantum certificate chain, compressed per RFC 8879 | RFC 8879 §4, RFC 8446 §4.4.2 | Pass | Handled it: decompressed and parsed the 2-certificate, 15,430-byte ML-DSA-87 chain, then rejected it on trust (alert 42). That is the right answer to a private CA, and reaching it means the certificate message itself was handled. |
| GREASE named group a client must tolerate | RFC 8701 §4, RFC 8446 §4.2.7 | Pass | Ignored the unrecognised element and completed the follow-up request. |