> Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors
There are two ways that you might wish to use DANE in a web browser: either to block a certificate that would normally be considered valid, or to bless a certificate that would normally be rejected. The first, obviously, requires that DANE information always be obtained—if a lookup failure was ignored, a network attacker with a bad certificate would just simulate a lookup failure. But requiring that browsers always obtain DANE information (or a proof of absence) is nearly implausible
That paragraph does not claim DANE expands the number of trust anchors.
As magila stated, registrars are already a trust anchor for domain validated certificates. Trusting a certificate directly via DANE vs through a domain-validated certificate doesn't change that. It does, however, cut CAs out of the process, which reduces the number of trust anchors.
If you can't use DANE to block certificates that the WebPKI says are valid, then you're stuck trusting both DANE and the CAs. Browsers don't trust DANE today. Ergo, adoption of DANE would expand the number of trust anchors.
Assuming we need to keep backwards compatibility indefinitely that's true, but that still wouldn't expand the number of trust anchors. DANE isn't a new trust anchor, it's just a more direct way of trusting preexisting trust anchors (DNS registrars). Even if you don't use or support DANE you still need to trust the registrars.
No, that is false. DNS registrars do not sign CA certificates and, without DANE, are not trust anchors in the WebPKI. And, of course, with DANE, they would essentially gain that status. This is a plain fact, but you can reason your way to it axiomatically by (again) considering how trust would be rescinded: Google singlehandedly killed the web's largest CA after a misissuance, but obviously cannot do that to .COM in a DANE world.
When your argument starts depending on redefinitions of well-established concepts, that's a sign that you should reconsider it.
I think we are getting mixed up in this thread over multiple senses of the term "trust". One sense is PKI. Ajedi32 is referring to a different type of trust.
Everyone who uses .com must trust the authority for .com, because that registry's name servers are what delegate control of all domain names in the TLD. Every time you resolve a domain name like "example.com", you are relying on the name servers for ".com" to serve correct information.
If the registry was malicious (or if an attacker compromised it), then the registry could easily seize control of any domain name -- it could rescind the delegation and publish whatever DNS records it chooses, including the DNS records necessary to obtain a domain-validated certificate.
It is correct to say that we "trust" TLD authorities because they can do these malicious things, but they commit to behave in a certain way. We trust TLD authorities in the same way that we trust certificate authorities only to issue certificates following a certain process. Both of these actors are capable of fraudulently obtaining certificates: the CA can mis-issue a certificate directly, whereas the TLD can seize a domain's DNS and trivially procure a domain validated certificate (from a legitimate CA).
This is what I believe Ajedi32 means when referring to "trust anchor" (using the term informally). DNSSEC is not adding new trusted entities, but is rather adding PKI around an existing trust relationships: a child DNS zone (e.g. example.com) always needs to trust its parent zone (e.g. the .com TLD). In the PKI sense, I agree that it would be adding new trust anchors, but those trust anchors would simply model preexisting trust relationships that don't use PKI.
On that note, we also need to trust the Internet root name servers that point to the name servers for the TLDs.