This is bullshit. Entrenching TLS in web standards is just handing the keys to the internet over to malicious government entities.
We need security without TLS.
We need security without TLS.
All I know is that centralized certificate authorities act as choke-points malicious governments can use to censor information.
DNSSEC is absolutely hierarchical and has strong name constraints. Today it has a single root run by ICANN, and run in such a way that hopefully the NSA and friends do not have access to the root key. Nothing stops other countries from legislating national alternative root zones, and nothing stops individuals from maintaining their own alternate root zones. We can expect eventually to see national alternate root zones, and we'll know that then that those states that impose them are almost certainly interested in being able to MITM. The ability to perform recursive lookups locally and use a root of one's choice will make MITMing more difficult.
DNSSEC, like WebPKI, is only as strong as the authentication of communications between domain owners/admins and CAs/registrars. With Let's Encrypt the WebPKI is quickly also becoming equally reliant on the security of communications between domain owners/admins and registrars anyways. There are efforts to improve that and reason to believe they'll succeed.
So at least as to non-nation-state actors, DANE is already more secure than the WebPKI.
QName minimization, and DNS privacy extensions (I wish the IETF would standardize DJB's solution for privacy), will make it very difficult for nation states with access to DNSSEC root zone keys to mount targeted MITM attacks. Non-targeted MITM attacks will be easier to notice than targeted ones.
In short, there's no silver bullet. The introduction problem is simply a very difficult one. But DANE looks to have better properties than WebPKI.
I wish that TLS 1.3 had mandated support for this going forward. Not just for public CAs, but also, I'd love to say "here is my company's internal CA root, only trust it for *.thecompany.example domains".
And protocols are typically stacked cleanly enough that it'd not be a big problem to replace TLS if another standard comes along to replace it.
[0] https://tools.ietf.org/html/rfc6698DANE definitely does not "work" for SMTP.
The necessity for DNSSEC in SMTP is, I think, a desperate trope† that recognizes that the Web PKI has moved past considering DANE and begun investing in direct hardening for the X.509 system. SMTP is other mainstream protocol for which transport security couldn't be guaranteed, is mired in the late 1990s technologically, and doesn't inherit modern browser- and server- based protection. So: SMTP! SMTP is the reason we need DNSSEC! We must get DNSSEC deployed immediately so everyone can have secure SMTP!
Except, you know who doesn't agree with you? The people who the most important email services. Hence: MTA-STS --- a standard whose introduction spells out its raison d'être: to avoid DANE! --- and the mooting of that last fragile argument for deploying DNSSEC.
DANE is a dead letter.
† I'm choosing words carefully
No, the major providers did not get together to do MTA-STS because DANE was bad. They did it because their existing DNS geo-balancing kit for e.g. google.com and yahoo.com does not offer an easy upgrade path to DNSSEC. Note that Microsoft has a dedicated domain (outlook.com) for email hosting, and can more easily do DNSSEC there without impacting their other "web properties". Note also that Google now MX-hosts many customer domains on "googlemail.com" rather than google.com.
So things are starting to change. Furthermore, there are now over 1 million DANE-enabled DNSSEC domains. MTA-STS is far behind, is not downgrade-resistant on first contact and uses weak CA-leap-of-faith DV authentication. It will probably be enabled at the biggest providers by the end of this year, but as you yourself said elsewhere, these providers are the threat, and if so, securing email delivery to the user surveillance empires is not necessarily that important. Mind you, they can play a useful role by enabling validation and helping to keep the TLSA records of receiving systems valid, and perhaps surveillance is not their business for paying customers...
There are a million DANE-enabled DNSSEC domains because there are registrars, particularly in Europe, that enable it automatically. Who cares? First of all, DNSSEC managed by your registrar is security theater, but, more importantly, the overwhelming majority of those domains do not matter. Who cares if some landing page in the Netherlands has TLSA records?
Meanwhile, the domains that really do matter --- the ones managed by the major mail providers --- are doing MTA-STS.
SMTP is not a success case for DNSSEC.
Recall: the argument you're responding to (you drew it up from downthread) is that DANE "definitely works for SMTP". Does it, now?
Yes, only ~9 to 10 million domains are presently signed, and most of the larger ones are not (but comcast.net and cloudflare.com are not tiny, and gmx.de has over 10 million email users). Changing this takes time and effort. Users still need better software tools that make deployment easier and there needs to be less KSK deployment and rollover friction at the registrars and registries (i.e. CDS support). Some DNS hosting providers with outdated software need to upgrade their stacks, ... this does not happen overnight. Let's compare notes in 2020 or 2021. Infrastructure upgrades happen slowly...
First of all, we have Certificate Transparency. This allows people to notice CA's behaving badly.
Secondly, we need certs to be signed by many different CA's. Note that this is just my idea, and I know of no intentions to standardize this. Currently, rescinding trust in a CA is a difficult and slow process. This is because rescinding a CA breaks a lot of infrastructure. If instead, certs were signed by multiple CA's, we could just drop a CA and most infrastructure should have signatures by other CAs.
Moreover, if I decided I don't trust the Hong Kong Post-office as a CA, I could drop them from my CA store without breaking the web. Perhaps I could even mark it as 'suspicious' and get notified when a cert is only signed by suspicious CAs.
By combing the two things, when a CA is compromised, Certificate Transparency should tell us about that in about a week, after which trust in that CA can be dropped almost immediately.
Just CT isn't enough. Consider what would happen if CT shows Lets-encrypt or DigiCert is compromised. We'd be forced to slowly drop trust, to allow many sites time to migrate away. Without the ability to drop a CA "like it's hot" Certificate transparency is toothless. It defends against CAs acting selfishly because getting caught by CT is bad for a CA. However, CT does not defend against coercion or compromise of CAs by third parties. Those third parties don't care whether the CA gets damaged. Under the current system they can get at least a month of signed certs for whatever domain they want.
Yes, you can, and yes, you should. Or are you saying you shouldn't file bug reports unless you can provide a patch?
Get real.
As opposed to cleartext, which hands your content over to everyone.
Also, certificate transparency means that it's going to be impossible for someone to MITM a TLS connection by forging a valid CA certificate for the domain without giant warning bells going off everywhere.
In the days before things like Certificate Transparency and HSTS preload lists, this was very worrysome because any of these governments could just freely impersonate any website they wanted to decrypt their access to. TLS is very vulnerable to this. SSH still has the TOFU model that is less vulnerable and TLS+TOFU is possible with HPKP but Chrome removed it. I can understand the reasons for the removal but it still had negative consequences. However, Google/Chrome is very avid about Certificate Transparency and many high-value domains are in the HSTS preload list with hardcoded CAs so we are in a better situation than just 5 years ago and I think it is going to improve going forward.
So no reason to discard TLS entirely with some kind of nirvana fallacy, but of course, being aware of the problems is always a good thing.
[1]: https://ccadb-public.secure.force.com/mozilla/IncludedCACert...
You don't need to specifically trust the CA that signs the certificate of your website: they don't get your private key or anything, only the public key which everyone is getting. Instead, you need to trust every single CA in the root zone.
That's at least the idea without certificate transparency (CT). The current SCT policy of Chrome for example increases [1, 2] the numbers of entities needed until a certificate is considered to be valid, and thus, any attack needs the cooperation of multiple such entities as well, making attacks harder to mount.
[1]: https://www.entrustdatacard.com/blog/2018/february/chrome-re...
The Turkish CA is constrained by Mozilla (and so in Firefox, but may not be constrained in your downstream software that wasn't written by Mozilla and just uses their trust lists wholesale) to just Turkish official sites, government, education, that sort of thing. The others are not subject to any notable constraints for a global CA.
If you don't run Firefox or a Free Unix you probably trust a lot more government CAs. For example Microsoft's list includes 35 root CAs from Australia to Uruguay. It's hard to do a cursory up-to-the-minute examination of Apple's status because they provide a summary of information from the certificate itself which will often have been written by some nerd twenty years ago, leading to descriptions like "Government Root Certification Authority" and "CA Root" (those are both real examples from Apple's actual list) which don't tell a reader anything of value.
I don't regard it as useful morally to try to count a company owned by the government as "the government". Consider the film production company Film 4. This is wholly owned by Channel 4, which is in turn wholly owned by the British government. So we could say the British government made "Four weddings and a funeral". OK, delightful English romantic comedy, sure, maybe drives tourism. "Trainspotting". Maybe it's a warning about how dangerous heroin is? "A Field In England" - Um, now we're struggling, I guess it is set in Britain at least. But wait, "The Motorcycle Diaries" is about the early life of Che Guevara, and "12 Years a Slave" is about a guy who was enslaved, in America. No, Film 4 is just a Film Prodution company, it happens to be owned by the British government, but that's even less relevant than which billionaire owns your favourite hockey team.