I know DNSSEC has a ton of flaws and has received a lot of justified criticism. But I'd still desperately love to be able to have good standards in place such that my possession of a given domain also allows me to operate a generally recognized private CA off of that for said domain (as well as elimination of a variety of DNS attacks of course). There shouldn't need for 3rd parties there in principle, it should be enough to just be able to put up a CA root public cert up in DNS and have everything automagically work from there. It'd make a host of things like RADIUS and future enhanced distributed auth email-likes a lot more convenient and less fragile. I love Let's Encrypt, but it's a bandaid for the fundamental issues with DNS. I hope increasing recognition of the centrality of DNS and need for improvements there will ultimately result in something modern and better than DNSSEC that can move a lot of stuff forward.
I'm not exactly sure this is germane to this thread because none of the query encryption mechanisms the root operators are writing about here really address the same things as DNSSEC.
This debate has happened in various places (here on HN; on mozilla.dev.security.policy; on the Let's Encrypt forum; on IETF WG mailing lists; presumably inside browser vendors' security teams) but I haven't usually seen the authoritative statement of both sides' views about the status quo and their visions of the future for web PKI.
I was involved in setting up Let's Encrypt, and I noticed that many of my colleagues were, to varying extents, themselves PKI skeptics (people who had been critical of existing CAs' practices, but also of the fragility of what certificates can even really attest to).
I've also seen (partly from a colleague who went to a bunch of meetings about these things) that generally e-mail people really like DNS and somewhat mistrust X.509, while commonly web people grudgingly respect X.509 and somewhat mistrust DNS. This was especially visible in the debate about DANE (a mechanism for putting public keys and statements about them in the DNS), and also in related debates about the role of DNSSEC. Reputedly, many of the avid DNSSEC users and DANE developers and proponents are e-mail software operators or implementers. We've also seen Thomas Ptacek here criticizing DNSSEC and arguing that it has no important role for Internet security (especially in terms of cryptographic protections against government eavesdropping).
During the DANE standardization, if I understand correctly, the developers hoped that it would eventually be on par with X.509 certificates as a way of validating public keys for TLS connections (both STARTTLS and HTTPS, as well as other applications). But I think the Chrome developers at some point made a clear statement to the effect of "nope, sorry, we're not going to do that"!
My intuition supporting any or all of "DNS registrars should be [name-constrained] CAs"/"DNS registries should be [name-constrained] CAs"/"DANE should replace X.509" was basically that DNS records are the fundamental source of ground truth for CAs issuing DV certificates, and literally if you look in the CA/B Forum's list of approved methods for doing domain validation, they're all about cross-checking information provided by DNS registrars, and similarly if you look at Let's Encrypt's domain validation methods (https://letsencrypt.org/docs/challenge-types/), they all directly rely on DNS, while the most secure method (DNS-01 challenge) is literally about the ability to place a TXT record into a specified DNS zone. So, DNS registrars and registries are directly being trusted in the DV issuance path -- every time.
The main counterarguments I remember were along these lines:
* DNS registries and registrars are (despite their huge importance) less security-conscious than CAs in numerous ways, and operate under less stringent security precautions and procedures. [But this argument is a little weird when CAs will issue certificates based on whatever the registries tell them.]
* DNS is less transparent than CAs, especially given the mandatory use of Certificate Transparency, which allows detection and investigation of misissuance. (Also if we relied on DANE without X.509, there would be no public or permanent record of the DANE DNS RRs that were used in a particular trust decision, so fraudulent ones might never be detected either contemporaneously or retrospectively, and a root or TLD keyholder could construct a completely fraudulent DNS signature chain that would be accepted by a particular relying party but never stored anywhere else.)
* You can choose a relatively security-conscious registrar, and then registry's security precautions should ensure that attacks against other registrars (or negligence or malice on their part) don't affect your domain's zone contents, but if registrars could directly issue certificates, arbitrary registrars could misissue for domains that aren't even registered through them. But registries couldn't usually issue certificates because they have no relationship with subscribers, no means of authenticating them, and no user interface through which certificate issuance could be requested or performed.
I think there are others. Maybe I could approach some people and get them to write up their different views of all of this for the record, not as part of a debate or flamewar.
Edit: the sibling comment reminds me that there are also different proposed use cases -- one is the belt-and-suspenders method where you need an X.509 certificate and a valid DNSSEC-signed DANE record confirming that the subject key is legitimate. Other proposals have been that the DANE record could be just-as-good as the X.509 certificate, or that it could eventually supplant it entirely.
Chrome found that the Internet as it actually exists, with a diversity of broken middleboxes, made DANE impossible to deploy effectively. You can't count on DANE lookups succeeding, because middleboxes shoot down DNSSEC lookups, which look weird compared to ordinary lookups. You can't distinguish between a broken middlebox shooting down your DANE lookup and an adversary deliberately suppressing DANE lookups. So, in effect, all DANE bought you was an additional single point of failure; you still had to trust the rest of the WebPKI infrastructure.
It's worth keeping in mind that proof of domain ownership doesn't have to depend on the DNS; you can also just ask registrars directly, via something like RDAP. If we're going to keep pinning Internet trust to name ownership, there's probably no reason we have to involve the DNS at all. Moreover: if you can accomplish WebPKI trust using an RDAP-type lookup, that pretty much obviates the need to forklift in a cumbersome, pre-outmoded signing system for the DNS itself.
> Chrome found that the Internet as it actually exists, with a diversity of broken middleboxes, made DANE impossible to deploy effectively. You can't count on DANE lookups succeeding, because middleboxes shoot down DNSSEC lookups, which look weird compared to ordinary lookups.
Yikes!
> It's worth keeping in mind that proof of domain ownership doesn't have to depend on the DNS; you can also just ask registrars directly, via something like RDAP. If we're going to keep pinning Internet trust to name ownership, there's probably no reason we have to involve the DNS at all.
Do you think this would be useful? I'm not part of the Let's Encrypt team anymore, but I still know almost all of them (but, to my knowledge, nobody from any registrars).
I've kind of wished for something like this in the past (on the basis that it would obviate other kinds of attacks against the domain validation process, such as routing or DNS attacks), but I'm not sure what the user interaction flow would look like, or whether it could be made compatible with Let's Encrypt's desire to automate almost all certificate issuance and renewal steps.
It seems like maybe the registrars would have to give out proof-of-ownership RDAP challenge API credentials (that a server could use to ask the registrar to serve a particular value via RDAP?).
From an absolute security perspective, I'm not sure I see how RDAP is much better than a DNS/DNSSEC-based solution, but if you can make RDAP work, you can get most (maybe more!) of the purported benefit of DNSSEC (vis a vis the WebPKI) with a tiny number of deployments, compared to the billions (I think, if you do the math over, say, 10 years, assuming wide deployment --- which won't happen, but, arguendo --- you can get there) we'll spend on DNSSEC...
I mean, given how just about all DNSSEC domains are bootstrapped through domain registrar interfaces and their APIs (which have been compromised in attacks before), that might not be the best idea. As a counterpoint I think despite it's flaws that removing any form of certificate/key pinning from browsers was a mistake, rather than learning from said issues (i.e Maybe provisioning pinning of the public keys through an HTTP header isn't the best idea.)
