A QUIC look at HTTP/3

> The logs would record every record change, or perhaps just every record change of the domain itself if the domain gets to provide its own subdomain records.

So.. you're advocating for a completely parallel system that's independent of the trust model of the existing one?

How is this "DNS transparency" party trustworthy where the existing DNS trust model is not?

Won't this require, in order to be effective, every client resolver to independently push the results of their lookups to this third party? Or download an ever-growing global log? And what's to prevent those from being intercepted?

> And you'd figure out if they're malicious in much the same way you do with CA transparency: if a change occurs that didn't come from the domain owner.

In the CA model, *every CA* is technically capable of issuing a valid certificate for any domain, and publishing the certificate is done by each individual service/server. Under the DNSSEC model, only the domain owner can *publish* a certificate for their domain, meaning there is no longer a distinct "issuance" step. As those third party CA issuers are no longer part of the trust model, there is no longer a need to independently audit them and what they do.

The threat model for DNSSEC is quite different, and requires a different approach -- there are only really three vectors, which I rank in their real-world relevance today:

1) Resolvers
2) Registrars (and TLD/root operators)
3) Zone owners themselves

(CAs already have all three of those threat vectors, and add a fourth)

If the zone owner/operator is compromised, then they can push "legitimate" updates and nobody will ever be the wiser.

Similarly, if the registrar, TLD, or root operator is compromised to the point where they maliciously serve different stuff for short periods of time or to specific users, we're all pretty much screwed as their trustworthiness underpins everything else.

(That said, DNSSEC's trust model only requires you to ultimately trust the root server keys. Those change very infrequently, and can be trivially pinned in client resolvers, not unlike the existing CAcert bundle..)

This leaves only (1) as a serious threat, and one that's actively in use today. DNSSEC was designed to mitigate that. Of course, it's not perfect -- Hostile resolvers just strip out DNSSEC from what they serve to their clients, as there's nothing widely deployed that "requires" DNSSEC as a prerequisite. Meanwhile, anything more elaborate than that (ie serving hostile stuff with valid DNSSEC signatures) would require compromising the client in advance (eg by substituting a different root cert bundle, or disabling use of DNSSEC validation)

(And this "DNS transparency" entity won't do anything to mitigate (1))

(Which makes me wonder, if someone were to convince my CA to issue a certificate for another domain via fraudulent means, wouldn't that still end up registered/signed with the Transparency log, and thus be considered valid by Chrome?)

Meanwhile, this still doesn't change the fact that this entire class of problem is due to the very loose coupling between independent parts/models -- ie trust, certificate publishing/distribution, and naming. If you tightly couple all three into the same system, one solely controlled by the domain owner, attacks that rely on that loose coupling go away completely.

(If I'm wrong or hopelessly naive here, please show me, preferably using small words, as I'm clearly missing something fundamental..)

Sure, this relies on trusting your domain registrar, the TLD operators, and the root server operators... but CAs already trust DNS to help them determine that you control the domain you say you do. End-users already trust DNS to point at your server before they can even retrieve that Transparency-attested certificate. If we can't trust the core DNS operators, we're already completely, utterly hosed.