RFC 10024 Explained: Hybrid ML-KEM for TLS 1.3

RFC 10024 gives hybrid post-quantum key agreement in TLS 1.3 a final Standards Track specification. Published by the IETF in August 2026, it defines three named groups that combine ML-KEM with an ephemeral elliptic-curve Diffie-Hellman exchange. It also assigns final IANA code points and formally obsoletes two experimental Kyber groups.

This matters because production deployments no longer need to refer to an Internet-Draft or an experimental group identifier when implementing the dominant hybrid TLS construction. It does not mean every TLS library, server, proxy, client, or inspection appliance supports all three groups. It also does not add post-quantum certificate authentication to TLS.

For the broader reason to combine classical and post-quantum algorithms, read Hybrid Cryptography Explained. This page focuses narrowly on what RFC 10024 standardizes and what implementers should change.

What RFC 10024 changes

RFC 10024 applies the hybrid key-exchange framework in RFC 9954 to ML-KEM, the NIST key encapsulation mechanism standardized in FIPS 203. It defines the exact client and server shares, validation behavior, shared-secret construction, names, and code points for three TLS Supported Groups.

Before publication, major browsers, CDNs, TLS libraries, and cloud services already deployed X25519MLKEM768. That operational experience was important, but implementers still had to distinguish final ML-KEM deployments from earlier experimental Kyber variants and changing draft specifications. RFC 10024 removes that standards ambiguity for these three groups.

The RFC does not:

change TLS 1.3 into a post-quantum authentication protocol;
define ML-DSA certificates or certificate signatures;
require every implementation to enable all three groups;
make obsolete clients compatible;
declare every connection using TLS 1.3 post-quantum protected;
make the same concatenation construction safe to copy into another protocol.

The RFC explicitly states that its security analysis depends on the TLS 1.3 transcript. Implementers should not reuse the construction outside TLS without a protocol-specific analysis and standard.

The three standardized groups

TLS group	Traditional component	PQ component	IANA value	Recommended in IANA registry	Intended role
`X25519MLKEM768`	X25519	ML-KEM-768	4588, `0x11EC`	Yes	Widely deployed general-purpose hybrid
`SecP256r1MLKEM768`	secp256r1, NIST P-256	ML-KEM-768	4587, `0x11EB`	No	Environments that need NIST-curve mechanisms
`SecP384r1MLKEM1024`	secp384r1, NIST P-384	ML-KEM-1024	4589, `0x11ED`	No	Higher-security environments needing P-384 and ML-KEM-1024

All three entries are standardized by the same Standards Track RFC. The IANA Recommended column is a separate implementation-guidance signal. N for the P-256 and P-384 groups does not mean experimental, deprecated, or forbidden. It means IANA does not mark them as recommended for general implementation in the registry.

Why X25519MLKEM768 is recommended

RFC 10024 describes X25519 as widely deployed and often the most practical choice when an implementation offers one post-quantum/traditional hybrid combiner. It pairs X25519 with ML-KEM-768 and has already been deployed across major browser and edge ecosystems.

The client share is 1,216 bytes: a 1,184-byte ML-KEM-768 encapsulation key followed by a 32-byte X25519 share. The server share is 1,120 bytes: a 1,088-byte ML-KEM ciphertext followed by a 32-byte X25519 share. The resulting combined shared secret is 64 bytes before it enters the TLS key schedule.

The historical ordering matters. Despite the group name beginning with X25519, the ML-KEM share is encoded first. Implementers must follow the RFC byte layout rather than infer serialization order from the name.

The IANA Recommended status does not make every deployment compliant with a particular regulatory regime. RFC 10024 notes that FIPS use also depends on approved key derivation and certified implementations. For X25519MLKEM768, its documented FIPS path places a requirement on the ML-KEM implementation. Teams with specific validation requirements need to verify the exact cryptographic module, build, configuration, and certificate.

The P-256 and P-384 alternatives

SecP256r1MLKEM768 combines NIST P-256 ECDHE with ML-KEM-768. Its client share is 1,249 bytes and its server share is 1,153 bytes. The P-256 component is encoded first. The group is relevant where both inputs to the combiner need to be generated using FIPS-approved mechanisms and an existing certified P-256 implementation is available.

SecP384r1MLKEM1024 combines P-384 ECDHE with ML-KEM-1024. Both client and server shares are 1,665 bytes, and the shared secret is 80 bytes. RFC 10024 positions it for higher-security environments that require FIPS-approved mechanisms with a larger security margin.

Do not silently substitute older implementation names such as P256MLKEM768 for the RFC name. A library may retain an implementation-specific or transitional alias, but the standardized TLS Supported Group is SecP256r1MLKEM768. Configuration and interoperability testing must use the name and code point supported by the exact library release.

Obsolete Kyber draft groups

RFC 10024 formally obsoletes:

Obsolete group	Experimental value	Current status
`X25519Kyber768Draft00`	25497, `0x6399`	Pre-standard Kyber768, obsoleted by RFC 10024
`SecP256r1Kyber768Draft00`	25498, `0x639A`	Pre-standard Kyber768, obsoleted by RFC 10024

IANA changed their Recommended field to D and records RFC 10024 as the reason. These groups used a pre-standard Kyber version, not the final FIPS 203 ML-KEM definition.

