rdl
21 hours ago
It will be interesting to compare PQ rollout to HTTPS rollout historically (either the "SSL becomes widespread in 2015" thing, or the deprecation SSL 3.0). Cloudflare is in an easy position to do stuff like this because it can decouple end user/browser upgrade cycles from backend upgrade cycles.
Some browsers and some end user devices get upgraded quickly, so making it easy to make it optionally-PQ on any site, and then as that rollout extends, some specialty sites can make it mandatory, and then browser/device UX can do soft warnings to users (or other activity like downranking), and then at some point something like STS Strict can be exposed, and then largely become a default (and maybe just remove the non-PQ algorithms entirely from many sites).
I definitely was on team "the risks of a rushed upgrade might outweigh the risks of actual quantum breaks" until pretty recently -- rushing to upgrade has lots of problems always and is a great way to introduce new bugs, but based on the latest information, the balance seems to have shifted to doing an upgrade quickly.
Updating websites is going to be so much easier than dealing with other systems (bitcoin probably the worst; data at rest storage systems; hardware).
jeroenhd
21 hours ago
If any kind of proof about serious quantum computers comes to light, browsers can force most websites' hand by marking non-PQ ciphers as insecure.
Maybe it'll require TLS 1.4/QUIC 2, with no changes but the cipher specifications, but it can happen in two or three years. Certificates themselves don't last longer than a year anyway. Corporations running ancient software that doesn't support PQ TLS will have the same configuration options to ignore the security warnings already present for TLS 1.0/plain HTTP connections.
The biggest problem I can imagine is devices talking to the internet no longer receiving firmware updates. If the web host switches protocols, the old clients will start dying off en masses.
bwesterb
21 hours ago
No need for a TLS 1.4.
Leaf certificates don't last long, but root CAs do. An attacker can just mint new certs from a broken root key.
Hopefully many devices can be upgraded to PQ security with a firmware update. Worse than not receiving updates, is receiving malicious firmware updates, which you can't really prevent without upgrading to something safe first.
jeroenhd
2 hours ago
> An attacker can just mint new certs from a broken root key.
In Chrome at the very least, the certificate not being in the certificate transparency logs should throw errors and report issues to the mothership, and that should detect abuse almost instantly.
You'd still be DoSing an entire certificate authority because a factored CA private key means the entire key is instantly useless, but it wouldn't allow attacks to last long.
bwesterb
2 hours ago
Yeah, PQ certificate transparency is crucial for downgrade protection: https://westerbaan.name/~bas/rwpqc2026/bas.pdf
GoblinSlayer
3 hours ago
When you connect, you specify supported ciphers. If the server doesn't support them, there's standard "insufficient security" (71) error that was there since at least TLS 1.0, maybe earlier.
rocqua
27 minutes ago
Confidentiality of the TLS connection is indeed easy to handle here.
The hard part is certificate authentication. And that's not included in the cipher suite setting.
PunchyHamster
19 hours ago
There is no reason to not support non quantum safe algorithms for foreseeable future in the first place
greesil
17 hours ago
You did not increase comprehension by not using a single negative.
ZiiS
6 hours ago
They are slower, larger, and less tested. Specifically the hope was to develop hybrids that could also provably be more pre-quantum secure then what they are replacing. History dose not favour rushing cryptography.
bwesterb
2 hours ago
They are large, but they're not that slow actually. We've been testing them for almost a decade now. I agree that rushing is bad. That's why we need to start moving now, so that we're not rushing even closer to the deadline.
Hendrikto
4 hours ago
You misread the comment you replied to.
KAMSPioneer
3 hours ago
Which, to be fair, is easy to do because they used a triple-negative.
Rephrased, they meant to say "there is no reason to remove support for quantum-vulnerable algorithms in the near future."
IMO that's much less likely to be accidentally misinterpreted.
bwesterb
21 hours ago
Waiting now means rushing even more close to the deadline! We added stats on origin support for post-quantum encryption. Not as much support as browsers of course, but better than I expected. Still a long road (and authentication!). https://radar.cloudflare.com/post-quantum
stingraycharles
21 hours ago
> Updating websites is going to be so much easier than dealing with other systems (bitcoin probably the worst; data at rest storage systems; hardware).
IPv6 deserves a prominent spot there
fc417fc802
16 hours ago
Does it? That one is different because IPv4 with CGNAT largely "just works" except for P2P type stuff. As a result there's a strong incentive for anyone who has a working setup to just not care.
I can use myself as an example here. IPv6 is supported by all my hardware, all the software I use, and my ISP provides it. Yet my LAN intentionally remains IPv4 only with NAT. Why? Because adding IPv6 to my LAN would require nonzero effort on my part and has (at least for now) quite literally zero upside for me. If I ever need something it offers I will switch to it but that hasn't happened yet.
PQC is entirely different in that the existence of a CRQC immediately breaks the security guarantee.