The terms on this page
- ML-KEMModule-Lattice-based Key Encapsulation Mechanism
- the standardised post-quantum replacement for RSA and ECDH key exchange, published as FIPS 203
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab) are defined in the glossary.
Read this first
On 7 October 2026, two Ericsson authors published an individual Internet-Draft proposing MLKEM1024X448 for TLS 1.3, DTLS 1.3 and QUIC. It combines ML-KEM-1024 with X448, producing a 1,624-byte key share in each direction and an 88-byte input to the TLS key schedule. The proposal targets a higher security level than X25519MLKEM768. It is not adopted by an IETF working group, has no assigned codepoint and is not an interoperable deployment target.
The new MLKEM1024X448 draft applies the hybrid construction from RFC 9954 to a larger post-quantum and classical pair. The client sends a 1,568-byte ML-KEM-1024 encapsulation key followed by a 56-byte X448 public key. The server sends a 1,568-byte ML-KEM ciphertext followed by its 56-byte X448 public key. Both key shares therefore total 1,624 bytes.
The draft is a proposal for a new TLS NamedGroup, not a change to RFC 10024. RFC 10024 already standardizes X25519MLKEM768 and two NIST-curve combinations. The proposed group would add another point in the design space for deployments that want ML-KEM-1024 and a classical component above the roughly 128-bit level of X25519.
The proposal increases both security margin and wire cost
| Property | X25519MLKEM768 | Proposed MLKEM1024X448 |
|---|---|---|
| Post-quantum component | ML-KEM-768 | ML-KEM-1024 |
| Classical component | X25519 | X448 |
| Client key share | 1,216 bytes | 1,624 bytes |
| Server key share | 1,120 bytes | 1,624 bytes |
| Combined secret input | 64 bytes | 88 bytes |
| Status | RFC 10024, Proposed Standard | Individual Internet-Draft, no assigned codepoint |
The 88-byte input is the 32-byte ML-KEM shared secret followed by the 56-byte X448 shared secret. As with the standardized groups, TLS feeds the concatenation into its existing key schedule rather than adding a new handshake message. The draft requires both peers to reject a key share whose length is not exactly 1,624 bytes.
The authors describe ML-KEM-1024 as NIST security category 5 and position the combination alongside AES-256 and ChaCha20. The important qualification is that a parameter label is not an end-to-end assurance level. Protocol code, key validation, downgrade behavior, implementation leakage and certificate authentication remain separate review boundaries.
More margin does not make a draft deployable
Datatracker classifies this as an individual Internet-Draft with no formal standing in the IETF standards process. Version 00 may change or expire. There is no assigned NamedGroup value, demonstrated interoperability or broad library support. Track and test the proposal, but do not put a private codepoint into production and call it a standard.
The extra bytes make network-path testing mandatory
A 1,624-byte client key share is 408 bytes larger than the complete X25519MLKEM768 client share. The full ClientHello is larger still once extensions, server names and other offered groups are included. That increases the chance of IP fragmentation, multiple TLS records or a first flight that crosses congestion-window and middlebox assumptions. The draft itself acknowledges interoperability problems with buggy legacy TLS implementations and network devices.
Teams evaluating the proposal should start from the existing hybrid TLS reference, use the migration guide to preserve a standardized fallback, and repeat the end-to-end measurements in the hybrid TLS test guide. A laboratory handshake is not enough. The path through load balancers, inspection devices, QUIC fallbacks and constrained networks is part of the result.
The validation rules are as important as the parameter sizes
- Reject any client or server key share that is not exactly 1,624 bytes.
- Perform the FIPS 203 Section 7.2 encapsulation-key check before using the client's ML-KEM-1024 key.
- Apply the X448 all-zero shared-secret check and abort when the classical contribution is invalid.
- Never reuse either component key share across connections.
- Exercise HelloRetryRequest, standardized-group fallback, fragmented ClientHello and QUIC paths.
- Record the exact draft revision and experimental identifier in every test artifact.
These checks belong in both conformance testing and an implementation audit. A parser that accepts a truncated concatenation, reverses the component order or skips ML-KEM public-key validation can negotiate something that looks hybrid while violating the proposal's security contract.
What migration teams should do now
Do not replace X25519MLKEM768 because a version 00 draft offers larger parameters. Continue deploying the standardized group where it fits the threat model, and add MLKEM1024X448 to the watchlist for high-assurance profiles that can justify the wire cost. A migration programme should decide which security level each system needs before choosing the largest available parameter set by reflex.
The proposal is useful because it makes a real tradeoff explicit: a larger classical component can match ML-KEM-1024's intended margin, but every additional byte and implementation path must survive the network and operational environment. The next meaningful signals are working-group adoption, an assigned codepoint, independent implementations and interoperability results.
References
- draft-preussmattsson-tls-mlkem1024-x448-00, published 7 October 2026.
- RFC 9954, the general hybrid key-exchange construction for TLS 1.3.
- RFC 10024, the standardized ML-KEM hybrid groups for TLS 1.3.
- FIPS 203, the ML-KEM standard and parameter definitions.
- RFC 7748, the X25519 and X448 functions and validation behavior.
Where this goes next