From f92bf3a7aa66e08ca7085a0751d6808c1058d1bd Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Mon, 27 Jul 2026 23:31:56 +0100 Subject: [PATCH 1/2] QS06: separate construction, negotiation and implementation risk Addresses #12. The entry treated hybrid misuse as one undifferentiated risk and opened with an uncited claim that hybrid is "widely misimplemented". Standardised named groups inherit a reviewed construction; the transition-window risk is dominated by negotiation fallback and downgrade, and by demonstrated implementation timing leaks. Also updates two stale anchors: draft-ietf-tls-hybrid-design was published as RFC 9954 (July 2026), and draft-kwiatkowski-tls-ecdhe-mlkem is now draft-ietf-tls-ecdhe-mlkem, which defines X25519MLKEM768. --- ...06_Insecure-Migration-and-Hybrid-Misuse.md | 59 ++++++++++++------- 1 file changed, 37 insertions(+), 22 deletions(-) diff --git a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md index bee7a08..781634b 100644 --- a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md +++ b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md @@ -2,44 +2,59 @@ **Description:** -Hybrid cryptography is the practical migration pattern, but it is widely misimplemented. A hybrid construction combines a classical algorithm and a PQC algorithm so that breaking the combination requires breaking both - for key encapsulation, deriving the session key from both an ECDH share and an ML-KEM share; for signatures, producing two signatures over the same artefact. Done correctly, hybrid provides defence in depth during transition. Done incorrectly, it weakens security, hides algorithm failures, becomes an attractive permanent state that delays full migration, or introduces new attack surface: silent fallback to classical when PQC negotiation fails, broken hybrid KEM constructions where key derivation does not require both inputs, weak parameter selection, non-constant-time PQ implementations vulnerable to timing side channels, and downgrade attacks during the transition window. +Hybrid cryptography is the practical migration pattern: a construction that combines a classical algorithm with a PQC algorithm so that breaking the combination requires breaking both. For key encapsulation, the session key is derived from both an ECDHE share and an ML-KEM share; for signatures, two signatures are produced over the same artefact. Done correctly, hybrid provides defence in depth across the transition. The risks in getting it wrong are real, but they concentrate in three distinct layers that are often conflated, and the mitigations differ for each. + +*Construction risk* applies to custom combiners, not to standardised ones. RFC 9954 fixes the hybrid key exchange construction for TLS 1.3, and the ECDHE-MLKEM groups - X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 - are implemented inside mainstream libraries, with OpenSSL 3.5 offering X25519MLKEM768 as a default keyshare. An organisation that selects a standard named group inherits a reviewed construction. An organisation that assembles its own combiner, deriving the session key by selecting one shared secret or XORing the two rather than running a KDF over both, discards the property that makes hybrid worth deploying: security is then no better than the weaker component. + +*Negotiation and deployment risk* is where the transition window actually bites, and it is largely a configuration and operations problem rather than a cryptographic one. Silent fallback to classical-only when PQC negotiation fails, active downgrade in which an attacker strips the PQC key share, preference lists that leave classical groups ahead of hybrid ones, and hybrid that is configured but never verified as negotiated all produce the same outcome: traffic an organisation believes is quantum-safe is not. A session downgraded today is a session harvested today, which places this failure directly upstream of QS01. Larger PQC handshakes add an operational dimension - where a ClientHello is fragmented or dropped by middleboxes, the common resolution is to disable hybrid to restore service. + +*Implementation risk* is demonstrated rather than hypothetical. KyberSlash recovered ML-KEM secret keys by exploiting secret-dependent division timings present in several implementations, including reference code. Clangover (CVE-2024-37880) showed a compiler optimising constant-time source into a secret-dependent branch, a leak invisible to source-level review because it exists only in the compiled binary. + +Hybrid is also an interim state rather than a destination. The EU roadmap prohibits standalone quantum-vulnerable public-key cryptography for high-risk use cases after 2030, and deployments still running pre-standard Kyber or Dilithium drafts are running algorithms that ML-KEM and ML-DSA superseded. **Common Examples of Vulnerability:** -1. Drop-in replacement that silently falls back to classical when PQC negotiation fails. -2. Broken hybrid KEM constructions where the key derivation does not require both the classical and PQC inputs (selection or XOR rather than a KDF over both). -3. Weak parameter selection - ML-KEM-512 where ML-KEM-768 is required. -4. Non-constant-time PQ implementations vulnerable to timing side channels. -5. Downgrade attacks where an attacker strips PQC options during transition to force classical-only negotiation. -6. Pre-2024 hybrid Kyber/Dilithium implementations still in use after ML-KEM and ML-DSA superseded them. +1. Deployments that silently fall back to classical-only key exchange when PQC negotiation fails, with no alerting to distinguish a hybrid handshake from a classical one. +2. Susceptibility to active downgrade, where an attacker strips the PQC key share from the handshake to force classical-only negotiation. +3. Hybrid enabled in configuration but never verified in production - group preference lists that place classical ahead of hybrid, or clients and middleboxes that quietly negotiate around it. +4. Larger PQC handshakes fragmented or dropped by middleboxes, load balancers, or firewalls, leading operators to disable hybrid to restore service. +5. Custom hybrid combiners that derive the session key by selection or XOR rather than a KDF over both the classical and PQC inputs. +6. PQC implementations vulnerable to timing side channels, including reference code affected by KyberSlash and binaries affected by compiler-introduced leaks such as Clangover (CVE-2024-37880). +7. Pre-standard Kyber or Dilithium draft implementations still in production after ML-KEM and ML-DSA superseded them, and weak parameter selection such as ML-KEM-512 where ML-KEM-768 is required. **How to Prevent:** -1. Use standard hybrid constructions from IETF drafts and vendor implementations rather than custom combinations. -2. Combine hybrid outputs through a KDF over both inputs, not by selection or XOR. -3. Test for downgrade resistance - ensure PQC failure does not silently fall back to classical-only, and monitor for handshakes that revert. -4. Track hybrid deployments as transitional and plan their replacement with pure PQC ahead of regulatory deadlines for high-risk use cases. -5. Verify hybrid implementations use ML-KEM and ML-DSA, not predecessor draft algorithms, and rely on validated constant-time libraries (SymCrypt, BoringSSL, AWS-LC) rather than reference code. -6. Pilot hybrid PQC TLS in non-production for each architecture pattern, measuring handshake size, latency, throughput, and middlebox behaviour - larger PQC handshakes may be dropped or fragmented by firewalls and load balancers. +1. Adopt standard named hybrid groups through a maintained library rather than assembling a combiner: the RFC 9954 construction with the ECDHE-MLKEM groups from `draft-ietf-tls-ecdhe-mlkem`. Where a custom combination is genuinely unavoidable, derive the key with a KDF over both inputs - never by selection or XOR. +2. Monitor the negotiated group in production and alert on classical-only handshakes. Hybrid that is configured but unobserved is indistinguishable from hybrid that is not working. +3. Test downgrade resistance explicitly: strip the PQC key share in a test harness and confirm the connection behaves as policy requires - failing closed where classical-only is not acceptable - rather than falling back silently. +4. Pilot for handshake size before rollout, measuring ClientHello fragmentation, middlebox behaviour, latency, and throughput for each architecture pattern, so capacity problems surface in test rather than as a production incident whose fastest fix is turning hybrid off. +5. Use validated constant-time implementations rather than reference code, prefer libraries hardened against compiler-introduced timing leaks, and track PQC implementation advisories as they are published. +6. Verify that deployments use ML-KEM and ML-DSA at the required parameter sets, not superseded pre-standard Kyber or Dilithium drafts. +7. Record which systems run hybrid and treat that record as a transitional inventory, planning pure-PQC replacement ahead of the regulatory deadlines that apply to high-risk use cases. **Example Attack Scenarios:** -Scenario #1: A deployment negotiates hybrid PQC TLS but falls back to classical-only if the PQC option is absent. An active attacker strips the PQC key-share from the handshake, forcing a downgrade to ECDH, then records the session for later CRQC decryption - the hybrid protection is nullified by the fallback. +Scenario #1: A deployment negotiates hybrid PQC TLS but falls back to classical-only when the PQC option is absent. An active attacker strips the PQC key share from the handshake, forcing negotiation down to ECDHE, and records the session for decryption once a CRQC exists. The hybrid protection is nullified by the fallback, and because nothing monitors the negotiated group, the downgrade leaves no operational trace. + +Scenario #2: A team builds a custom hybrid KEM that derives the session key from the ML-KEM share alone and attaches the ECDHE share for compatibility. Because breaking the combination requires breaking only the PQC component, an implementation flaw in the PQC library compromises the whole session - the classical share contributes nothing, and the construction provides none of the defence in depth it was adopted for. -Scenario #2: A team builds a custom hybrid KEM that derives the session key from the ML-KEM share alone and merely attaches the ECDH share for "compatibility." Because breaking the combination requires breaking only the PQC part, an implementation flaw in the PQC library compromises the whole session, defeating the point of hybrid. +Scenario #3: Following a hybrid TLS rollout, an organisation sees intermittent handshake failures where a legacy middlebox drops the larger ClientHello. Under incident pressure the fastest remedy is to remove the hybrid groups from the affected path. The change is never revisited, the estate is recorded as migrated, and an attacker harvests traffic from a segment that reverted to classical key exchange months earlier. **Reference Links:** - + -1. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. -2. [IETF - Hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/): Standard hybrid KEM construction. -3. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. -4. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 standalone-classical prohibition for high-risk cases (hybrid as interim). +1. [RFC 9954 - Hybrid Key Exchange in TLS 1.3](https://www.rfc-editor.org/info/rfc9954): The standardised hybrid construction for TLS 1.3 (Informational, July 2026). Supersedes `draft-ietf-tls-hybrid-design`. +2. [draft-ietf-tls-ecdhe-mlkem - Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/): Defines the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 groups. IESG-approved and awaiting RFC publication; replaces `draft-kwiatkowski-tls-ecdhe-mlkem`. +3. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. +4. [Bernstein et al. - KyberSlash: Exploiting secret-dependent division timings in Kyber implementations](https://eprint.iacr.org/2024/1049): Secret-key recovery from timing leaks in ML-KEM implementations, including reference code (IACR TCHES). +5. [CVE-2024-37880 (Clangover)](https://www.cve.org/CVERecord?id=CVE-2024-37880): Compiler optimisation of constant-time source into a secret-dependent branch in the Kyber reference implementation. +6. [OpenSSL 3.5 release notes](https://openssl-library.org/news/openssl-3.5-notes/): Default TLS groups changed to include and prefer hybrid PQC KEM groups, with X25519MLKEM768 offered as a default keyshare. +7. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. +8. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 standalone-classical prohibition for high-risk cases, with hybrid as an interim state. **Standards and Regulatory Mapping:** > **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. -NIST FIPS 203, FIPS 204. NCSC guidance treats hybrid as interim. EU Coordinated Implementation Roadmap end-2030 standalone-classical prohibition for high-risk cases. NIS2 Article 21(2)(h) state-of-the-art cryptography obligation, which supervisors increasingly read as requiring correctly-constructed hybrid during transition. DORA Article 9 confidentiality and integrity obligations apply to financial entities deploying hybrid TLS in production. IETF drafts on Hybrid PQ Key Exchange in TLS 1.3 and on Composite ML-DSA. IETF PQUIP working group migration documents. - +NIST FIPS 203, FIPS 204. RFC 9954 standardises the TLS 1.3 hybrid key exchange construction; `draft-ietf-tls-ecdhe-mlkem` defines the ECDHE-MLKEM groups and is awaiting RFC publication. NCSC guidance treats hybrid as interim. EU Coordinated Implementation Roadmap end-2030 standalone-classical prohibition for high-risk cases. NIS2 Article 21(2)(h) state-of-the-art cryptography obligation, which supervisors increasingly read as requiring correctly-constructed hybrid during transition. DORA Article 9 confidentiality and integrity obligations apply to financial entities deploying hybrid TLS in production. IETF PQUIP working group migration documents; IETF LAMPS work on Composite ML-DSA for hybrid signatures. From 6cc3485ec56e608f22331337e8499c924a2c48ac Mon Sep 17 00:00:00 2001 From: m-khan-97 Date: Tue, 4 Aug 2026 13:33:57 +0100 Subject: [PATCH 2/2] QS06: reframe downgrade as induced fallback, per review TLS 1.3 transcript authentication means in-handshake stripping aborts rather than completes, and RFC 9954 hybrids are single named groups with no half-share to strip. The practical downgrade is the client's own fallback logic retrying classical-only after an induced failure - a completed, internally valid handshake with no tampering on the wire. Description, Common Example #2, Scenario #1 and the fallback-testing prevention step reframed accordingly. RFC 8446 Section 4.1.3 added to references. --- ...06_Insecure-Migration-and-Hybrid-Misuse.md | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md index 781634b..58693c3 100644 --- a/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md +++ b/quantum-top-10/QS06_Insecure-Migration-and-Hybrid-Misuse.md @@ -6,7 +6,7 @@ Hybrid cryptography is the practical migration pattern: a construction that comb *Construction risk* applies to custom combiners, not to standardised ones. RFC 9954 fixes the hybrid key exchange construction for TLS 1.3, and the ECDHE-MLKEM groups - X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 - are implemented inside mainstream libraries, with OpenSSL 3.5 offering X25519MLKEM768 as a default keyshare. An organisation that selects a standard named group inherits a reviewed construction. An organisation that assembles its own combiner, deriving the session key by selecting one shared secret or XORing the two rather than running a KDF over both, discards the property that makes hybrid worth deploying: security is then no better than the weaker component. -*Negotiation and deployment risk* is where the transition window actually bites, and it is largely a configuration and operations problem rather than a cryptographic one. Silent fallback to classical-only when PQC negotiation fails, active downgrade in which an attacker strips the PQC key share, preference lists that leave classical groups ahead of hybrid ones, and hybrid that is configured but never verified as negotiated all produce the same outcome: traffic an organisation believes is quantum-safe is not. A session downgraded today is a session harvested today, which places this failure directly upstream of QS01. Larger PQC handshakes add an operational dimension - where a ClientHello is fragmented or dropped by middleboxes, the common resolution is to disable hybrid to restore service. +*Negotiation and deployment risk* is where the transition window actually bites, and it is largely a configuration and operations problem rather than a cryptographic one. TLS 1.3 itself resists in-handshake tampering: the Finished MAC authenticates the full transcript, so an on-path attacker who edits the offered groups causes the handshake to abort, not to complete classically (RFC 8446 Section 4.1.3 covers version downgrade; the transcript hash covers parameter tampering). The exposure is instead the endpoint's own behaviour. Client fallback logic that answers a failed hybrid handshake with a fresh classical-only attempt hands an active attacker a downgrade without any tampered handshake completing - the attacker only has to make the first attempt fail. Preference lists that leave classical groups ahead of hybrid ones, and hybrid that is configured but never verified as negotiated, produce the same outcome with no attacker at all: traffic an organisation believes is quantum-safe is not. A session downgraded today is a session harvested today, which places this failure directly upstream of QS01. Larger PQC handshakes add an operational dimension - where a ClientHello is fragmented or dropped by middleboxes, the common resolution is to disable hybrid to restore service. *Implementation risk* is demonstrated rather than hypothetical. KyberSlash recovered ML-KEM secret keys by exploiting secret-dependent division timings present in several implementations, including reference code. Clangover (CVE-2024-37880) showed a compiler optimising constant-time source into a secret-dependent branch, a leak invisible to source-level review because it exists only in the compiled binary. @@ -15,7 +15,7 @@ Hybrid is also an interim state rather than a destination. The EU roadmap prohib **Common Examples of Vulnerability:** 1. Deployments that silently fall back to classical-only key exchange when PQC negotiation fails, with no alerting to distinguish a hybrid handshake from a classical one. -2. Susceptibility to active downgrade, where an attacker strips the PQC key share from the handshake to force classical-only negotiation. +2. Client fallback logic that answers a failed hybrid handshake by retrying classical-only - a downgrade an active attacker can induce simply by making the first attempt fail, and which completes as an internally valid handshake with no failed negotiation left on the wire. 3. Hybrid enabled in configuration but never verified in production - group preference lists that place classical ahead of hybrid, or clients and middleboxes that quietly negotiate around it. 4. Larger PQC handshakes fragmented or dropped by middleboxes, load balancers, or firewalls, leading operators to disable hybrid to restore service. 5. Custom hybrid combiners that derive the session key by selection or XOR rather than a KDF over both the classical and PQC inputs. @@ -26,7 +26,7 @@ Hybrid is also an interim state rather than a destination. The EU roadmap prohib 1. Adopt standard named hybrid groups through a maintained library rather than assembling a combiner: the RFC 9954 construction with the ECDHE-MLKEM groups from `draft-ietf-tls-ecdhe-mlkem`. Where a custom combination is genuinely unavoidable, derive the key with a KDF over both inputs - never by selection or XOR. 2. Monitor the negotiated group in production and alert on classical-only handshakes. Hybrid that is configured but unobserved is indistinguishable from hybrid that is not working. -3. Test downgrade resistance explicitly: strip the PQC key share in a test harness and confirm the connection behaves as policy requires - failing closed where classical-only is not acceptable - rather than falling back silently. +3. Test fallback behaviour explicitly: induce hybrid handshake failure in a test harness and confirm the client behaves as policy requires - failing closed where classical-only is not acceptable - rather than silently retrying classical. 4. Pilot for handshake size before rollout, measuring ClientHello fragmentation, middlebox behaviour, latency, and throughput for each architecture pattern, so capacity problems surface in test rather than as a production incident whose fastest fix is turning hybrid off. 5. Use validated constant-time implementations rather than reference code, prefer libraries hardened against compiler-introduced timing leaks, and track PQC implementation advisories as they are published. 6. Verify that deployments use ML-KEM and ML-DSA at the required parameter sets, not superseded pre-standard Kyber or Dilithium drafts. @@ -34,7 +34,7 @@ Hybrid is also an interim state rather than a destination. The EU roadmap prohib **Example Attack Scenarios:** -Scenario #1: A deployment negotiates hybrid PQC TLS but falls back to classical-only when the PQC option is absent. An active attacker strips the PQC key share from the handshake, forcing negotiation down to ECDHE, and records the session for decryption once a CRQC exists. The hybrid protection is nullified by the fallback, and because nothing monitors the negotiated group, the downgrade leaves no operational trace. +Scenario #1: A client is configured to retry with a classical-only handshake when its hybrid handshake fails. An active attacker interferes with the initial hybrid attempt - tampering with the offered groups aborts the handshake under TLS 1.3 transcript authentication, which is all the attacker needs - and the client falls back, completing a fresh, internally valid classical handshake. The attacker records that session for decryption once a CRQC exists. Because the fallback is the client's own behaviour, no tampered handshake ever completes on the wire: there is only a clean classical session that nothing distinguishes from normal unless the negotiated group is monitored. Scenario #2: A team builds a custom hybrid KEM that derives the session key from the ML-KEM share alone and attaches the ECDHE share for compatibility. Because breaking the combination requires breaking only the PQC component, an implementation flaw in the PQC library compromises the whole session - the classical share contributes nothing, and the construction provides none of the defence in depth it was adopted for. @@ -46,12 +46,13 @@ Scenario #3: Following a hybrid TLS rollout, an organisation sees intermittent h 1. [RFC 9954 - Hybrid Key Exchange in TLS 1.3](https://www.rfc-editor.org/info/rfc9954): The standardised hybrid construction for TLS 1.3 (Informational, July 2026). Supersedes `draft-ietf-tls-hybrid-design`. 2. [draft-ietf-tls-ecdhe-mlkem - Post-quantum hybrid ECDHE-MLKEM key agreement for TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/): Defines the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 groups. IESG-approved and awaiting RFC publication; replaces `draft-kwiatkowski-tls-ecdhe-mlkem`. -3. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. -4. [Bernstein et al. - KyberSlash: Exploiting secret-dependent division timings in Kyber implementations](https://eprint.iacr.org/2024/1049): Secret-key recovery from timing leaks in ML-KEM implementations, including reference code (IACR TCHES). -5. [CVE-2024-37880 (Clangover)](https://www.cve.org/CVERecord?id=CVE-2024-37880): Compiler optimisation of constant-time source into a secret-dependent branch in the Kyber reference implementation. -6. [OpenSSL 3.5 release notes](https://openssl-library.org/news/openssl-3.5-notes/): Default TLS groups changed to include and prefer hybrid PQC KEM groups, with X25519MLKEM768 offered as a default keyshare. -7. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. -8. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 standalone-classical prohibition for high-risk cases, with hybrid as an interim state. +3. [RFC 8446 - TLS 1.3, Section 4.1.3](https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3): Downgrade protection and transcript authentication, which confine the practical downgrade path to endpoint fallback behaviour rather than in-handshake tampering. +4. [NIST FIPS 203 (ML-KEM)](https://csrc.nist.gov/pubs/fips/203/final) and [FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final): Standardised PQC primitives for hybrid use. +5. [Bernstein et al. - KyberSlash: Exploiting secret-dependent division timings in Kyber implementations](https://eprint.iacr.org/2024/1049): Secret-key recovery from timing leaks in ML-KEM implementations, including reference code (IACR TCHES). +6. [CVE-2024-37880 (Clangover)](https://www.cve.org/CVERecord?id=CVE-2024-37880): Compiler optimisation of constant-time source into a secret-dependent branch in the Kyber reference implementation. +7. [OpenSSL 3.5 release notes](https://openssl-library.org/news/openssl-3.5-notes/): Default TLS groups changed to include and prefer hybrid PQC KEM groups, with X25519MLKEM768 offered as a default keyshare. +8. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Hybrid construction, downgrade resistance, and migration patterns. +9. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): End-2030 standalone-classical prohibition for high-risk cases, with hybrid as an interim state. **Standards and Regulatory Mapping:**