hckrnws
FWIW if you want to tinker on the topic I recommend OQS https://github.com/open-quantum-safe/ including Chromium, Apache, nginx, curl, etc. It's quite fun to play with.
What are appropriate default parameters?
The mozilla SSL Config Generator doesn't yet support PQ; it has Old, Intermediate, and Modern: https://ssl-config.mozilla.org/
mozilla/ssl-config-generator: https://github.com/mozilla/ssl-config-generator
"Chrome switching to NIST-approved ML-KEM quantum encryption" (2024) https://news.ycombinator.com/item?id=42265927
"ML-KEM Mythbusting" (2025) https://news.ycombinator.com/item?id=46074381 re: AuthKEM
The title is vague, my first thought was "We already have MLKEM". Which is enough against passive attackers.
The article apparently is about the CA/certs for authenticating the server, a part of HTTPS
Also just now Chrome published https://www.chromium.org/Home/chromium-security/post-quantum...
While I appreciate more efficient and compact representations, I fail to see why this is particularly necessary. This article [1] on the same topic indicates a naive PQ chain is only ~40x the size of a current 4 KB chain. That means it is just ~160 KB.
If you have the legal minimum to be considered broadband in the US, you need ~100 Mbps, so that would add ~12 ms.
If you can stream one 4K video, you need ~20-40 Mbps, so that would add ~30-60 ms.
If you can stream one 1080p video you need to ~3-6 Mbps, so that would add ~200-400 ms.
Even on just a 1 Mbps connection, just barely enough to stream a single 480p video that would only add ~1 second.
And I doubt the weight of most of pages is lower than 160 KB. Many of them are probably dramatically higher, so the total effect of a extra 160 KB is just a few percent.
If there is a problem, it seems like it would be with poorly designed protocols and infrastructure which should be fixed as well instead of papering them over.
[1] https://arstechnica.com/security/2026/02/google-is-using-cle...
The key will be 40x larger. Not that bad for the certs. It'll be about 15kB extra. Will depend on your use case if that's bad. For video it's fine. But not all browsing is video. At Cloudflare half of the QUIC connections we see transfer less than 8kB from server -> client total. On average 3-4kB of that is already certificates today. That'll probably be quite noticeable. https://blog.cloudflare.com/pq-2025/#do-we-really-care-about...
But do those connections constitute a material amount of total bandwidth and thus resources? No, as the article points out the median is 8 KB, but the average is 583 KB. The extra 15 KB for each connection would only bump server-side bandwidth serving by ~2%.
But even that is beside my point. The impact of making certificates larger should be, largely, just the cost of making them larger which, on average, would not actually be that significant of a impact. That is not the real problem. The problem is actually that there is so much broken crap everywhere in networks and network stacks that would either break or dramatically balloon what should otherwise be manageable costs.
Everybody just wants to paper over that by blaming the larger certificates when what is actually happening is that the larger certificates are revealing the rot. That is not to say that the proposal which reduces the size of the certificates is bad, I think it is good to do so, but fixing the proximal cause so you can continue to ignore the root cause is a recipe that got us into this ossified, brittle networking mess.
Comment was deleted :(
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.
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.
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).
> 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.
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?
For point 1, as I noted here [1], total bandwidth and resources are dominated by large flows. Endpoints are powerful enough to handle these large flows. The primary problems would lie with poor intervening networks and setup overhead.
For point 2, that is a valid concern of any case where you have just plain old more data. This dovetails into my actual point.
The problem of going from a 4 KB certificate chain to a 16 KB certificate chain, 160 KB certificate chain, or any arbitrary sized certificate chain should be equivalent to the problem of "server sends N byte response like normal". To simplify the problem a little it is just: the client sends a R-byte request message, the server responds with the Q-byte response message (which happens to be a certificate chain), the client sends the P-byte actual request, the server responds with a K-byte response message. So, at the risk of over-simplification, the problem should only be marginally harder than any generic "time to Q + K bytes".
Of course, if you previously had a 4 KB actual response and a 4 KB certificate chain and now it is a 160 KB certificate chain, you are going from "time to 8 KB" to "time to 164 KB". That is the essential complexity to the problem. But as I noted in my response to your point 1, the amount of server and client resources actually being expended on "small" requests is small with only poor networks where you are now consuming significantly increased bandwidth being a problem.
This then leads into the question of why "time to 8 KB" versus "time to 164 KB" is viewed as such a dramatic difference. This is a artifact of poor protocol design.
From a network perspective, the things that mostly matter are end-to-end bandwidth, end-to-end latency, endpoint receive buffer size, and per-hop bandwidth/buffering. You have a transport channel with unknown, dynamic bandwidth and unknown latency and your protocol attempts to discover the true transport channel parameters. Furthermore, excessive usage degrades overall network performance, so you want to avoid over-saturating the network during your discovery. In a ideal world, you would infer the transport parameters of every hop along your path to determine your holistic end-to-end transport channel parameters. This is problematic due to paths shifting or just plain dynamic throttling, so you will probably only limit yourself to "client to common bottleneck (e.g. your router) path" and "common bottleneck to server path". The "client to common bottleneck path" is likely client controlled and can be safely divided and allocated by the client. The "common bottleneck to server path" is not efficiently controllable by the client so requires safe discovery/inference.
The "initial congestion window" is a initial bandwidth-delay product to avoid over-saturating the network. This does not directly map to the transport parameters that matter. What you actually want is a initial safe "end-to-end bandwidth" which you refine via the discovery process. The latency of your roundtrip then only matters if the endpoint receive buffer size is too small and only effects how quickly you can refine/increase the computed safe "end-to-end" bandwidth.
Under the assumption that a 16 KB "initial congestion window" is fine and we assume the default RTT is ~100 ms (a somewhat reasonable assumption for geographically distributed servers who want to minimize latency) then that is actually a initial safe "end-to-end bandwidth" assumption of (16 KB / 0.1 s * 8 B/b) = ~1.3 Mb/s. Assuming the client advertises a receive buffer large enough for the entire certificate chain (which it absolutely should) and there are no packet losses, the client would get the entire certificate chain in ~(1 s + RTT) in the worst case. Note how that has only a minor dependency on the end-to-end latency. Of course it could get the data sooner if the bandwidth gets refined to a higher number, and a lower RTT gives more opportunities to get refined to a higher number, but that bounds our worst case (assuming no packet loss) to something that is not really that bad especially for the poor network throughput that we are assuming.
This then makes it obvious how to improve this scheme by choosing better initial estimates of "end-to-end" bandwidth or actively communicating that information back and forth. The "client to common bottleneck path" can be "controlled" by the client, so it can allocate bandwidth amongst all of its connections and it can set aside bandwidth on that leg for receiving. This allows higher initial "end-to-end" bandwidth assumptions that can be safely clipped when the client realizes it is in bad network conditions such as plane wifi. If the server determines "I have set aside N b/s to the 'internet' for this client" and the client determines "I have set aside M b/s from the 'internet' for this server" then your only problem is if there is a bottleneck in the broader backbone connections between the server and client. You would almost certainly be able to support better initial bandwidth assumptions or at least faster convergence after first RTT if you communicated that information both ways. This is just a example of what and how things could be improved with fairly minimal changes.
And this all assumes that we are even trying to tackle this fairly fundamental root issue rather than what are probably heaps of other forms of accidental complexity like middleboxes just giving up if the certificates are too large or whatever else nonsense there is which is what I am pretty sure is the real impetus by why they want the networking equivalent of wanting the 737-MAX to handle the same as a 737.
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.
Let's say you visit a site that doesn't use H2. That's now nearly a megabyte (up from 24kb) of data across the six connections that HTTP/1.1 establishes.
You're on LTE? You have high packet loss over a wireless connection? The initial TCP window size is ~16kb in a lot of cases, now you need multiple round trips over a high latency connection just to make the connection secure. You'll probably need 3-4 round trips on a stable connection just for the certificate. On a bad connection? Good luck.
Exactly, HTTP/1.1 is a poorly designed protocol and there are good reasons why we have newer versions of HTTP which avoid multiple unnecessary encryption handshakes.
Exactly, using a blanket default initial congestion window of 16 KB is stupid. Even ignoring that it was chosen when average bandwidth was many times less and thus should be increased anyways to something on the order of the average BDP or you should use a better congestion control algorithm, it is especially stupid if you are beginning a connection that has a known minimum requirement before useful data can be sent.
These things should be fixed as well instead of papering them over. Your system should work well regardless of the size of the certificate chain except for the fundamental overhead of having a larger chain.
I mean, unless you stop supporting H1, you're stuck with it. "Fixing" it means killing it. Unless you break every site/API that uses it, you can't do that.
Increasing the initial congestion window is probably smart, but increasing it to a size large enough to hold a 160kb certificate is almost certainly a terrible idea. Lots of people with "broadband" probably never get close to 160kb congestion window size.
Flaky wifi or a bad mobile signal will probably never get above a 32kb congestion window size—that's today, with modern hardware. That's five round trips assuming you start at 32kb and it never increases.
You think airplane wifi is bad? Imagine how bad it'll be when the congestion window starts at an order of magnitude bigger than it would normally ever reach. The "fix" means... Well I don't know actually, because if it could be good, you'd think at least one carrier would have good in-flight wifi. I doubt you could overcome to bureaucratic and technical challenges.
This isn't a problem that can be "fixed" in a lot of cases. If you optimize for the happy path, you're not just hurting people who literally don't have another option, you're hurting yourself when under bad connections.
You are not breaking H1, it just runs poorly in a different environment than the one it was created during. This is frankly already true which is why we literally have had two entire major versions since.
A 160 KB congestion window with 50 ms RTT means you are limited to a maximum bandwidth of 3,200 MB/s (~25 Mbps). At 200 ms RTT you are limited to ~6.5 Mbps. At 32 KB you are getting ~5 Mbps and ~1 Mbps, respectively.
If you are literally being limited to 1 Mbps, then you should not use a initial 160 KB congestion window as that is too much for your connection anyways. You can solve this with proper adaptive channel parameter detection in your network stack. In the presence of arbitrarily poor, degraded, or lossy network conditions, you should already be doing this to achieve good throughput and initial connection throughput.
A proper design should only really have the problem of "we are literally sending more data which fundamentally takes a extra N units of time on our K rate connection". This is a problem that is still worth solving by reducing the size of the certificate chain, but if you have other problems than that then you should solve them as well. More pointedly, having problems other than that directly points at serious structural design deficiencies that are ossified and brittle.
The pivot to MTC is a big change in the infrastructure of https. I wish other browsers were at least mentioned in this blog post. I'm curious about the future of letsencrypt as well.
Discussed few weeks ago on https://community.letsencrypt.org/t/post-quantum-crypto-road... specifically "The path we're more interested in is Merkle Tree Certificates, currently in design at the PLANTS working group at IETF. Chrome has indicated that they anticipate this to be their preferred approach to PQC. We're following that very closely, and are likely to deploy MTCs if it looks like that design is going to be supported widely." according to Matthew McPherrin, Let's Encrypt staff
There are also Merkle ladders.
What is the difference between a Merkle Tree Certificate and a Merkle Ladder?
Is this correct?:
Without Merkle Tree Certificates, the per keypress overhead for e.g. jupyter_server would be something like 3.3 KB due to the PQ signatures.
Merkle Tree Certificates basically uses the same structure as Certificate Transparency today. Merkle Ladder uses a weird variation claimed to be useful to DNSSEC. I think it's rather just to seem novel ( https://datatracker.ietf.org/ipr/search/?submit=draft&id=dra... )
I found buzzwords for this; Quantum-Resistant Decentralized PKI / DNS:
Multilinear/Hash-based VCs and Sum-Check protocol for Stateless PKI (with Sparse Merkle Tree (SMT))
PKI-over-Log with Hyper-Trees, Decentralized PKI (DPKI), XMSS^MT, M-FORS and F-SPHINCS+ (stateless),
"Spartan: Efficient and General-purpose zkSNARKs without Trusted Setup" (2020) https://link.springer.com/chapter/10.1007/978-3-030-56877-1_... :
- Spartan implements the Sum-Check protocol with Multilinear Polynomial Commitments, which is hash-based like XMSS and SPHINCS+ (unlike Verkle trees which are built on KZG which relies on the "Discrete Logarithm Problem" (which Shor’s broke)).
[dead]
Crafted by Rajat
Source Code