QS06 phrasing

[rot169]

QS06 claims in the first sentence, without citation:

but it is widely misimplemented

This does not align with what I observe. Crypto libraries such as openssl implement hybrid (composite) schemes as their own cipher; e.g., x25519mlkem768. It requires more effort to break rule zero of crypto ("never write your own crypto") and try to create a custom hybrid scheme.

There's a lot in this entry that I don't think adds much value. I think it should really double-down on what's currently common example no.5 - downgrade attacks back to classical crypto.

The entry seems to conflate hybrid (composite) schemes such as x25519mlkem768 with dual-running support for classical vs quantum-resistant schemes. I suggest a re-write focusing on the latter.

[m-khan-97]

Agreed on the diagnosis, and I have opened #17 as a proposed rewrite along these lines.

Your point about rule zero is the one I built it around: the standardised path (RFC 9954 construction, X25519MLKEM768 from draft-ietf-tls-ecdhe-mlkem, offered by default in OpenSSL 3.5) is not where risk concentrates, so the entry should stop implying it is. The rewrite separates three layers with different mitigations - construction risk, which applies only to hand-rolled combiners; negotiation and deployment risk, which gets the most weight per your suggestion, covering silent fallback, active downgrade, preference ordering and the middlebox failures that end with hybrid being switched off under incident pressure; and implementation risk, which is demonstrated rather than speculative (KyberSlash, and Clangover as CVE-2024-37880). The uncited "widely misimplemented" claim is gone.

Two things worth noting for the thread: the entry cited draft-ietf-tls-hybrid-design, which was published as RFC 9954 in July 2026, and it did not cite the ECDHE-MLKEM draft at all - so the group your argument rests on was missing from the references. QS05 cites the same superseded draft and needs the same fix, which I have left out of #17 to keep it to one entry.

Happy to adjust the balance if you think the negotiation layer should absorb even more of the entry.

[ossumpossum]

PR #17 (@m-khan-97) already addresses the conflation raised here, separating construction,
negotiation/deployment, and implementation, weighting the negotiation-downgrade layer highest, and linking it
upstream to QS01.

One refinement, which I've noted in detail on that PR: its Scenario #1 attributes the downgrade to an active
attacker "stripping the PQC key share" so the session silently completes classical with no operational trace. In
TLS 1.3 the Finished MAC authenticates the handshake transcript, so in-handshake stripping is detected and the
handshake aborts. The genuinely exploitable paths are the induced fall-back retry and permissive
preference/middlebox-disable, which the PR already lists elsewhere. Reframing Scenario #1 around those keeps the
entry from re-introducing, in subtler form, the conflation this issue set out to remove.

Context: I work on post-quantum migration guidance for a large pharma security research org, where downgrade
resistance is a concrete acceptance criterion we write into standards and vendor requirements.