[TLS] Re: draft-ietf-tls-key-share-prediction next steps

["Kampanakis, Panos" <[e-mail]>]

Thx Adrian for the reaction.

> There is a considerable difference between loading large amounts of data for a single site, which is a decision that is controllable by a site, and adding a fixed amount of latency to _all_ connections to all sites to defend against a computer that does not exist [3].

Fair. And draft-ietf-tls-key-share-prediction tries to address that. I like the draft. Btw, I have some disagreements to your “PQC Signatures damn too big” blog referenced in [3], but these are more or less similar to the ones I am sharing below.

> Adding Kyber to the TLS handshake increased TLS handshake latency by 4% on desktop [1] and 9% on Android at P50, and considerably higher at P95. In general, Cloudflare found that every 1K of additional data added to the server response caused median HTTPS handshake latency increase by around 1.5% [2].

I have seen these arguments, but I am still skeptical. Your points focus on the TLS handshake which is not necessarily directly tied to Web experience. According to https://firefox-source-docs.mozilla.org/testing/perfdocs/perf-sheriffing.html , even the 4% (>2%) regression for Desktops would be unacceptable. So, why is 4% in the handshake acceptable, but 9% is not?

If I am sending 100KB of data over the conn, 1 extra packet in the CH will not matter even for these mobile clients. We tried to make the point in https://www.ndss-symposium.org/ndss-paper/auto-draft-484/ . Ideally we should have proven it by measuring web metrics too (other than just the TTLB) but that requires more work.

I am arguing that 5% or 10% or even 20% of TLS handshake slowdown does not equate to the same slowdown in the CrUX / web metrics. For example, the TLS handshake should not affect the INP or CLS metrics at all. The LCP or the FCP will not be affected be an extra packet if the server sends 50+ packets per connection. https://httparchive.org/reports/state-of-the-web says that each mobile connection transfers about 200KB. This means 150+ packets. Will an extra CH packet really show up in this connection’s performance impact? I doubt it. Another data point,  https://httparchive.org/reports/loading-speed#fcp says that the median FCP and TTI for mobile is 3 and 16 seconds respectively. Will an extra packet in the CH really affect the multisecond FCP or TTI even in a slow connection at 1Kbps? That is questionable as well.

So, respectfully, is your assertion that ML-KEM768 will have noticeable impact for mobile based on measurable web metric data, or is it just based on an intuition which is focusing on the TLS handshake and could be overestimating the impact on real web metrics?


From: David Adrian <[e-mail]>
Sent: Thursday, September 12, 2024 11:26 PM
To: Kampanakis, Panos <[e-mail]>
Cc: David Benjamin <[e-mail]>; <[e-mail]> <[e-mail]>
Subject: RE: [EXTERNAL] [TLS] Re: draft-ietf-tls-key-share-prediction next steps


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


> Any numbers you have to showcase the regression and the relevant affected web metrics?

Adding Kyber to the TLS handshake increased TLS handshake latency by 4% on desktop [1] and 9% on Android at P50, and considerably higher at P95. In general, Cloudflare found that every 1K of additional data added to the server response caused median HTTPS handshake latency increase by around 1.5% [2].

> I have seen this claim before and, respectfully, I don’t fully buy it. A mobile client that suffers with two packet CHs is probably already crawling for hundreds of KBs of web content per conn.

There is a considerable difference between loading large amounts of data for a single site, which is a decision that is controllable by a site, and adding a fixed amount of latency to _all_ connections to all sites to defend against a computer that does not exist [3].

[1]: https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html
[2]: https://blog.cloudflare.com/pq-2024/
[3]: https://dadrian.io/blog/posts/pqc-not-plaintext/