6 ms·

This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established i

This is such a nice and pragmatic solution. And yet for some reason people would rather prefer the CA madness we know in the HTTPS ecosystem to be established in the SSH world. I understand that DANE was ahead of its time which is why we settled with CAs for SSL certificates but can we please take a different route this time for SSH?

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 ago
  The 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 ago
    Getting 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 ago
      That also shows up on Certificate Transparency logs.
      - dane-pgp 4y ago
        People 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 ago
    The 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 ago
      The CA system is just multiple points of failure instead of one. One is better.
      - rakoo 4y ago
        No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
        teddyh 4y ago
        So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.
        rakoo 4y ago
        DNSSEC 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 ago
        If 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 ago
        A 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 ago
  How do you authenticate the certificate issuing? Public CAs tend to use DNS (either host or dns txt records) to authenticate.
  - ShroudedNight 4y ago
    Right 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]
Avamander 4y ago
I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.
- 8organicbits 4y ago
  The long part is well stated here: https://www.youtube.com/watch?v=UawS3_iuHoA https://www.youtube.com/watch?v=UawS3_iuHoA
- dane-pgp 4y ago
  Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them. A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.
  - Avamander 4y ago
    > A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary. This is bypassing a dangerous design, at best.
    - dane-pgp 4y ago
      > Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web. If a country decided to invalidate the security of (predominantly) its own citizens' websites then that wouldn't harm anyone who used any of the other ccTLDs in the world (not to mention the hundreds of gTLDs). Also, I think you are over-estimating the ease with which a CA can be "quickly mistrusted". What is the record for how quickly a CA has been taken out of browsers' certificate stores, measured from the time of their first misissuance? And I would argue that revoking CA trust to Let's Encrypt / IdenTrust would be much more disruptive than revoking a single ccTLD operator, since that would mean breaking most sites on the web. So DNSSEC is actually better in terms of the "too big to fail" problem. > This is bypassing a dangerous design, at best. But that's my point; DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you, and wait for the bureaucratic and software update processes to remove that CA from all your users' browsers. There are definitely limitations to the DNSSEC system as currently deployed, just as there were with the web PKI system before browsers started to patch all the holes in that, but I don't know why my position on this technical question is so controversial. Nevertheless, I really appreciate you taking the time to offer intelligent counter-arguments in your comment, thank you.

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 ago
The 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 ago
  Getting 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 ago
    That also shows up on Certificate Transparency logs.
    - dane-pgp 4y ago
      People 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 ago
  The 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 ago
    The CA system is just multiple points of failure instead of one. One is better.
    - rakoo 4y ago
      No, because if one CA is broken only the certificates it authored are vulnerable. It takes more to break the entire system.
      - teddyh 4y ago
        So? If an authoritative DNS server operator is broken, only the domains below that operator (in the DNS hierarchy) could be impacted.
        rakoo 4y ago
        DNSSEC 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 ago
        If 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 ago
        A 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 ago
How do you authenticate the certificate issuing? Public CAs tend to use DNS (either host or dns txt records) to authenticate.
- ShroudedNight 4y ago
  Right 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]

Avamander 4y ago

I'm going to skip the long part, but what you're basically requesting is that everyone must trust the countries operating their ccTLDs. Does that sound reasonable? I don't think so.

8organicbits 4y ago
The long part is well stated here: https://www.youtube.com/watch?v=UawS3_iuHoA https://www.youtube.com/watch?v=UawS3_iuHoA
dane-pgp 4y ago
Trusting the country that operates the ccTLD of your website is a much better situation than having to trust all the countries that have CAs operate in them. A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary.
- Avamander 4y ago
  > A malicious CA in one country can issue a fraudulent certificate for a site in another country, whereas the people operating .ru can't affect the records for example.us so the blast radius is limited by design. Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. > Moreover, no one is required to use a ccTLD, and there are hundreds of gTLDs to choose from, or you could even run one yourself if necessary. This is bypassing a dangerous design, at best.
  - dane-pgp 4y ago
    > Sure and they'll be quickly mistrusted. You can't really revoke DNNSEC trust of an ccTLD operator. But you don't have to, because the blast radius is so much smaller, and the incentives are aligned better. The reason why CAs require such extreme punishment for misbehaviour is that one bad CA can break the trust for every site on the web. If a country decided to invalidate the security of (predominantly) its own citizens' websites then that wouldn't harm anyone who used any of the other ccTLDs in the world (not to mention the hundreds of gTLDs). Also, I think you are over-estimating the ease with which a CA can be "quickly mistrusted". What is the record for how quickly a CA has been taken out of browsers' certificate stores, measured from the time of their first misissuance? And I would argue that revoking CA trust to Let's Encrypt / IdenTrust would be much more disruptive than revoking a single ccTLD operator, since that would mean breaking most sites on the web. So DNSSEC is actually better in terms of the "too big to fail" problem. > This is bypassing a dangerous design, at best. But that's my point; DNSSEC lets you bypass the danger of a rogue issuer, by swapping to an alternate domain in the worst case, whereas with CAs you have to hope that the rogue issuer doesn't decide to target you, and wait for the bureaucratic and software update processes to remove that CA from all your users' browsers. There are definitely limitations to the DNSSEC system as currently deployed, just as there were with the web PKI system before browsers started to patch all the holes in that, but I don't know why my position on this technical question is so controversial. Nevertheless, I really appreciate you taking the time to offer intelligent counter-arguments in your comment, thank you.