<p>The concern that post-quantum TLS will slow down HTTPS connections is widespread and, in most production environments, wrong. The performance record from Cloudflare's deployment at internet scale, Chrome's default hybrid key exchange across hundreds of millions of connections, and Apple's PQ3 messaging protocol tells a consistent story: ML-KEM-768 hybrid key exchange adds no perceptible latency at the median. The residual concerns are real but specific. This article gives you the actual numbers to make that assessment for your own deployment rather than relying on speculation.</p>

<p>For an understanding of how the TLS handshake structure changes, and which components stay identical, see <a href="/insights/post-quantum-tls-what-changes-stays-same/">Post-Quantum TLS: What Changes and What Stays the Same</a>. This article focuses on performance data, not protocol anatomy.</p>

<h2>The baseline numbers for a standard TLS 1.3 handshake</h2>

<p>Before comparing performance, you need the baseline. A TLS 1.3 handshake with X25519 key exchange and an ECDSA P-256 certificate chain involves the following approximate sizes:</p>

<ul>
  <li>ClientHello: approximately 300 to 500 bytes, including a 32-byte X25519 key share, cipher suite list, and extensions</li>
  <li>Server flight (ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished): approximately 2 to 4 KB for a two-certificate chain with ECDSA P-256 signatures</li>
  <li>Client Finished: approximately 50 bytes</li>
</ul>

<p>Total handshake: approximately 3 to 5 KB for a typical TLS 1.3 connection. The X25519 scalar multiplication runs in approximately 0.1 ms on modern server hardware, a number that is entirely invisible against network round-trip times of 10 to 100 ms. The computation cost has never been the concern with classical TLS. The same is true, more emphatically, for ML-KEM.</p>

<p>RFC 8446 defines the handshake message structure. RFC 7748 specifies X25519. The size figures above reflect the message boundaries in those specifications; actual sizes vary with certificate chain length and extension negotiation.</p>

<h2>Cloudflare's production deployment: what the real data shows</h2>

<p>Cloudflare deployed hybrid post-quantum TLS across its global TLS termination infrastructure beginning in 2023, initially using X25519+Kyber768, then updating to X25519+ML-KEM-768 following NIST FIPS 203 finalisation. The data Cloudflare published from that deployment is among the largest real-world PQC TLS datasets available. Their findings:</p>

<ul>
  <li>No measurable increase in TLS handshake latency at the median for connections where the hybrid key share was accepted by the client</li>
  <li>Fewer than 1% of connections experienced handshake failures or additional round trips due to middlebox interference</li>
  <li>Affected connections involved mobile networks and enterprise firewall configurations that enforced maximum TLS extension size limits</li>
</ul>

<p>The ClientHello size with X25519+ML-KEM-768 is approximately 1,400 to 1,600 bytes. The ML-KEM-768 public key alone is 1,184 bytes (NIST FIPS 203, Table 2). For TCP-based TLS over HTTP/1.1 and HTTP/2, this fits within a standard TCP segment without triggering an additional round trip. The TCP initial congestion window on modern Linux (approximately 10 segments at 1,460 bytes each, totalling around 14,600 bytes) absorbs a 1,600-byte ClientHello without issue.</p>

<p>QUIC is different. RFC 9000 requires that a QUIC Initial packet fit within approximately 1,280 bytes on IPv6 paths to avoid fragmentation. A hybrid ClientHello that reaches 1,600 bytes exceeds this limit and may require QUIC-layer handling. For HTTP/3 deployments, this is the more operationally sensitive constraint.</p>

<h2>Chrome and the GREASE approach to middlebox conditioning</h2>

<p>Google enabled X25519+ML-KEM-768 hybrid key exchange in Chrome by default, with the underlying implementation in BoringSSL. Chrome's data matched Cloudflare's server-side observations: the additional ClientHello key share bytes did not measurably increase connection establishment times for typical HTTPS connections to well-configured servers. Hybrid TLS runs at scale across a substantial fraction of HTTPS connections globally wherever servers support the corresponding server-side TLS extension.</p>

