Posted by todsacerdoti 8 hours ago
Once again I would like to ask CA/B to permit name constrained, short lifespan, automatically issued intermediate CAs. Last year's request: https://news.ycombinator.com/item?id=43563676
We then can just staple the Persist DNS key to the certificate itself.
And then we just need to cut out the middleman and add a new IETF standard for browsers to directly validate the certificates, as long as they confirm the DNS response using DNSSEC.
So why not cut out the middleman?
(And the answer right now is "legacy compatibility")
The biggest problem is that DNS replies are often cached, so fixes for the mistakes can take a while to propagate. With Let's Encrypt you typically can fix stuff right away if something fails.
But let's not pretend that WebPKI is perfect. More than one large service failed at some point because of a forgotten TLS certificate renewal. And more than one service was pwned because a signing key leaked. Or a wildcard certificate turned out to be more wildcard than expected.
I understand the failures of DNSSEC and DNS in general. And we need to do something about it because it's really showing signs of its age as we continue to pile on functionality onto it.
I don't have an idea for a good solution for everything, but I just can't imagine us piling EVERYTHING onto WebPKI either.
You're commenting on a post about LetsEncrypt working with other entities in the industry to make improvements to WebPKI. It's safe to say that nobody's claiming it's perfect.
But you can't go from ~"WebPKI isn't perfect" and ~"DNSSEC/DANE exist" and draw a magic path where using DNSSEC or DANE is actually a good thing for people to roll out. They'd need to be actually a good fit, and for DANE we have direct evidence that it isn't: a rollout was attempted and it was walked back due to multiple issues.
It's also more secure, compared to ACME. An on-path attacker can impersonate the site operator and get credentials. DNSSEC is immune to that.