TLS trust model depends on DNS. DV certificates are issued to anyone who controls DNS. OV and EV certificates aren't useful. Browsers never displayed an indicator for OV and EV didn't accomplish much so they stripped away the indicators for that too. There's basically just DV.
Conversation
Let's Encrypt and other public CAs will give you a certificate to anyone who controls DNS from their perspective. If someone hijacks controls of your DNS or simply spoofs it (if you don't have DNSSEC) they can simply obtain valid Let's Encrypt certificates to use for your domain.
1
WebPKI does nothing to proactively defend against DNS hijacking or spoofing. The only mechanism that's offered is reactive defence via Certificate Transparency (CT).
CT currently depends on Expect-CT header pinning because you can spoof dates prior to Chrome requiring it.
1
Certificate Transparency isn't trivial to use. You need to track all certificates actually issued by your servers. Otherwise, how do you figure out which are your Let's Encrypt certificates vs. someone else who hijacked DNS and issued certificates for your domain? Non-trivial.
2
So, with the necessary infrastructure for it, CT allows you to receive an alert that a certificate was created which wasn't issued by your actual server. Revocation doesn't really work well, especially when you didn't issue the certificate, so that's just even more of a mess.
1
At that point, the attack has happened, and you're trying to clean up the aftermath. If they're still in a position to hijack DNS, they can just keep getting new certificates. There's nothing you can do about it beyond watching it with CT (once it's truly mandatory, at least).
1
So, perhaps the DNS trust model is inappropriate for WebPKI, but WebPKI currently entirely depends on the DNS trust model as the base and makes it substantially weaker. WebPKI isn't actually useful beyond CT. It would be strictly better to have TLSA + CT and throw out the rest.
1
There are a bunch of government controlled entities trusted as CAs able to issue certificates for every single domain. There are a ton of TLDs available now offering a ton of different options for who you want to trust. Google alone has a bunch of public ones like app, dev, page.
1
And ~70% of .page domains are DNSSEC-signed. So if Google is your benevolent dictator who does no evil, you're good to go. :-)
1
I'm curious if that's because .page is significantly less popular than .app and .dev so most people using it are getting it via Google Domains which deploys DNSSEC for you by default if you use their DNS servers. On other registrars, I've mostly had to toggle it on and wait ages.
1
It'd be interesting to know the % of DNSSEC adoption for different registrars. TLD is revealing in some ways (like .nl adoption) but I think it mostly has to do with registrar default and then how prominent / easy the option is to enable it is if it's not enabled by default.
That dataset is not easily obtainable. It would require bulk WHOIS lookups, which are rate limited, and so only the registry, and registrars with special access to such data can get those numbers.
1
1
I could try to infer the registrar from the NS and/or SOA records, but this does not always work, and presently, I don't include NS and SOA in the survey dataset.
1