[jcrites]

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.

[tptacek]

Again, this is a redefinition of the concept of a WebPKI trust anchor (or, for that matter, of a "trust anchor" in any PKI; it would be equally confusing to describe the Linux kernel as a "trust anchor" in a secret storage or XML signing or inter-services authentication PKI).

If you want to use an idiosyncratic definition of a term, that's fine --- I won't, but I can at least follow the argument. But what you can't do is say "that citation you provided does not say what you said it does" when it clearly does using the mainstream definition of the term. It's especially fallacious to pull out this semantic argument about a reliable source that generates a surprising conclusion about trust anchors!

DNSSEC adds trust anchors to the Web PKI.

Obviously, I disagree with the argument that we "need" DNSSEC to securely issue certificates, but the rest of this thread adequately captures my rebuttals to that argument.

[Ajedi32]

If you insist on such a narrow definition of the term "trust" then yes you're technically correct. But it also reduces your entire argument into one of semantics; there's no security impact to adding a new "trust anchor" as you're defining the term.

[tptacek]

No, sorry, you're not getting away with that argument. We're not debating "trust"; we're debating "trust anchors". "Trust anchor" is a term of art with a specific meaning, and you can't pretend I'm the one trying to exploit a technicality when you've built an argument whose premise is an idiosyncratic redefinition of the term.

Besides that, you were just plain wrong, twice (you doubled down when I showed the quote that refuted your claim). It's fine to be wrong; I'm wrong all the time! But stubbornly refusing to acknowledge when you're plainly incorrect to the extent where you redefine words is not a good look.

[Ajedi32]

Okay, that's fair. You've won the semantic argument, I was wrong to argue that DANE doesn't add new "trust anchors".

The central point of your comment is still completely wrong though. DANE does _not_ add new trusted actors, and has no significant negative security impact.

[tptacek]

"Trusted actor"? Seriously?

[Ajedi32]

That's the term magila used in the comment you originally replied to near the start of this thread before you started the whole semantic debate about "trust anchors". Ultimately, trust is something you place in people and organizations, not inanimate cryptographic primitives.