bwesterb

There's no store-now/decrypt-later, but DNS is notoriously slow to make any changes. Better start early. We're running probes from our challenge pas to the test zone, so we see how much breaks with these large signatures. If things look good, we can roll out ML-DSA-44 by default on all Cloudflare signed zones.

I like how an ML-DSA-44 RRSIG ends with a string AAAAAAAAAAAAAAAAAAA... a scream of relief it's finally out.

Scott used to be that guy.

It'll be a 90/10 rule: 90% of the upgrades will be straightforward. It's important the 10% that'll be hard early. For many it's probably already too late.

Where available, you can migrate. Even if PQ is not yet available it helps to:

1. Make sure your dependencies are up to date. Move to a recent version of your crypto libraries. 2. Make sure your server can install multiple certificates: you'll need that unless you control all your clients. 3. Automate certificate issuance as far as possible.

Also, what you can do now is to run the following wargame: assume the CRQC arrived. What's the business impact?

For the migration itself I see three parallel streams.

1. Main push of straight-forward cases (TLS, etc.) Might need to wait a bit for software support.

2. Hard cases: crypto baked into hardware; custom protocols; keys in tight spaces (JWT in URLs); etc. You need to bubble those up soon to make decisions on how to fix them.

3. External dependencies. Barely any vendor has a PQ roadmap, so asking now is probably early, but you can figure out what to do if they don't get their stuff ready in time.

We're almost done countering store-now/decrypt-later, but the biggest part of the job, post-quantum authentication, still remains. Like Google, we target 2029 to be done .

SSH is working on a drop-in as we speak. TLS is further along: most stacks already support X25519MLKEM768 (by default!) to counter store-now/decrypt-later. PQ certs are not widely supported yet, but that's being sped up as we speak.

When it's real, it's too late.

You sure? Defenders get funding if things break—not when they actually did their job.

Yeah, it's rough. Important to understand now for each product / system what the business impact is if it's not upgraded in time.

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.