Historical reporting can still mention them when explaining browser or server deployments from 2023 and 2024. New configuration examples, compatibility tables, procurement requirements, and monitoring rules should use the final RFC 10024 groups instead.

Do not assume that replacing the string in a configuration file is sufficient. The final ML-KEM algorithm, share encoding, group code point, and supported library version all matter. An old client that implements only 0x6399 will not automatically negotiate 0x11EC.

What implementers should change

TLS libraries

Confirm that the library release implements RFC 10024, not only an earlier draft. Check the public API name, wire code point, default group order, server preference behavior, and whether the implementation validates ML-KEM encapsulation keys and ciphertext lengths as required.

The PQC library comparison matrix provides an ecosystem overview. Use the library’s official release notes for the final decision.

Server and proxy configuration

Offer X25519MLKEM768 alongside classical fallback groups while incompatible clients remain in scope. A typical group list may prefer the hybrid and retain X25519 and secp256r1. The exact syntax depends on the TLS library and server.

Do not enable a hybrid group only at the public CDN and then report the entire application path as protected. Inspect edge-to-origin, service-mesh, API gateway, load balancer, database, messaging, and administrative paths separately.

The OpenSSL quantum-safe configuration guide covers server configuration and verification.

Clients and browsers

Inventory client versions, embedded TLS stacks, mobile platforms, inspection appliances, and enterprise policies. A server supporting X25519MLKEM768 does not prove a particular client offers it. Record the negotiated group from a real handshake.

Use Is My TLS Quantum-Safe? for a practical test, but interpret the result narrowly: it verifies key agreement for that connection, not post-quantum signatures or end-to-end application coverage.

Monitoring and policy

Update scanners and telemetry to recognize the three final code points and flag obsolete Kyber draft values. Preserve the raw numeric identifier where possible. A label generated by an outdated packet analyzer may be wrong even when the wire value is correct.

Policy should distinguish:

RFC 10024 group supported;
RFC 10024 group offered;
group selected in a real connection;
coverage across defined endpoints;
classical fallback observed;
obsolete draft code point observed.

Interoperability considerations

The larger key shares can expose middleboxes, packet-size assumptions, memory limits, ClientHello fragmentation issues, and handshake timeouts. Run tests across representative networks and devices rather than testing only a local client and server.

At minimum, measure:

successful negotiation with each supported RFC 10024 group;
fallback behavior with classical-only clients;
behavior when a client offers an obsolete draft group;
malformed encapsulation-key and ciphertext handling;
latency, CPU, memory, and handshake byte counts;
session resumption and connection reuse;
observability of the negotiated group;
edge-to-origin and internal-hop coverage;
rollback without disabling unrelated TLS security controls.

The PQC implementation test guide provides a broader test-lab framework. Store results in the PQC migration plan template with exact versions, evidence, owner, and rollback.

Migration checklist

Replace new references to Kyber draft groups with RFC 10024 names and code points.
Keep historical draft references only when clearly dated and labeled obsolete.
Upgrade libraries and appliances to releases that document RFC 10024.
Prefer X25519MLKEM768 when one broadly deployed hybrid group is needed, subject to local requirements.
Evaluate P-256 or P-384 groups only for a defined policy, interoperability, or assurance requirement.
Verify negotiated groups on actual traffic.
Test classical fallback for supported legacy clients.
Monitor obsolete code points and unexpected downgrade.
Document every unprotected hop.
Keep certificate and signature migration as separate workstreams.

The post-quantum migration checklist places this TLS work within the wider enterprise program.

Standards status

RFC 10024 is an IETF Standards Track RFC published in August 2026. RFC 9954 defines the general framework for hybrid key exchange in TLS 1.3. RFC 10024 instantiates that framework for three ML-KEM plus ECDHE groups. FIPS 203 defines ML-KEM itself.

These layers should not be collapsed. A final algorithm standard, a final protocol RFC, a library implementation, and a managed-service deployment are four different maturity facts.

Practical verdict

New TLS 1.3 hybrid deployments should treat RFC 10024 as the wire-level source of truth. X25519MLKEM768 is the recommended and widely deployed default candidate. SecP256r1MLKEM768 and SecP384r1MLKEM1024 are standardized alternatives for specific requirements, not general co-defaults.

Remove obsolete draft groups from active configurations, update monitoring, and validate real negotiations. Then continue the rest of the PQC program, because hybrid TLS key agreement alone does not migrate certificates, signatures, code signing, KMS operations, or stored data.

FAQ

Is RFC 10024 a final standard or an Internet-Draft?

It is an IETF Standards Track RFC published in August 2026. The three groups and their IANA code points are no longer defined only by an Internet-Draft.

Does “Recommended: N” mean the P-256 and P-384 groups are deprecated?

No. Both are standardized by RFC 10024. The IANA registry does not mark them as recommended for general implementation, but they exist for defined requirements and are not obsolete.

Should servers disable classical fallback now?

Usually not without a controlled client-support decision. Classical-only clients still exist. Prefer the hybrid when both sides support it, monitor fallback, and define when legacy compatibility can be removed.

Does X25519MLKEM768 make the certificate post-quantum secure?

No. It protects TLS key agreement. Traditional RSA or ECDSA certificate signatures remain a separate authentication and migration concern.

Can old Kyber draft clients negotiate the final group automatically?

No. The obsolete draft and final RFC groups use different identifiers and underlying algorithm versions. Clients and servers need compatible final implementations.