Skip to content

PATTERN Cited by 2 sources

TLS-first PQC rollout as blueprint

Shape

A deployment pattern where a new cryptographic primitive rolls out to TLS first, validates the construction + installed-base + performance profile at Internet scale, and then subsequent protocols (SSH, IPsec, messaging, DNS) follow TLS's blueprint — reusing the same hybrid-KEM construction, the same algorithm- negotiation mechanism, and the same ciphersuite convergence discipline.

TLS plays the lead-protocol role because:

  • TLS's installed base is the largest by endpoint count (every HTTPS connection).
  • TLS's standards community converges fastest (small working group, strong Google / Cloudflare / Mozilla / Microsoft alignment).
  • TLS 1.3's supported_groups / key_share extension mechanism is built for exactly this kind of rollout.
  • Browsers auto-update, so the client-side deployment rolls forward faster than any other protocol family.

Canonical framing from Cloudflare's 2026-04 IPsec PQ GA post:

"A full specification for hybrid ML-KEM in IPsec, draft-ietf-ipsecme-ikev2-mlkem, became available only in late 2025. That's roughly four years after support for hybrid ML-KEM landed in TLS. (In fact, Cloudflare turned on hybrid post-quantum key agreement with TLS in 2022, even before NIST finalized the standardization of ML-KEM, because the TLS community quickly converged on a single, interoperable approach and pushed it into production.)" (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The five-stage rollout template

Stage 1 — Primitive standardisation

NIST (or equivalent body) selects and standardises the primitive: ML-KEM → FIPS 203 (August 2024) for PQ key encapsulation; ML-DSA → FIPS 204 (2024) for PQ signatures.

Stage 2 — TLS first

The TLS community defines the hybrid construction and names a canonical ciphersuite. For ML-KEM this is X25519MLKEM768 = X25519 ECDH + ML-KEM-768 combined via HKDF- Expand. Cloudflare + Google + browsers ship the hybrid pre-finalisation (2022, as X25519Kyber768Draft00) using algorithm negotiation to avoid breaking classical clients.

Stage 3 — Mass TLS deployment validates the construction

Production-scale deployment proves:

  • The hybrid is CPU-tolerable at handshake-heavy edge loads.
  • The ~1 kB wire overhead doesn't break MTU / middlebox / QUIC assumptions.
  • Algorithm negotiation successfully rolls the installed base forward (browsers auto-update into PQ; legacy clients fall back to classical).
  • >65 % of human-generated TLS traffic to Cloudflare is PQ-encrypted by early 2026 (radar.cloudflare.com/post-quantum).

Stage 4 — Sibling protocols adopt the construction

SSH, IPsec, messaging protocols follow, typically with the same hybrid construction but protocol-specific algorithm names:

  • SSH: sntrup761x25519-sha512 (OpenSSH 9.0+, 2022-04) for Streamlined NTRU Prime + X25519; ML-KEM-based hybrid pending library support.
  • IPsec: draft-ietf-ipsecme-ikev2-mlkem (late 2025); GA in Cloudflare IPsec 2026-04 with Cisco / Fortinet interop.
  • Signal protocol: PQXDH (2023) — hybrid with CRYSTALS-Kyber.

Stage 5 — Ecosystem convergence

Laggard protocols close the gap by borrowing TLS's approach wholesale rather than re-deriving. Vendor-specific ciphersuites (e.g. Palo Alto Networks' RFC 9370 PQ path) converge toward the named canonical.

Why TLS goes first — five structural reasons

  1. Browser auto-update ships client-side PQ faster than any other protocol's client-library update cycle. Chrome rolled hybrid Kyber into the default in 2023. No SSH / IPsec / VPN client fleet updates that fast.
  2. CDN concentration at the server side — Cloudflare + AWS + Akamai + Fastly serve so much of the web that enabling PQ on four server-side deployments covers a large fraction of the Internet's TLS traffic. Other protocols don't have this concentration.
  3. Low-risk experimentation surface. A mis-configured TLS handshake drops a connection; the client retries on classical; user sees minor latency. A mis-configured IPsec tunnel takes down an enterprise branch office.
  4. Standards community velocity. The IETF TLS working group ships faster than IPsec / SSH working groups. Smaller vendor footprint, tighter consensus loop.
  5. Measurement infrastructure. Cloudflare Radar / Google Transparency Report publish PQ adoption telemetry for TLS; no equivalent public dashboard exists for IPsec. Fast feedback on rollout.

