I don't know what you mean by "Firefox doesn't enforce [CT]". Mozilla has been instrumental in dis-trusting misissuing CAs.
For example Firefox doesn't check for SCTs so if you show my Firefox an apparently brand new certificate for which there are no SCTs (because maybe it's actually bogus) it will carry on as if nothing happened.
It also doesn't check validity periods. If you show Firefox a certificate from Let's Encrypt claiming notBefore 1986-03-02 and notAfter 2024-09-16 it considers that seems fine, never mind that the Web PKI didn't exist in 1986 or that nobody is allowed to issue leaf certificates that last almost 40 years - it doesn't care about that.
They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid.
Source: https://developer.mozilla.org/en-US/docs/Web/Security/Certif....
I guess that webmasters just don't care about DNSSec.
I will concede that if you centralize all your stuff on Cloudflare, it's very easy to set up. That's why Cloudflare makes it so easy to set up. Cloudflare is one of a single-digit small number of exceptions to the rule that big tech companies don't use DNSSEC; they do, of course, because it's part of the product they sell.
For example, a common argument is that DNSSEC is controlled by world governments, as if certificate authorities and domain registries are free-standing entities separate from the countries they’re based in.
Many of these folks are actually misinformed, but there are quite a few who are clearly disingenuous about how DNSSEC works.
Let's clear this up: DNSSEC creates a chain of trust, from the root zone (the “.” at the top of the domain hierarchy) to your zone, such as example.com.
The chain is
. --> com --> example.com
The DNSSEC trust chain is far more constrained and you get to create the KSK and zone signing keys (ZSK) for your zone.
Root Key Signing Key (KSK) is the public key of the key pair that’s for the root zone. The private key of this key pair is used to sign the top-level domains such as .com, .net, .org, etc.
The root KSK ships with all of the DNSSEC-supporting DNS resolvers and enables them to verify the authenticity of the trust chain.
It’s not clear what the paranoia is about; the public KSK is public; it’s referenced on thousands of websites and everyone involved with running the global internet knows about it. [1]
If something malicious or nefarious were to happen, all registries, regional internet operators, ISPs, etc. would immediately know about it.
All of the DNS resolvers that support DNSSEC have a built-in way to automatically upgrade to a new KSK when it’s released [2]. Even if you imagine the world’s governments colluding to change the key for whatever nefarious reason, DNS resolvers know not to trust any new key unless it’s been available for 30 days.
(The new key would need to be signed by the old key anyway, but for the sake of arguement, lets pretend that’s not neccessary.)
What those people neglect to mention is you’re not required to trust the root KSK. You can decide where your chain of trust starts if you wish, including only trusting your own zone. You can also create islands of trust, zones or domains you feel comfortable with.
Anyway, you can read rational, fact-based responses to these and other DNSSEC falsehoods. [3]
[1]: https://www.iana.org/domains/root
Even if don't use Cloudflare (or Google Cloud, which also supports DNSSEC), signing your zone has gotten pretty easy.
All of the major authoritative DNS servers support automatic DNSSEC signing and automatic key rollover of the Key Signing Key (KSK) and Zone Signing Key (ZSK).
For example, here's the configuration for automatic DNSSEC signing for Knot DNS [1]:
zone:
- domain: myzone.test
dnssec-signing: on
Let me say just having SSHFP support thanks to DNSSEC turns using SSH from annoying to "it just works" [2] if you admin a server.
Setting up DNSSEC was difficult back in the day, but it’s pretty easy now.
[1]: https://www.knot-dns.cz/docs/2.9/html/configuration.html#aut...
[2]: https://weberblog.net/sshfp-authenticate-ssh-fingerprints-vi...
* You bring them up regularly without acknowledging that they're due in large part to European registrars that automatically sign new domains for their customers and hold the keys, which is security theater.
* The stats themselves are ludicrously misleading; for instance, they claim that 97% of .COM domains are signed despite listing only 1.5MM signed .COM domains, which is a tiny fraction of all of .COM (they are in reality listing the percentage of domains that have DNSSEC and properly validating signatures, and while it's amusing that something like 4% of DNSSEC domains don't even verifying, it's not evidence of adoption).
* The overwhelming majority of these domains don't matter at all, and a quick check of the lists of popular domains, from Alexa or the Moz 500, shows that virtually none of the popular domains outside the USG (where DNSSEC was formerly but is no longer required) are signed.
You can keep bringing this up, but all you're doing is giving me opportunities to put more facts about the failure of DNSSEC on the table, which is something I'm not actually all that committed to doing.