Skip to content

PATTERN Cited by 1 source

Standards convergence over vendor extension

Shape

A standards-body discipline where a new protocol capability is introduced by simultaneously publishing (a) the generic extension mechanism and (b) a named canonical default ciphersuite / algorithm that every implementation is expected to support. The pattern is an explicit anti-pattern counter to the common failure shape of publishing the extension mechanism first, letting vendors ship incompatible ciphersuites under it, and then years later publishing a clean-up specification that names the canonical choice.

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

"We hope the IPsec community continues to focus on the development of interoperable standards like draft-ietf-ipsecme-ikev2-mlkem." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The two-outcome tree

When a standards body publishes an extension mechanism for a new capability (e.g. "protocols MAY negotiate additional post-quantum KEMs in parallel with classical DH"), two paths open:

Path A — Converge early. Publish, or immediately co-publish, a companion specification naming the canonical ciphersuite. Vendors implement against the named default. Deployments interoperate cross-vendor from day one.

Path B — Leave the gap. Publish only the mechanism. Vendors implement against the mechanism using vendor-branded ciphersuites. Deployments do not interoperate cross-vendor. Later, a clean-up specification names the canonical ciphersuite; vendors slowly converge; installed base remains fragmented for the transition period.

The pattern says choose Path A. The IPsec / PQ episode is a canonical Path B case study whose remediation cost is four years of delayed deployment.

TLS (Path A) vs IPsec (Path B) — the canonical comparison

Axis TLS PQ rollout IPsec PQ rollout
Extension mechanism supported_groups / key_share (since TLS 1.0) RFC 9370 (2023)
Named default ciphersuite X25519Kyber768Draft00 → X25519MLKEM768 (draft through 2022-2024) Gap: 2020-2025. draft-ietf-ipsecme-ikev2-mlkem fills it (late 2025).
Vendor implementations before canonical name Minimal; browsers + CDNs waited for draft convergence Yes: Palo Alto Networks shipped RFC-9370-based PQ with custom ciphersuites
Cross-vendor interop on PQ path Yes, from 2022 No for PANW ↔ Cloudflare as of 2026-04
Time to mass PQ traffic ~2 years to >65 % of human traffic TBD; GA just announced 2026-04
Distraction tangents Minimal QKD (concepts/quantum-key-distribution-qkd) / RFC 8784 (2020)

Cloudflare's explicit framing:

"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 mechanism — extension-without-default is a failure mode

A standards publication that opens a policy surface without naming the default produces ciphersuite bloat:

"Some vendors shipped early implementations under RFC 9370 before the hybrid ML-KEM draft was available, defining their own ciphersuites including some which are not NIST-standardized. This is exactly the kind of 'ciphersuite bloat' NIST SP 800 52r2 warned against."

The interoperability regression is not a theoretical risk — it's the default outcome. See concepts/ciphersuite-bloat for the full mechanism.

Why the pattern is hard in practice

  • Standards-body incentive asymmetry. Participants representing vendors with in-flight implementations push for flexibility and against prematurely binding to a single ciphersuite. Those participants benefit individually from flexibility and bear the interop cost collectively.
  • Primitive maturity lag. Sometimes the generic mechanism is ready to publish but no candidate primitive is mature enough to name as canonical (this was briefly true for ML-KEM pre-NIST- finalisation). Better to wait than publish Path B.
  • Multiple candidate ciphersuites. In some domains there are legitimate reasons to support more than one (e.g. FIPS-approved vs non-FIPS; different security levels). Naming one canonical default for the interop pool + listing alternatives is the discipline; not naming any is the failure.
  • Regulatory pressure. Different jurisdictions may mandate different primitives. The standards-body discipline is to name the canonical NIST / regulatory default while leaving the negotiation mechanism open for jurisdictional overlays.

Signals that a protocol community is on Path B

  • RFCs publish with an open ciphersuite registry but no canonical default.
  • Vendor-branded ciphersuite names (vendor_a_pq_kem_v1) appear in product release notes.
  • Operator-side documentation mentions "interop testing required between Vendor A and Vendor B."
  • Cross-vendor bake-offs produce empty-intersection handshake failures rather than interop successes.
  • Standards-body clarifying drafts appear years after the mechanism RFC, explicitly pinning a ciphersuite.

Signals that a protocol community is on Path A

  • Mechanism RFC and named-default RFC / draft publish together or within one standards-cycle.
  • Vendor implementations wait for the named default before shipping (or gate their PQ path on "draft-foo compliance" rather than the mechanism RFC).
  • Reference implementation (e.g. strongswan for IPsec, OpenSSL for TLS) publishes the named default early and drives cross-vendor interop testing against it.
  • Migration telemetry is measurable (e.g. Cloudflare Radar's 65 %- of-human-traffic-PQ-encrypted figure).

When the pattern is most critical

  • Protocols with long-lived installed bases. Any protocol deployed on hardware with multi-year refresh cycles (enterprise routers, HSMs, embedded IoT) — where installed-base fragmentation persists for years after clean-up.
  • Protocols carrying sensitive long-lived data. Any protocol where HNDL exposure during the fragmentation window has real cost (i.e. most of the cryptographic protocol space).
  • Protocols gated by regulatory regimes. FIPS / BSI / NCSC / ANSSI approval processes extend the convergence window; Path B here means years of regulated customers stuck on classical-only.

Remediation playbook for Path-B scenarios

Once a protocol community finds itself on Path B:

  1. Publish the canonical ciphersuite specification quickly — don't let the ambiguity compound.
  2. Name reference implementations that exercise the canonical ciphersuite — strongswan for IPsec is the canonical example.
  3. Interop-test against the reference implementation as a forcing function for pre-standard vendors to converge.
  4. Publish deprecation schedules for vendor-specific ciphersuites (with transition windows proportional to installed-base life).
  5. Report customer-visible interop gaps publicly — Cloudflare's explicit naming of the Palo Alto Networks non-interop is pressure-forcing.

Seen in

  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical wiki instance. Cloudflare explicitly ties the four-year TLS-to-IPsec delay to the IPsec community's failure to converge early on a named canonical PQ ciphersuite after RFC 9370; names draft-ietf-ipsecme-ikev2-mlkem as the belated convergence vehicle; articulates the explicit standards-community ask ("continue to focus on interoperable standards like draft-ietf-ipsecme-ikev2-mlkem"); names Palo Alto Networks as the canonical vendor-specific-implementation casualty awaiting the industry-wide convergence.
Last updated · 433 distilled / 1,256 read