Summary

  • RFC 10024 defines three final TLS 1.3 groups that concatenate an ECDHE secret with an ML-KEM secret. The TLS key schedule aims to remain secure when at least one component mechanism remains unbroken.
  • That property concerns cryptographic components under stated assumptions. RFC 10024 separately warns that if both algorithms use the same insecure random generator, state disclosed through one can affect the security of the other.
  • A defensible migration records the selected group and transcript, then audits entropy, process, library, module, termination, certification and authentication boundaries. Two algorithm names are not two independent operating systems.

A green control with a hidden common root

Imagine a quarterly cryptography review for a global service. The edge dashboard says every eligible TLS 1.3 connection negotiated X25519MLKEM768. A packet trace confirms group 4588 in the ServerHello. The implementation passed the ML-KEM encapsulation-key check, the ciphertext had the right length, X25519 did not produce an all-zero shared secret, and Finished authenticated the handshake transcript.

The review marks the control complete: two algorithms, therefore two lines of defence.

Then an engineer asks where the randomness came from.

Both the ML-KEM operation and the X25519 ephemeral scalar were supplied by one process-wide CSPRNG. That generator was seeded once from the same virtual-machine image path, inherited across a faulty fork boundary and monitored only through a startup health flag. The cryptographic algorithms are different. Their source of unpredictability is not.

This is a hypothetical failure, not a report about a product. It illustrates a limit the standard itself names. Hybrid design diversifies mathematical assumptions. Operational design must decide whether the components still meet at one weak root.

RFC 10024, published on the IETF Standards Track in August 2026, turns that distinction into an unusually concrete engineering question. It defines three Post-Quantum Traditional key-agreement groups for TLS 1.3. Each combines an ephemeral elliptic-curve exchange with ML-KEM. The intended session secret survives if at least one component key-exchange mechanism remains secure.

The phrase “at least one” is not permission to stop counting dependencies.

One group name contains an ordered construction

TLS does not negotiate two independent extensions and hope an application combines them. Under the framework in RFC 9954, every combination is one opaque NamedGroup. Its component public values or ciphertexts are placed in a fixed order, concatenated without new length fields, and processed as one key share. Its fixed-length component secrets are concatenated and inserted where TLS 1.3 would ordinarily use the (EC)DHE secret.

The three RFC 10024 groups therefore have exact shapes.

X25519MLKEM768 sends a 1,216-byte client share: the 1,184-byte ML-KEM-768 encapsulation key first, followed by 32 bytes of X25519. The server returns 1,088 bytes of ML-KEM ciphertext and a 32-byte X25519 share, for 1,120 bytes. Its shared secret is 32 bytes from ML-KEM followed by 32 from X25519.

SecP256r1MLKEM768 reverses that component order. The client sends 65 bytes of uncompressed P-256 point followed by the same 1,184-byte ML-KEM key. The server sends the 65-byte point and 1,088-byte ciphertext. The 64-byte shared secret is ECDHE first, ML-KEM second.

SecP384r1MLKEM1024 uses a 97-byte P-384 point and 1,568-byte ML-KEM-1024 value in both client and server shares. Its shared secret contains a 48-byte ECDHE coordinate followed by a 32-byte ML-KEM secret, for 80 bytes.

Those byte counts matter because concatenation is unambiguous only when every component length is fixed by the selected group. They also show why a label is not a bag of algorithms. Order, parameter set, checks and the TLS key schedule are part of the construction.

The transcript gives the combiner its protocol home

The hybrid secret does not protect a session in isolation. The current TLS 1.3 specification, RFC 9846, binds ClientHello, any HelloRetryRequest, the second ClientHello, ServerHello and later authentication messages into transcript hashes. The server's selected key share determines the secret used by the key schedule. CertificateVerify separately signs the handshake transcript.

RFC 10024 states that its security analysis relies crucially on that TLS 1.3 transcript. The same concatenation cannot be copied into an unrelated protocol and declared secure by resemblance.

That boundary is constructive. The common group identifier says which ordered combination the endpoints executed. The transcript binds negotiation to the session. Finished proves possession of the derived keys under TLS rules. None of those facts claims that the service's other protocol, custom tunnel or home-grown combiner inherited the proof.

RFC 9794 provides the vocabulary. A PQ/T hybrid is a multi-algorithm scheme with at least one post-quantum and one traditional component. It also warns, by definition, that “post-quantum” describes an intended property. An algorithm can still be compromised by a future classical or quantum attack. A precise name narrows the claim; it does not immortalise it.

The checks defend values, not the whole factory

RFC 10024 requires the server to validate the client's ML-KEM encapsulation key under FIPS 203 and abort with illegal_parameter if that check fails. The client checks that the ciphertext length matches the group. Both sides perform the elliptic-curve validity checks; X25519 includes the all-zero shared-secret check. A different ML-KEM decapsulation failure produces internal_error.

These refusals are security properties. A receiver must not turn malformed material into an apparently valid session.

