[TLS] Bytes server -> client

[Bas Westerbaan <[e-mail]>]

Hi all,

Just wanted to highlight a blog post we just published.
https://blog.cloudflare.com/another-look-at-pq-signatures/  At the end we
share some statistics that may be of interest:

On average, around 15 million TLS connections are established with
> Cloudflare per second. Upgrading each to ML-DSA, would take 1.8Tbps, which
> is 0.6% of our current total network capacity. No problem so far. The
> question is how these extra bytes affect performance.
> Back in 2021, we ran a large-scale experiment to measure the impact of big
> post-quantum certificate chains on connections to Cloudflare’s network over
> the open Internet. There were two important results. First, we saw a steep
> increase in the rate of client and middlebox failures when we added more
> than 10kB to existing certificate chains. Secondly, when adding less than
> 9kB, the slowdown in TLS handshake time would be approximately 15%. We felt
> the latter is workable, but far from ideal: such a slowdown is noticeable
> and people might hold off deploying post-quantum certificates before it’s
> too late.



Chrome is more cautious and set 10% as their target for maximum TLS
> handshake time regression. They report that deploying post-quantum key
> agreement has already incurred a 4% slowdown in TLS handshake time, for the
> extra 1.1kB from server-to-client and 1.2kB from client-to-server. That
> slowdown is proportionally larger than the 15% we found for 9kB, but that
> could be explained by slower upload speeds than download speeds.


> There has been pushback against the focus on TLS handshake times. One
> argument is that session resumption alleviates the need for sending the
> certificates again. A second argument is that the data required to visit a
> typical website dwarfs the additional bytes for post-quantum certificates.
> One example is this 2024 publication, where Amazon researchers have
> simulated the impact of large post-quantum certificates on data-heavy TLS
> connections. They argue that typical connections transfer multiple requests
> and hundreds of kilobytes, and for those the TLS handshake slowdown
> disappears in the margin.


> Are session resumption and hundreds of kilobytes over a connection typical
> though? We’d like to share what we see. We focus on QUIC connections, which
> are likely initiated by browsers or browser-like clients. Of all QUIC
> connections with Cloudflare that carry at least one HTTP request, 37% are
> resumptions, meaning that key material from a previous TLS connection is
> reused, avoiding the need to transmit certificates. The median number of
> bytes transferred from server-to-client over a resumed QUIC connection is
> 4.4kB, while the average is 395kB. For non-resumptions the median is 7.8kB
> and average is 551kB. This vast difference between median and average
> indicates that a small fraction of data-heavy connections skew the average.
> In fact, only 15.8% of all QUIC connections transfer more than 100kB.


> The median certificate chain today (with compression) is 3.2kB. That means
> that almost 40% of all data transferred from server to client on more than
> half of the non-resumed QUIC connections are just for the certificates, and
> this only gets worse with post-quantum algorithms. For the majority of QUIC
> connections, using ML-DSA as a drop-in replacement for classical signatures
> would more than double the number of transmitted bytes over the lifetime of
> the connection.


> It sounds quite bad if the vast majority of data transferred for a typical
> connection is just for the post-quantum certificates. It’s still only a
> proxy for what is actually important: the effect on metrics relevant to the
> end-user, such as the browsing experience (e.g. largest contentful paint)
> and the amount of data those certificates take from a user’s monthly data
> cap. We will continue to investigate and get a better understanding of the
> impact.


Best,

 Bas