[tptacek]

In a sense, yes, but not so much so that DoH is a dispositive argument for deprecating it.

The difference is that DoH protects transactions and DNSSEC protects the authenticity of records. It's perfectly possible for a DoH server to feed you bogus cached records; you have to trust the DoH server you're talking to, where you wouldn't have to do that if all the records on the chain of lookups you're doing are signed with DNSSEC, and you're running DNSSEC on your local system rather than a stub resolver than talks to full resolver server you have to trust (this is an uncommon set of circumstances and in practice you have exactly the same server trust problem with DNSSEC that you do with DoH).

Muddying the waters further, the attacks DNSSEC protects against overlap with the ones DoH protects again, so that if the whole Internet managed to switch to DoH, you'd have bottom-up built 95% of the security feature DNSSEC is attempting to provide (DoH has massively better deployment stats than DNSSEC, so this is plausible).

It's better to think of DoH as one of a catalog of different arguments that together make a clear case for sticking a fork in DNSSEC and calling it done.

[rainsford]

I think the best argument for DoH being the killing blow to DNSSEC is that not only does DoH overlap a lot with the security features DNSSEC is trying to be the solution for, but DoH also gives you arguably more important security features that DNSSEC does not and cannot reasonably provide.

This is particularly true if your security model also includes things like TLS to secure your communications with whatever domain you just resolved. In that scenario, the features DoH provides that DNSSEC does not (e.g. lookup confidentiality) are still quite useful, while the 5% of DNSSEC use-cases that DoH doesn't cover are essentially redundant if not better provided elsewhere in your protocol stack.

[cmeacham98]

> DoH has massively better deployment stats than DNSSEC, so this is plausible

Is this actually true where it matters? (i.e. the root servers and authoritative servers for TLDs)?

[tptacek]

Where what matters? On-path DNS attacks occur everywhere across the Internet, and are probably more common on the lookup side and at the edges. Certainly, the use of DoH to protect authority transactions isn't common, yet!

[cmeacham98]

The most devastating and primary attack I am worried about is someone obtaining a TLS certificate for my domain via services like Let's Encrypt.

Thus, I really care about LE getting the right IP, I don't care about random users' DNS getting hijacked because their browser will reject the missing/invalid certificate.

[tptacek]

LetEncrypt does validate DNSSEC signatures (when they exist), but CA's aren't even required to do that. LetsEncrypt also does multi-perspective lookups, so a single hijacked DNS transaction or poisoned cache is insufficient to trick it. Hopefully, at some point in the not-too-distant future, LE's multi-perspective lookup will generate data we can look at about the frequency of DNS attacks on certificate issuance. I expect it to be quite rare, because it's an elaborate attack with a weak payoff.

The right way to think about this CA issue is this:

* The largest, best-funded, savviest security teams in tech are, like the rest of tech, not signing their domains; the major TLDs are overwhelmingly not signed (there is low single digit uptake in .COM for instance, and what's there is overwhelmingly not big companies but rather random domains signed by registrars that auto-sign). Nobody who's actually targeted for CA misissuance attacks uses DNSSEC to mitigate that threat.

* The WebPKI already has a system in place to guard against misissuance that, unlike DNSSEC, actually does work: Certificate Transparency. So if you're actually concerned about CAs not issuing bogus certs for you, match your revealed preferences to your stated ones and set up CT monitoring.

[cmeacham98]

I'll take this massive shift of the goalposts as agreement that DNSSEC is much closer to solving some problems today than DoH is.

I would appreciate it if you would update your other comments in this thread clarifying that, as we both now agree they are incorrect.

[theamk]

Subscribe to CT logs for your domain, and you will know if this ever happens, from LE or from any oher authority. Such attack is a very big deal, if this happens this will only happen once, whichever hole is used will be closed. And if this does not happen, you can be rest assured your TLS is safe.

Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth".

[matthew9219]

> Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth"

This is a false dichotomy. DNSSEC secures DNS records, it doesn't prevent logging certificate issuance.

[acdha]

I think you misunderstood the claim: say the U.S. government leaned on the .com DNS server operators to issue a different response for, say, Gmail.com to certain requesting IPs. The absence of a mechanism like CT makes that very hard to detect since everyone else in the world is going to see the same correct response, and there’s no reason for the target’s DNS resolver to question a response with a valid DNSSEC signature, and since DNSSEC has no UI there’s not even a way for the user to notice.

That matters because, as the person you were replying to explained, there’s no plausible way to build such a thing. We have CT because the browser developers insisted on it and they control the clients but DNSSEC doesn’t have an equivalent party with that kind of leverage.