But their authority is narrow. They do not attest the origin of the random input. They do not prove that a side-channel-resistant implementation ran. They do not say whether the same library, memory allocator, HSM firmware, signed build chain or emergency rollback controls both components. They do not prove that another TLS terminator in the same service negotiated the group.

FIPS 203 standardises ML-KEM and describes ML-KEM-512, ML-KEM-768 and ML-KEM-1024. It says ML-KEM is believed secure against adversaries with a quantum computer. The calibrated word is “believed”. A standardised mechanism still depends on correct implementation, randomness, parameter selection and continuing cryptanalysis.

NIST SP 800-227 supplies broader recommendations for secure KEM implementation and use, including hybrid constructions. Referencing that guidance is not equivalent to showing which controls a running binary applied.

The standard names the common-mode failure

During ML-KEM encapsulation, the server draws randomness m and encrypts it in a way that lets the client recover it during decapsulation. RFC 10024 observes that information carried by m about the generator's other outputs is therefore exposed to the client. ECDHE ephemeral scalars also depend on cryptographically secure randomness, although the scalar is not directly sent to the peer.

Then comes the operational sentence: if the same insecure RNG is used by both algorithms, disclosure of its state through one also affects the security of the other.

The qualifier matters. Sharing a correctly designed CSPRNG does not automatically break the hybrid group. Nor does the RFC require two physical entropy appliances. The duty is to understand the dependency: seed sources, reseeding, process forks, snapshots, rollback, health tests, memory exposure and which outputs an adversary can observe.

RFC 8937 explains why. Broken initial entropy can weaken every generator instance seeded from it. It proposes an optional wrapper that mixes material derived from a long-term private-key operation to strengthen randomness across sessions. A deployment can adopt that technique or another defensible design. A handshake group cannot testify that it did.

Randomness is the explicit example. Common mode extends to other layers without changing the RFC's cryptographic theorem. If one remotely exploitable library parses both components, one memory-corruption defect may expose both secrets. If one unsigned configuration update changes the group policy, one operator action may remove both. If one edge vendor terminates every session, the organisation has algorithm diversity inside provider concentration.

These are operational risks, not claims that the combiner is mathematically defective.

FIPS ordering assigns a burden

RFC 10024's component order also carries a compliance consequence. NIST guidance permits HKDF with two distinct secrets when the first comes from a FIPS-approved key-establishment scheme. In the P-256 and P-384 combinations, the ECDHE secret comes first; the RFC explains that the ECDHE implementation must be certified for the described FIPS use, while the ML-KEM implementation need not be certified under that ordering condition. In X25519MLKEM768, ML-KEM comes first, so the ML-KEM implementation must be certified.

This is not a strength ranking. First does not mean superior. Certification of the required first component does not certify the second component, the random generator, the combined binary, the negotiation policy or the entire service.

The record should therefore name the exact module and certificate boundary behind a compliance assertion. “Uses a FIPS-capable hybrid group” is too loose to explain which implementation carried the approved role.

A registry value is not a deployment receipt

The IANA TLS Supported Groups registry assigns 4587, 4588 and 4589 to the three final groups. Only X25519MLKEM768 has Recommended Y; the two secp combinations are N, which IANA explicitly says need not mean flawed. They may be intended for limited or specific uses.

The registry also marks the experimental Kyber draft groups 25497 and 25498 obsolete and discouraged. That creates a useful telemetry distinction. Seeing a final code point shows different wire semantics from seeing a pre-standard experiment.

Still, registration establishes a shared word. A configuration establishes local intent. A ClientHello shows what one client offered. The ServerHello and transcript show what one connection selected. Only a fleet measurement can say how often a service reached that state, and only a dependency audit can say how independently its two components operated.

The official RFC 10024 errata search displayed no record on 30 August 2026. That is a dated registry observation, not proof that every implementation or interpretation is correct.

Key agreement is one migration track

RFC 9954 deliberately excludes next-generation authentication. TLS 1.3 separates key agreement from Certificate and CertificateVerify. A connection can correctly negotiate X25519MLKEM768 and still authenticate its server with a traditional signature.

This is not a contradiction. Hybrid key agreement addresses the confidentiality risk that an adversary records traffic now and decrypts it after a future break. A signature does not let that adversary retroactively change an already completed authenticated session. Future impersonation and certificate migration are different timelines.

The accurate statement is therefore layered: this session used an RFC 10024 hybrid key agreement; this certificate chain used a separately recorded signature scheme; this endpoint applied a particular policy; this application granted a particular operation. Compressing those facts into “PQC complete” gives one symbol authority over four controls.

Heng Lu's Running-Code Primacy supplies the evidentiary rule: the published group and configured policy must yield to the executed transcript and observed outcome. The minimum-common-layer doctrine explains why the RFC should not choose every operator's failure-domain architecture. It defines the interoperable combination; deployments retain the decision surface and the consequences.

Reality-layer analysis separates the “hybrid” label from the two component operations it represents. Practical data control asks who can actually change the terminator, library, entropy source, telemetry and rollback path. Cryptographic diversity is real only when those control surfaces are visible.

The handshake can combine two secrets correctly. The organisation must still prove that one hidden failure cannot choose them both.