Summary

  • RFC 10024 defines three TLS 1.3 groups—X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024—that combine ML-KEM with a traditional elliptic-curve component for key agreement.
  • Key agreement derives session secrets. Certificate validation and the CertificateVerify signature authenticate the endpoint. Migrating the first operation does not silently migrate the second, nor does it prove coverage after TLS terminates.
  • Bas Westerbaan co-authored the RFC with Krzysztof Kwiatkowski, Panos Kampanakis and Douglas Stebila. His significance is the staged engineering boundary: standards, implementation, negotiation, authentication, deployment and recovery each need their own evidence.

The strongest clue in a post-quantum TLS audit may be two facts that appear to contradict each other. The connection negotiated a post-quantum/traditional hybrid group. The certificate chain and handshake signature remained classical.

There is no contradiction. The facts describe different cryptographic jobs.

RFC 10024, published as an IETF Proposed Standard in August 2026, makes one of those jobs deployable with stable TLS 1.3 code points. Krzysztof Kwiatkowski, Panos Kampanakis, Bas Westerbaan and Douglas Stebila define X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Each group joins ML-KEM, the module-lattice key-encapsulation mechanism standardised by NIST, with a familiar elliptic-curve key-establishment component.

The purpose is not cosmetic algorithm diversity. A passive adversary can record encrypted traffic now and hope to recover the classical key agreement if a cryptographically relevant quantum computer becomes available later. A PQ/T hybrid is designed so that deriving the session secret does not depend on only the traditional family or only the newer post-quantum component.

That result matters. It also has a precise edge.

One handshake, separate questions

TLS 1.3 uses key exchange to establish secret material and a key schedule to derive traffic keys. It uses certificates, trust chains and a CertificateVerify signature to authenticate the server in the usual certificate-based handshake. The operations are joined inside one protocol transcript, but they do not answer the same question.

Hybrid key agreement asks whether the parties can derive connection secrets through a construction combining the specified components. Certificate authentication asks whether the party presenting the endpoint identity controls the private key corresponding to a trusted certificate and signs the transcript with an accepted signature scheme.

RFC 9794 makes the vocabulary explicit. PQ/T hybrid key establishment, hybrid KEMs, hybrid public-key encryption and hybrid digital signatures are different scheme families. A deployment can move one family before another. RFC 9935, which defines X.509 identifiers for ML-KEM keys, is another reminder that certificate and PKI migration has its own formats, issuance decisions and validation dependencies. An identifier is not an issuance programme, and a hybrid key share is not a post-quantum signature.

This separation changes the threat statement. Hybrid key agreement chiefly addresses a passive harvest-now-decrypt-later adversary seeking future access to recorded sessions. A future active adversary capable of forging a classical certificate signature could impersonate an endpoint. Both are quantum-era concerns, but they have different mechanisms, maturity and operational controls.

Westerbaan’s staged migration evidence

Cloudflare Research describes Westerbaan as a Research Engineer working to drive post-quantum adoption from cryptographic engineering and standardisation through large-scale experimentation and deployment. His IETF record includes RFC 10024 and other post-quantum work. That record does not make him the sole inventor of the hybrid mechanism; the RFC has four authors and stands on the general construction in RFC 9954, the terminology in RFC 9794, TLS 1.3 and NIST's ML-KEM standard.

His relevance is clearest in a first-party deployment account. In September 2025, Cloudflare said more than one-third of human-generated traffic to its network used TLS 1.3 with hybrid post-quantum key agreement. The same article said post-quantum digital signatures and certificates were still being standardised for use in TLS and Internet PKI, and that the WARP client had not yet been upgraded to use them.

The juxtaposition is more useful than a broad “quantum-safe” claim. It records a production-scale advance and its unfinished neighbouring control. It also carries limits: the percentage describes Cloudflare's dated observation, not the Internet as a whole; the WARP statement does not establish every later configuration; and an edge handshake does not reveal every internal hop.

Staged migration is not failure. It is the normal condition of a system whose cryptographic components have different standards, software, hardware, certificate and operational dependencies. The failure begins when a component receipt is promoted into an architecture-wide label.

What a negotiated group proves

A client can advertise several supported groups. That advertisement proves capability or preference, not the final selection. A server can select an RFC 10024 group. That negotiation proves what the visible endpoint and client agreed to attempt, not that each implementation is free of defects, side channels or weak randomness.

A successful handshake gives stronger operational evidence. It shows that the observed endpoints completed the transcript and derived usable traffic keys under the negotiated construction. It still does not reveal every property of the certificate authority, signature algorithm, private-key custody, TLS terminator, session-resumption path, 0-RTT policy, proxy chain or origin connection.

Nor does it answer what happens after decryption. An application may store plaintext, encrypt records under unrelated keys, copy data into logs or backups, or send it through another connection. Recovery may require rotating certificates, session tickets, application secrets and stored-data keys independently. “PQ encrypted” on one connection is not a receipt for those surfaces.

The RFC itself rejects careless portability. Its security section gives reasons for the specified construction and warns readers not to assume that similar hybridisation is secure in other protocols. Concatenating two secrets is not a universal post-quantum recipe. The protocol context, combiner, length rules, transcript and threat model matter.

From product label to evidence ledger

Heng Lu's Running-Code Primacy offers an operational test: the declaration is not the result. Here the declaration might be a dashboard badge saying “post-quantum”. The running result is the set of observed cryptographic and architectural properties that the service can reproduce.

A defensible receipt should include the client and endpoint; time; TLS version; advertised and negotiated groups; implementation versions; certificate chain; CertificateVerify signature scheme; termination point; resumption and 0-RTT behaviour; protection of downstream hops; and the boundary at which data is decrypted or stored. It should record probe method and limitations so a future operator can repeat the observation.

Ownership follows those fields. Standards groups specify the mechanisms. Library and browser teams implement them. Service operators configure groups, signatures, certificates, termination and fallback. Certificate authorities govern issuance. Network and platform teams own proxies and internal hops. Application and data teams own storage. Incident teams own revocation and recovery. No single green handshake can discharge every owner.

RFC 9851's feature freeze for TLS 1.2 reinforces the direction of travel: new protocol capabilities belong in TLS 1.3 rather than being improvised into the older version. But moving to the right protocol generation is still not evidence that every cryptographic plane moved at the same time.

Bas Westerbaan and his co-authors have made the key-agreement step easier to name, negotiate and verify. The honest next sentence is equally important: which step has not moved yet?

Sources