4 ms·
We could also be relying on DNSSEC+DANE, where the domain owner publishes TLS public keys via DNS. Without a third party CA. The main limitation right now is b
by WhyNotHugo 2y ago
We could also be relying on DNSSEC+DANE, where the domain owner publishes TLS public keys via DNS. Without a third party CA.
The main limitation right now is browser support. Browsers _only_ support CAs, so CAs continue being the norm.
- mycall 2y agoBrave should try an implementation as it fits their paradigm.
- lxgr 2y agoHow so?
- growse 2y agoWho do you think signs the DNSSEC root?
- cryptonector 2y agoThey can't be MITMing people left and right without getting caught. Maybe getting caught is not a problem, but still. And if you use query name minimization[0] then it gets harder for the root CA and any intermediates but the last one to decide whether to MITM you. And you can run your own root for your network. [0] QName minimization means if if you're asking for foo.bar.baz.example. you'll ask . for example. then you'll ask example. for baz.example. and so on, detecting all the zone cuts yourself. As opposed to sending the full foo.bar.baz.example. query to . then example. and so on. If you minimize the query then . doesn't get to know anything other than the TLD you're interested in, which is not much of a clue as to whether an evil . should MITM you. Now because most domainnames of interest have only one or two intermediate zones (a TLD or a ccTLD and one below that), and because those intermediates are also run by parties similar to the one that runs the root, you might still fear MITMing. But you can still use a combination of WebPKI and DANE, in which case the evil DNSSEC CAs would have to collaborate with some evil WebPKI CA. Ultimately though DNSSEC could use having CT.
- tptacek 2y agoThey can absolutely MITM people left and right without getting caught.
- dadrian 2y agoThe main limitation is the incredibly opaque and brittle nature of putting keys in DNS. We've spent a decade and a half slowly making the Web PKI more agile and more transparent by reducing key lifetimes, expanding automation support, and integrating certificate transparency. None of that exists for DNS, largely by design.
- Spivak 2y agoYou don't even need DNSSEC because CAs will happily issue you a cert without it.
- cryptonector 2y agoNote that DNSSEC is a PKI, but it's fantastically better than a WebPKI because a) you get a single root CA, b) you can run your own private root CA (by running your own `.`), c) if clients did QName miniminzation then the CAs wouldn't easily know when it's interesting to try to MITM you. Oh, and DNS has name constraints naturally built-in while PKIX only has them as an extension that no one implements. The only real downsides are that DNSSEC doesn't have CT yet (that'd be nice), this adds latency, and larger DNS messages can be annoying.
- tptacek 2y agoThe single root CA makes it fantastically worse, not better. DNSSEC will never get CT, because no entity in the world has the leverage to make that happen. The whole point of CT is that no WebPKI entity can opt out of it.
- jeroenhd 2y agoOutside of some European TLDs, DNSSEC is pretty much unused. Amazon's cloud DNS service only recently started supporting it and various companies trying to turn it on ran into bugs in Amazon's implementation and got painful downtime. Hell, there are even incompetent TLDs that have DNSSEC broken entirely with no plan for fixing it any time soon. Another problem with DNSSEC is that the root is controlled by the United States. If we start relying on DNSSEC, America gains the power to knock out entire TLDs by breaking the signature configuration. Recent credible threats of invading friendly countries should make even America's allies fearful for extending digital infrastructure in a way that gives them any more power.
- immibis 2y agoYour registrar would be able to MITM your website - and prevent you from noticing, since there's no Certificate Transparency in this case.