At the beginning of a TCP connection, which is when the certificate chain is sent, you can't send more data than the initial congestion window without waiting for it to be acknowledged. 160KB is far beyond the initial congestion window, so on a high-latency connection the additional time would be higher than the numbers you calculated. Of course, if the web page is very bloated the user might not notice, but not all pages are bloated.

The increased certificate size would also be painful for Certificate Transparency logs, which are required to store certificates and transmit them to anyone who asks. MTC doesn't require logs to store the subject public key.

▲

Veserv 4 hours ago | parent [-]

That is exactly the type of poor design that I was saying should be rectified.

You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed.

You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating.

And I fail to see how going from 4 KB of certificate chain to 160 KB of certificate chain poses a serious storage or transmission problem. You can fit literal millions into RAM on reasonable servers. You can fit literal billions into storage on reasonable servers. Sure, if you exactly right-sized your CT servers you might need to upgrade them, but the absolute amount of resources you need for this is miniscule.

▲

ekr____ an hour ago | parent | next [-]

A few points of technical clarification might help here.

1. The reason for a relatively small initial congestion window (cwnd) is to avoid situations where a lot of connections start up and collectively exceed the capacity of the network, causing congestion collapse. Instead, you start slow and then gradually ramp up, as you learn the available capacity. Slow start started in TCP but it's in QUIC too. Initial windows actually used to be a lot smaller and TCP only moved up to its current 10 packet initial window (IW10) after a bunch of experimentation that determined it was safe.

2. The congestion window is actually a property of the sender, not the receiver. The receiver advertises the size of their flow control window, but that's about the buffer, not the sending rate (see section 7 of RFC 9002 for the discussion of slow start in QUIC). So in this case, the server controls cwnd, no matter what the client advertises (though the server isn't allowed to exceed the client's advertised flow control window).

3. QUIC and TCP behave fairly similarly in terms of the broad strokes of rate control. As I noted above, QUIC also uses Slow Start. The amplification limit you mention is a separate limit from initial cwnd, which is intended to avoid blind amplification attacks, because, unlike TCP, QUIC servers can start sending data immediately upon receiving the first packet, so you don't know that the IP address wasn't forged. However, even if the peer's IP is authenticated, that doesn't mean it's safe to use an arbitarily large initial cwnd.

▲

raggi 2 hours ago | parent | prev | next [-]

> You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed.

The aggressive tone is no defense against practical problems such as the poor scalability of such a solution.

> You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating.

Not before key exchange it doesn't. There's no magic bullet here.

A refresher on the state of TFO and QUIC PMTU might be worthwhile here before jumping this far ahead.

▲

Veserv an hour ago | parent [-]

You have asserted without evidence that the increased certificate chain size is the primary scaling bottleneck. I assert that the bottleneck is most likely due to accidental complexity elsewhere on the argument that claimed problems look to be far in excess of the essential complexity.

> Not before key exchange it doesn't. There's no magic bullet here.

I was incorrect. Rereading the QUIC standard I see that they do not flow control the CRYPTO packet number space/stream. I thought they did because it is so easy to do that I did it as a afterthought. Truly another example of fundamental design errors introducing accidental complexity that should be fixed instead of papered over.

	▲	ekr____ 37 minutes ago \| parent [-]
		Can you elaborate a bit more about what you think the unnecessary complexity here? A basic source of concern here is whether it's safe for the server to use an initial congestion window large enough to handle the entire PQ certificate chain without having an unacceptable risk of congestion collapse or other negative consequences. This is a fairly complicated question of network dynamics and the interaction of a bunch of different potentially machines sharing the same network resources, and is largely independent of the network protocol in use (QUIC versus TCP). It's possible that IW20 (or whatever) is fine, but it may well may not be. There are two secondary issues: 1. Whether the certificate chain is consuming an unacceptable fraction of total bandwidth. I agree that this is less likely for many network flows, but as noted above, there are some flows where it is a large fraction of the total. 2. Potential additional latency introduced by packet loss and the necessary round trip. Every additional packet increases the chance of one of them being lost and you need the entire certificate chain. It seems you disagree about the importance of these issues, which is an understandable position, but where you're losing me is that you seem to be attributing this to the design of the protocols we're using. Can you explain further how you think (for instance) QUIC could be different that would ameliorate these issues?

▲

nickf 2 hours ago | parent | prev [-]

Your failure to see the problem doesn’t mean it doesn’t exist. 40x the size might not really be an issue for the hypothetical server you’ve suggested - but that isn’t the reality for the world. Many devices do HTTPS and TLS. Not to mention the issue is more with the clients. CT logs would get a lot harder to run (and they’re already not so easy).