Hacker News Reader

Comment by pvg | Hacker News Reader

Unrenewed certs have not caused the kind of extended mass outages DNSSec has, it's not close.

If Let's Encrypt goes down, half of the Internet will stop working. Doubly so when we switch to certs that are valid for just a couple of days.

That is... not how certificates work. The part of LetsEncrypt that has to work continuously ships as part of your browser root store.

The proposal is to make LE certs 9 days long or something. Which means if LE is down for even a short time thousands and millions of certs will expire.

You don't wait till the last second to renew. 9 day certificates would mean 7 day renewals for example. And at that point you could have 2 or 3 ACME-compatible services configured as a backup.

I doubt 20% of the LE users even know other ACME services exist let alone what they may be.

That's ok, this scales with requirements / experience / money on the line. Most people won't care about a day of downtime that much. And those who really don't know anything about SSL will be using a platform solving this for them.

The eventual plan is to limit certs to 48 hours (AFAIR), right now they're already allowing 6-day certs: https://letsencrypt.org/2025/02/20/first-short-lived-cert-is... In this scenario, if Let's Encrypt goes down for just a couple of days, a lot of certs will expire.

There are also operational risks, as Let's Encrypt has to have their secret key material in close proximity to web-facing services. Of course, they use HSMs, but it might not be enough of a barrier for nation-state level attackers.

The offline signing feature of DNSSEC allows the root zone and, possibly, the TLDs to be signed fully offline.

That's why in my ideal world I want to keep DNSSEC as-is for the root zone and the TLD delegation records, but use something like DoH/DoT for the second-level domains. The privacy impact of TLD resolution is pretty much none, and everything else can be protected fully.

That is not why DNSSEC has offline signers. DNSSEC has offline signers because when the protocol was designed, its authors didn't believe computers would be able to keep up with the signing work. Starting sometime in the middle of the oughts, people started to retcon security rationales onto it, but that's not the purpose of the design.

Do you have links for that? I don't really doubt that, since the work was done mid 90-s. But I'm genuinely curious about the early history of failed protocols (like IPv6 and DNSSEC), and I read most of the early archived discussions about IPv6.

Yes, somewhere I do; I wrote a complete history of the protocol, including archives I found of 90s-vintage mailing lists. I'll have to dig it up, though.

Reply on news.ycombinator.com