[daneel_w]

>... which leads to huge overheads in network traffic and of course CPU time.

This is just the key exchange. You're exchanging keys for the symmetric cipher you'll be using for traffic in the session. There's really no overhead to talk about.

[lillecarl]

Indeed, I'll expand a bit: Asymmetrical crypto has always been incredibly slow compared to symmetrical crypto which is either HW accelerated (AES) or fast on the CPU (ChaCha20).

But since the symmetrical key is the same for both sides you must either share it ahead of time or use asymmetrical crypto to exchange the symmetrical keys to go brrrrr

[simiones]

This still greatly affects connections/second, which is an important metric. Especially since servers don't always like very long lived connections, so you may get plenty of connections during an HTTP interaction.

[daneel_w]

It doesn't "greatly" affect it at all. The extra traffic and time required between curve25519 and ML-KEM768+X25519 is actually less than the jump from RSA2048 to RSA4096. Imagine how silly a person would appear if they had been this alarmist about RSA4096. When building for scales where it may eventually add up you should already be taking such scale into consideration.