3 ms·
As far as I can tell, DNS-based authentication puts all the trust eggs in the DNS root basket, and then again, in the TLD basket. This seems incredibly brittle
by ShroudedNight 4y ago
As far as I can tell, DNS-based authentication puts all the trust eggs in the DNS root basket, and then again, in the TLD basket. This seems incredibly brittle and fraught with peril. Am I missing something?
- bawolff 4y agoThe usual counter-argument for https, is that the eggs are already in that basket since anyone with control of dns can just get a new certificate. For ssh that doesn't really apply as clearly though.
- xurukefi 4y ago> For ssh that doesn't really apply as clearly though. Do you think that DNS-based proof of ownership is not something that CAs would use for SSH certification?
- mjg59 4y agoGetting a cert requires someone to either compromise the primary DNS server for the domain, or to compromise DNS in multiple independent locations to serve consistent false answers to the probes. It's true that much of the TLS ecosystem is somewhat bound to DNS being trustworthy, but not to the same extent that SSHFP is.
- lozenge 4y agoThat also shows up on Certificate Transparency logs.
- dane-pgp 4y agoPeople used HTTPS before there were Certificate Transparency logs, so there's no reason why those couldn't be run for DNSSEC too. https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-dnssec-03 https://datatracker.ietf.org/doc/html/draft-zhang-trans-ct-d... https://www.huque.com/2014/07/30/dnssec-key-trans.html https://www.huque.com/2014/07/30/dnssec-key-trans.html https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-delegation-only-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-deleg...
- jwilk 4y ago> or to compromise DNS in multiple independent locations to serve consistent false answers to the probes Do all CAs implement multi-prespective validation these days? Let's Encrypt implemented that only in 2020 and they believed they were the first ones: https://letsencrypt.org/2020/02/19/multi-perspective-validation.html https://letsencrypt.org/2020/02/19/multi-perspective-validat...
- rakoo 4y agoThe issue with DANE is that now the DNS becomes a new point of failure, which means higher attention to details, more scrutiny, heavier and more secure processes for the root signing ceremonies that require more activity. It recentralizes everything and makes "failing" easier.
- teddyh 4y agoThe CA system is just multiple points of failure instead of one. One is better.
- rakoo 4y agoNo, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
- teddyh 4y agoSo? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.
- rakoo 4y agoDNSSEC relies on a hierarchy of trust, with a single root zone at the top. If the root zone has issues, the whole system breaks down. In contrast, there is no unique "root CA" that can fail.
- teddyh 4y agoIf one CA fails, it can still issue certificates for all domains. You can’t avoid any bad CA by using a good CA; any other bad CA can still issue certs for your domains. The CA system as a whole can only ever be as good as its worst CA.
- bawolff 4y agoA CA can sign for any site. I'd say a single CA compromise breaks the entire system until it is revoked. DNS root key compromise breaks the entire system until it is replaced. Not seeing a huge difference.
- midasuni 4y agoHow do you authenticate the certificate issuing? Public CAs tend to use DNS (either host or dns txt records) to authenticate.
- ShroudedNight 4y agoRight now, probably domain validation. But with the TLS infrastructure, if domain validation ends up in disrepute, or if a CA screws around, we can revoke our trust on a subset without needing to replace the system wholesale.
- deleted 4y ago[deleted]