This CA system is designed for maximum reduction in security - not defense in depth. The company with the least security defines the security of the entire CA system.
It’s time for DANE [1]. We don’t need any more “men in the middle.”
I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here.
Agree with you, it's entirely incorrect that a CT log operator "defines the security of the entire CA system". They can't issue certs and their output is already regarded with suspicion by default.
> I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here.
I think this would be true except my statement wasn't just about SCT but the CA system in general. Furthermore, browsers like Firefox [1] do not even have CT checks.
Despite being supported, relying on browsers checking CT logs was never something that what going to be deployed at scale because, just like revocation lists, it adds a performance hurdle to every request.
Auditors and monitors are the real protection you get from CT logs.
You get the same problem with any form of DNS validation because you'll never get every little caching server to validate records.
Just so everyone's clear about this, Handshake is a system backed by a cryptocurrency, "HNS", that is actively traded despite being useful only to speculators. Its backers believe that they'll take over control of the Internet and be rewarded financially for it through their currency.
"Currently [2018], in more than 90% of cases if a user passes DNS queries to a resolver that performs DNSSEC validation of an RSA digital signature the same resolver will also perform DNSSEC validation of ECDSA P-256 digital signatures."
"Since the second quarter of 2019 [to the first quarter of 2020], the population of [strict DNSSEC] validating users has risen from 12% to 22%, close to doubling. At the same time, the proportion of [non-strict DNSSEC validating] users has risen from 5% to 10%."
A better argument against the preposterous claim that DNSSEC is "government-controlled" (and one that doesn't rely on blockchains, which are controversial in their own right), is that with DNSSEC you can choose which government (i.e. ccTLD) your domain is under, or choose one of the many generic TLDs.
The web PKI, by contrast, requires users to trust a bunch of CAs, any one of which could have been compromised by a government and can issue a certificate for your domain. Also, if a government can compromise your DNS records, they can also be granted domain-validated certificates for those domains, so the web PKI is not an improvement.
Anyway, if your threat model is that every single country in the world is willing to subvert the security of their own DNS hierarchy specifically to attack you, then the limitations of DNSSEC are the least of your worries.
With DNSSEC, when it becomes instantly clear that the United States Government controls .COM, Google can simply leave .COM, and tell every Google user in the United States never to use the tainted GOOGLE.COM domain, and all the users will stop using .COM and start using the new Google domain name, because that is how things work in the real world.
Yeah, imagine the hours of productivity that will be lost as people in the US update their link to Google in their IE6 "Favorites" list, because that's how things work in the real world.
In contrast, when it becomes clear that the United States Government controls multiple certificate authorities, that won't be a problem for any websites.
With the CT system I can monitor the CA's issuance, with DNSSEC I can't retroactively monitor if someone has changed the DANE keys and intercepted traffic.
True, DNSSEC Transparency is not as developed a technology as Certificate Transparency. There has been experimental deployment of such a system[0] but to give higher assurance there is a small addition to the DNS data that needs to be adopted first[1], which is still going through the IETF process.
It’s time for DANE [1]. We don’t need any more “men in the middle.”
[1] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...