> 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.
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.