Ah, the next step towards True DANE!

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.

▲

tptacek 4 hours ago | parent [-]

This decreases the salience of DANE/DNSSEC by taking DNS queries off the per-issuance critical path. Attackers targeting multitenant platforms get only a small number of bites at the apple in this model.

▲

NoahZuniga 4 hours ago | parent | next [-]

DNS queries are still part of the critical path, as let's encrypt needs to check that the username is still allowed to receive a cert before each issuance.

▲

cyberax 4 hours ago | parent | prev [-]

Sure. It's yet another advantage of doing True DANE. But it still requires DNS to be reliable for the certificate issuance to work, there's no way around it.

So why not cut out the middleman?

(And the answer right now is "legacy compatibility")

▲

tptacek 4 hours ago | parent [-]

I mean, the reason not to do DANE is that nobody will DNSSEC-sign, because DNSSEC signing is dangerous.

▲

cyberax 2 hours ago | parent [-]

Come on. It's not dangerous, it's just inconvenient and clumsy. So nobody is really using it.

▲

akerl_ 2 hours ago | parent [-]

Ok, it's inconvenient and clumsy in ways that make it easy to shoot oneself in the foot. But that's not dangerous?

▲

cyberax an hour ago | parent [-]

When you shoot yourself in the foot with DNSSEC, you typically end up with a non-working setup.

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.

▲

tptacek an hour ago | parent [-]

When you shoot yourself in the foot with DNSSEC, your entire domain falls of the Internet, as if it had never existed in the first place. It's basically the worst possible case failure and it's happened to multiple large shops; Slack being the most notorious recent example.

	▲	cyberax 5 minutes ago \| parent [-]
		Yes, and it'd be great if DNSSEC added an "advisory" signature level. So it can be deployed without doing a leap of faith. 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.