The sibling-protocol payoff

Following TLS's blueprint lets a sibling protocol skip most of the risk:

  • Construction is already validated. Hybrid KEM with PQ + classical combined via KDF is operationally battle-tested at Internet scale.
  • Algorithm negotiation mechanism is already proven. Just extend the protocol's equivalent of supported_groups.
  • Ciphersuite convergence discipline is named. Name the canonical hybrid at standards-publication time; don't repeat RFC 9370's Path-B mistake.
  • FIPS status is known. NIST approval of ML-KEM / ML-DSA is already pipelined; sibling protocols inherit this.
  • Threat model is consistent. HNDL on KEM side; signature forgery on auth side — protocol- agnostic.

Cloudflare's framing of what's left:

"While draft-ietf-ipsecme-ikev2-mlkem supports post-quantum encryption, we still need IPsec standards for post-quantum authentication, so that we can stop attacks by quantum adversaries on live systems after Q-Day."

The authentication-side story will also roll out TLS-first, with ML-DSA certificate chains + Merkle Tree Certificates leading in TLS (Cloudflare Mid-2027 target) and sibling protocols following.

When the pattern is most valuable

  • Protocol has a standards-body analogue of TLS's supported_groups / key_share mechanism. SSH (KEXINIT), IPsec (IKEv2 SA payload), SMTP (STARTTLS extensions), DNS (DNSSEC algorithm advertisement) all qualify.
  • Protocol has a large installed base with slow client-side update cycles — sibling protocols benefit most from reusing the TLS pattern because they can't afford flag days.
  • The new primitive has been through production-scale TLS deployment — not an experimental primitive that might still be found to have a cryptanalytic weakness.
  • The protocol's existing cryptography is on the same mathematical foundation as TLS's — classical DH + X25519 ECDH in both means the hybrid shape transfers cleanly.

When to deviate from the blueprint

  • Protocol has structural constraints TLS does not share. IPsec's MTU-sensitive path characteristics (tunnels over UDP with fragmentation-hostile middleboxes) may require ML-KEM-512 instead of ML-KEM-768 where TLS can afford ML-KEM-768.
  • Protocol has different trust model. Messaging protocols (Signal) have per-user identity keys with different lifetimes than TLS server certs; the signature-side blueprint differs.
  • Protocol has its own legacy cryptography (e.g. PGP's RSA-primary world) where the hybrid baseline is different.

Counter-example: the QKD-IPsec distraction

Cloudflare's IPsec PQ post explicitly names the IPsec community's failure to follow TLS's blueprint as a four-year-delay failure mode:

"The four-year delay is likely due in part to the IPsec community's continued interest in Quantum Key Distribution (QKD), as codified in RFC 8784, published in 2020." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The TLS community did not entertain QKD at any point; the IPsec community did; the IPsec community paid four years of delay. The pattern is a discipline against protocol-community re-derivation of decisions TLS has already made.

Seen in

  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical instance on the IPsec sibling side. Cloudflare explicitly frames IPsec's 2026-04 GA as "roughly four years after support for hybrid ML-KEM landed in TLS" and attributes the delay to the IPsec community not following TLS's convergence pattern — specifically, entertaining QKD (RFC 8784) + letting RFC 9370 ship as ciphersuite-bloat-prone extension mechanism without a canonical ciphersuite named. The post's standards-community ask is explicitly to not let QKD distract again as the authentication-side rollout follows TLS's blueprint toward the 2029 target.
  • sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github — canonical instance on the SSH sibling side. GitHub rolls out sntrup761x25519-sha512 for SSH in 2025, three years after TLS PQ hybrid. Same algorithm-negotiation + hybrid-construction pattern as TLS, applied to SSH's KEXINIT advertisement; FIPS-boundary constraint carved out per region. Another example of the blueprint working when sibling-protocol communities adopt it; ML-KEM-based SSH hybrid pending library support.
Last updated · 433 distilled / 1,256 read