<p>Chrome's deployment team used GREASE (Generate Random Extensions And Sustain Extensibility, RFC 8701) to condition the middlebox ecosystem ahead of the actual PQC rollout. The approach: Chrome sends a large fake key share extension in ClientHellos before deploying the real ML-KEM key share, so that network equipment encounters and learns to tolerate oversized ClientHellos. Middleboxes that drop or fragment unusual TLS extensions become visible in failure rate data before they can silently degrade production traffic.</p>

<p>The practical lesson for enterprise deployments: the middlebox problem documented by both Cloudflare and Chrome is not random and is not permanent. It is addressable. The failure pattern concentrates in older enterprise firewalls and DPI appliances with hardcoded TLS extension size limits. As firmware updates propagate, failure rates decline. Cloudflare's data confirmed this trend. Test your specific network path before assuming transparency.</p>

<h2>Apple PQ3: ML-KEM-768 performance at consumer messaging scale</h2>

<p>Apple deployed PQ3 in iOS 17.4 and macOS 14.4 (February 2024). PQ3 is not a TLS protocol; it is a hybrid post-quantum ratcheting protocol for iMessage, built on Signal's Double Ratchet architecture, combining X25519 with ML-KEM-768 for initial key establishment and ratchet updates. The distinction from TLS matters for interpreting the latency data: iMessage is asynchronous, where TLS is synchronous, so the latency sensitivity is different. What PQ3 provides is evidence that ML-KEM-768 hybrid key establishment adds no perceptible overhead at consumer scale.</p>

<p>Apple ran PQ3 in shadow mode before full deployment, with parallel classical and PQ3 processing to validate performance and correctness under production conditions. The published conclusion: no measurable degradation to iMessage delivery times. At hundreds of millions of active devices, this settles the question of whether the ML-KEM-768 arithmetic is computationally manageable at scale.</p>

<p>PQ3 proves the CPU arithmetic is not a constraint. For TLS-specific performance in production, the Cloudflare and Chrome datasets are the more directly applicable evidence. For a deeper look at the algorithmic comparison, see <a href="/quantum-news/ml-kem-vs-x25519-comparative-performance-analysis/">ML-KEM vs X25519: A Comparative Performance Analysis</a>.</p>

<h2>The actual numbers: CPU cost of ML-KEM and ML-DSA</h2>

<p>On x86-64 hardware with AVX2 vector instructions, ML-KEM-768 key operations run significantly faster than X25519. Benchmark data from the CRYSTALS-Kyber specification (Avanzi et al., Round 3, August 2021) and Open Quantum Safe liboqs confirm:</p>

<table>
  <thead>
    <tr>
      <th>Algorithm</th>
      <th>KeyGen</th>
      <th>Sign / Encaps</th>
      <th>Verify / Decaps</th>
      <th>Context</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>X25519</td>
      <td>~</td>
      <td>~0.10 ms</td>
      <td>~0.10 ms</td>
      <td>Key exchange</td>
    </tr>
    <tr>
      <td>ML-KEM-768</td>
      <td>~0.033 ms</td>
      <td>~0.038 ms</td>
      <td>~0.038 ms</td>
      <td>Key exchange</td>
    </tr>
    <tr>
      <td>ECDSA P-256</td>
      <td>~</td>
      <td>~0.08 ms</td>
      <td>~0.22 ms</td>
      <td>Signing</td>
    </tr>
    <tr>
      <td>ML-DSA-65</td>
      <td>~0.12 ms</td>
      <td>~0.18 ms</td>
      <td>~0.12 ms</td>
      <td>Signing</td>
    </tr>
  </tbody>
</table>
<p><small>Benchmarks from CRYSTALS-Kyber and CRYSTALS-Dilithium specification documents on Intel Skylake with AVX2. ML-DSA-65 is specified in NIST FIPS 204. Performance on platforms without AVX2 differs; verify with liboqs benchmarks for your target environment.</small></p>

<p>ML-KEM-768 KeyGen, Encaps, and Decaps each run in 33 to 38 microseconds with AVX2. X25519 scalar multiplication takes approximately 100 microseconds on the same hardware. ML-KEM is faster. The performance concern with post-quantum TLS is not CPU computation. It is packet size on specific network paths and middlebox behaviour.</p>

