The logical extension of this line of thinking is that the tech community should never provide any extra security to anyone, in case somewhere some malicious actor is angered into retaliating against a certain group of users.
If you think that there are companies that rely on surveilling DNS requests (but don't already intercept and decrypt all their employee's web traffic) then you can campaign for browsers and OSes to have an option to turn off new security features like DNS-over-HTTPS/TLS and Encrypted SNI, but please don't demand that the whole internet go without these basic protections because of the internal policies of a few corporations.
The logical extension would not be "there should be no security features", and this is obvious, because the whole problem was not the existence of security features. The problem was the lack of ability to enforce policies, which organizations (companies, governments) are often required to do. I think the logical extension should be that security features should be developed with policy enforcement capabilities in mind.
Also, it's not logical to conflate this privacy feature with security features. Secure connections do not require SNI hiding at all. DNS-over-HTTPS is closer to a security feature, because without enabling DNSSEC, exploits are possible to the DNS which can impact non-TLS connections. That has a much easier workaround, which is to point DNS-over-HTTPS to a local provider.
There's no "quiet" in this approach. The cert vendors do not have the certificate's private keys; all the server operators send to the cert vendors is the certificate's public keys. Therefore, the only way to listen on the secured connections through a cert vendor is to use the cert vendor's private keys to sign a counterfeit certificate, which is presented to the browser. And at this point, the browser has everything it needs to prove that the cert vendor was compromised.
There are also several other gotchas: Certificate Transparency can force them to publish their counterfeit certificates to the whole world; Extended Validation is allowed only from some cert vendors (and requires Certificate Transparency); and last but not least, this (like all MITM) breaks client authentication (client certificates).
Finally, this only applies to cert vendors under the USA jurisdiction. A NSL has no power over other countries.
And as you say, browsers today might not check these things (and checking CAA doesn't make much sense for a browser, it's intended to be checked by certificate issuers). But future browsers, browsers customized with some third-party extensions, or non-browsers might check.
Browsers don't and can't check CAA records, because that's not how CAA is supposed to work. CAA is only enforced at the time of issuance. If you temporarily switch your CAA records to allow issuance for an hour, issue a cert, then switch them back to block all issuance from all CAs, the cert you issued remains valid.
[1]: https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=506227
You should correct it into _national_ agencies for non-authoritarian governments. Unitary states are majority in the world.
Every corporation which does SNI scanning for web
filtering will require every user to insert the
company's CA cert in every client they use.
It doesn't prevent domain fronting, of course, but neither did SNI scanning.
All that encryption will lead to people using VPNs en masse. This will lead to laws, directly prohibiting VPN usage except for explicitly granted permissions for selected businesses. This will lead to Internet segmentation, Russian Internet, China Internet, etc, world wide web will cease to exist.
Kazakhstan attempted [1], but abandoned the idea, likely since it was unrealistic to expect widespread adoption of the certificate.
And eventually, it'll probably make it infeasible in China/Russia. Especially, as the population becomes more technology literate.
...ah, and that would break anything using cert pinning.
HTTPS feels so utterly clunky.
Or when the domain uses HPKP to pin its certificate to a different CA. When the MITM CA has been added manually to the browser's root key store, most browsers allow HPKP bypass by that CA unless configured otherwise; but if the MITM is done by compromising one of the browser's default CAs, the browser won't allow a bypass.
Or if the certificate was supposed to be an EV certificate, which can only be issued by a limited number of CAs, and the compromised CA is not one of these. And even if an EV CA is compromised, AFAIK some browsers require the certificate to be in a Certificate Transparency log, and they also require that the certificate carry proof of its submission to the CT logs.
Corporations and governments have to balance the costs and the benefits of breaking encryption. The costs have increased, which increases the chance that they decide that the costs outweigh any perceived benefits.
That's not the case at all, and a very dangerous idea. Some steps drive increased centralization. Increased centralization makes interception and filtering easier.
The better solution is to push domain authentication to after the secure channel is established. That doesn't protect against active MITM snoopers, but neither does TLS ESNI. Worse, TLS ESNI will drive people to use centralized DNS-over-TLS service providers.
Mozilla+Cloudflare's "free" DNS service barely made it out of the gate before it was hijacked by the Great Firewall (not even simply blocked). See https://borncity.com/win/2018/05/30/cloudflare-dns-service-1... and https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
Of course, with DNS-over-TLS you would know (maybe) that there was a MITM. But that's no different than DNSSEC. And there's nothing you could do about it, anyhow.
Securing DNS, and specifically keeping DNS queries private, is NOT a solved problem. Indeed, it's not even a solvable problem because of the nature of DNS--the need to centrally coordinate registration of human readable identifiers. The only real "solution" is anonymization via techniques like onion routing (e.g. Tor), which anonymizes the requester, not the responder.
Advocates will tell you that TLS ESNI improves requester anonymity by aggregating users behind "trusted" intermediate resolvers, but that's largely based on conjecture and very little evidence--in particular without any showing that usage patterns won't naturally reconfigure to either return everybody to the status quo ante, or make everybody worse off on average.
TLS ESNI is a wild goose chase and, looking back 10 years from now, will have simply served to increase the complexity of the web stack and decrease service and software diversity.
Every corporation which does SNI scanning for web filtering will require every user to insert the company's CA cert in every client they use. This then also forces them to make a choice between requiring all apps in all networks to do this, or whitelist certain parts of the network. Not only does this reduce their security, but it limits how apps can work on their networks.
Authoritarian governments will also start requiring this. I could even see federal agencies for non-authoritarian governments making a stink over it on law enforcement grounds. They already hate encryption. If they can't force you to expose what sites you are visiting, they may force new legislation to require all web service providers to provide logs to law enforcement, which is a much worse privacy violation than just seeing what domain you were hitting.
I think the better solution to this would have been to improve server-side support for VPNs and Tor. Tech does not exist in a bubble, and rights can be taken away when they conflict with the interests of authority.