Post-quantum encryption for Cloudflare IPsec is generally available
Cloudflare has made post-quantum encryption for its IPsec service generally available, using hybrid ML-KEM alongside classical Diffie-Hellman. The implementation protects WAN traffic against “harvest-now-decrypt-later” attacks and interoperates with Cisco and Fortinet hardware already deployed by customers. Cloudflare argues that broadly adopted, software-based standards—not specialized quantum key distribution hardware—are essential for achieving post-quantum security at Internet scale. ## Cloudflare IPsec and WAN Connectivity - Cloudflare IPsec is a WAN Network-as-a-Service connecting: - Data centers - Branch offices - Cloud VPCs - Cloudflare One SASE environments - Encrypted IPsec tunnels run over Cloudflare’s global IP Anycast network. - Customers receive simplified configuration, high availability, automatic traffic rerouting, and global network scale. ## Hybrid ML-KEM for IPsec - The new implementation uses hybrid ML-KEM, standardized as FIPS 203. - It addresses harvest-now-decrypt-later attacks, in which attackers collect encrypted traffic today and decrypt it once quantum computers can break current public-key cryptography. - ML-KEM is designed to run in software on standard processors and requires neither specialized hardware nor dedicated physical links. - The IETF draft `draft-ietf-ipsecme-ikev2-mlkem` combines: - A classical Diffie-Hellman exchange - A second ML-KEM exchange encrypted using keys derived from the first - Key material from both exchanges mixed into session keys for IPsec ESP traffic ## Interoperability with Network Hardware - Cloudflare initially tested its implementation against the strongSwan reference implementation. - General availability now includes interoperability testing with: - Cisco 8000 Series Secure Routers running version 26.1.1 or later - Fortinet FortiOS 7.6.6 or later - These devices can establish post-quantum Cloudflare IPsec tunnels without requiring new specialized networking hardware. ## Why IPsec Lagged Behind TLS - Hybrid ML-KEM reached TLS production roughly four years before a corresponding IPsec specification. - Cloudflare enabled hybrid post-quantum TLS key agreement in 2022, and more than two-thirds of human-generated TLS traffic to Cloudflare is now protected this way. - IPsec standardization moved more slowly partly because of continued interest in Quantum Key Distribution (QKD). - Cloudflare criticizes QKD as unsuitable for Internet-scale deployment because it: - Requires specialized hardware and dedicated physical links - Does not provide authentication - Has limited cross-vendor interoperability - The NSA, Germany’s BSI, and the UK’s NCSC have warned against relying solely on QKD. ## Standards and Compatibility Challenges - RFC 9370, published in 2023, allowed multiple parallel key exchanges with classical Diffie-Hellman but did not define the specific ciphersuites to use. - Some vendors introduced incompatible or non-NIST-standardized ciphersuites, creating “ciphersuite bloat.” - Cloudflare’s implementation does not currently interoperate with Palo Alto Networks’ earlier RFC 9370-based implementation. - The newer ML-KEM draft fills this gap by defining hybrid ML-KEM as a standardized exchange mechanism. - Cloudflare hopes continued industry convergence will eventually enable interoperability with additional vendors, including Palo Alto Networks. ## Remaining Post-Quantum Work - Hybrid ML-KEM currently protects key establishment and data confidentiality. - IPsec still needs standardized post-quantum authentication mechanisms to defend live systems against quantum-enabled active attackers. - Cloudflare’s broader goal is full post-quantum security by 2029. Cloudflare recommends prioritizing interoperable, software-based post-quantum cryptography over niche QKD deployments. Organizations using supported Cisco or Fortinet branch hardware can begin protecting IPsec WAN traffic against future quantum decryption threats now.
Read original(opens in new tab)