<p>ML-DSA-65 tells a slightly different story. Signing takes approximately 0.18 ms versus ECDSA P-256's 0.08 ms; verification at 0.12 ms is modestly faster than ECDSA P-256's 0.22 ms. ML-DSA-65 signing is roughly twice the CPU cost of ECDSA signing. On high-throughput servers signing millions of certificate verifications per day, the overhead is real but manageable. The more significant cost, when certificate migration eventually occurs, is the size of ML-DSA certificate chains in the handshake, not the CPU cost of signing operations.</p>

<h2>Four variables that determine production impact</h2>

<p>The real-world performance of PQC TLS in your deployment depends on four variables, not a single aggregate figure. Cloudflare's "no measurable latency impact" finding applies to the common case across those variables. Your case may differ.</p>

<p><strong>Variable 1: TCP versus QUIC.</strong> TCP connections are largely unaffected by the additional ~1.2 KB ClientHello key share. The TCP initial congestion window (~14,600 bytes on modern Linux) absorbs it without triggering an additional round trip. QUIC connections face a tighter constraint: the QUIC Initial datagram must fit within approximately 1,280 bytes for IPv6 path compatibility (RFC 9000). Test HTTP/3 endpoints separately from HTTP/1.1 and HTTP/2 endpoints.</p>

<p><strong>Variable 2: Path MTU and middlebox behaviour.</strong> TLS inspection proxies, WAN optimisers, and deep packet inspection appliances with hardcoded TLS extension size limits are the primary failure mode in production. Less than 1% of connections in Cloudflare's deployment, but concentrated in mobile networks and older enterprise firewall configurations. Test through your actual network topology, including any TLS inspection proxies on the path.</p>

<p><strong>Variable 3: Certificate chain migration status.</strong> As long as certificates remain ECDSA, the certificate chain size is unchanged. The large handshake increase materialises only when hybrid key exchange and ML-DSA certificate migration are both complete. Most deployments today are in the hybrid key exchange phase only. Certificate migration is a separate, later step with larger size implications.</p>

<p><strong>Variable 4: HSM signing latency for high-rate deployments.</strong> For TLS servers that use HSMs for private key operations, current HSM hardware may not natively support ML-DSA. Signing latency on non-native HSMs can exceed the software benchmark significantly. For high-connection-rate servers with HSM-backed keys, assess your HSM vendor's ML-DSA roadmap before planning the certificate migration phase.</p>

<p>Before enabling hybrid ML-KEM TLS in production, measure four specific things:</p>

<ul>
  <li>ClientHello size through your network path: use <code>openssl s_client</code> with an OQS-OpenSSL or BoringSSL build and capture with Wireshark or tcpdump</li>
  <li>Middlebox behaviour: run a hybrid ClientHello through your TLS inspection proxy and load balancer stack and check for ClientHello fragmentation or connection resets</li>
  <li>Handshake latency distribution (p50, p95, p99) before and after enabling hybrid key exchange, from your TLS termination infrastructure</li>
  <li>QUIC Initial packet fragmentation if you operate HTTP/3 endpoints, tested on both IPv4 and IPv6 paths separately</li>
</ul>

<h2>Putting the numbers in context</h2>

<p>A 2 KB additional handshake from hybrid key exchange on a 50 ms RTT network path does not add a round trip in most TCP configurations. The latency impact is sub-millisecond in the common case, as Cloudflare's production data confirms. For a 15 KB larger certificate chain after full ML-DSA migration (that is, 3 certificates with ML-DSA-65 signatures at roughly 3,309 bytes each plus public keys), an additional round trip becomes possible on paths with a 14,600 byte initcwnd, though it remains negligible on a low-latency data centre fabric.</p>

<p>For high-connection-rate deployments performing millions of handshakes per day, 0.038 ms per ML-KEM Encaps is well within the computational budget of modern server hardware. CPU capacity is not the constraint. The cases where PQC TLS performance genuinely warrants careful planning are three: strict latency SLA requirements (sub-5 ms TLS handshake) on low-MTU paths; existing middlebox infrastructure with TLS size enforcement that will need firmware updates; and very-high-connection-rate servers on older HSM hardware when the certificate migration phase eventually arrives.</p>

<p>None of those are reasons to delay hybrid key exchange deployment. They are reasons to test before you deploy, and to treat certificate migration as a separate planning exercise from key exchange migration.</p>