3 ms·

Your point was already addressed: http://news.ycombinator.com/item?id=2960504 http://news.ycombinator.com/item?id=2960504.

by nbpoole 15y ago

kragen 15y ago
Thanks! I thought that post was silly, and it doesn't address my point. You'd do the same thing with a compromised .COM cert that you'd do with a compromised Verisign or Thawte cert, whatever that might be, because the vast majority of .COM sites are certified by one of those CAs already.
- tptacek 15y ago
  No, this is simply wrong. Individual resolvers do not get to decide whether to trust or not trust zone signatures. Signatures in DNSSEC inherently chain to the root. You are shackled to one trust hierarchy for all time. This is in stark contrast to X.509 CAs; the "300 central CA" model we have today is a mere browser configuration setting, and one virtually anyone can change.
  - kragen 15y ago
    (Rewritten to fix problem with clarity) The resolver software that ultimately makes the trust decision --- examining the RRSIG records in the response and deciding what to display or do as a result --- is running on computers under end-user control. If the end-user, or whoever maintains your browser or other software for them, decides that a particular key has probably been compromised and should not be trusted, no RFC can force their software to treat that key as valid simply because it has a valid DS from its parent zone. You can have a DNSSEC blacklist just as we have openssl-blacklist and openssh-blacklist. You can make your resolver do whatever you want. Now, this is considerably more work than clicking around your browser's Preferences UI to delete DigiNotar's keys, but it's not as if every user has to do it themself. However, I appreciate the information about what the DNSSEC quasi-standards say you should program your resolver to do.
    - tptacek 15y ago
      I can't understand what this comment is trying to say. Could you reword it? Thank you.
      - kragen 15y ago
        Yes, I've rewritten it. I'm sorry it was so unclear.
    - tptacek 15y ago
      Help me understand. In one corner, we have PKI protocol whose trust roots are configurable, so much so that every mainstream browser has point-and-click UI to change them. It so happens that this protocol is also the de facto standard with 15+ years of deployment history. In the other corner, we have a PKI protocol that, instead of providing configurable trust, hardcodes trust into DNS names. Instead making point-and-click configuration changes, to alter the PKI roots in this scheme you'd have to "violate" the standards of one of the core Internet protocols by building and deploying a noncompliant DNS resolver. Kragen, why on earth do you prefer the second solution to the first?
      - kragen 15y ago
        Two reasons. First, the existing PKI already hardcodes trust into DNS names. If Libya's registry decides vb.ly is immoral and should be redirected to a server serving up a placeholder page, Violet Blue can't make her site continue working. And they can almost certainly even obtain an X.509 certificate proving that they really do own vb.ly, so that you still get the placeholder page instead of a TLS error page even if you visit the site over https. Second, the existing PKI grants every CA power over the entire namespace, instead of merely over the names it was established to verify. That means I can't get my intranet site to authenticate properly without granting my company the authority to MITM every site in the world. As a result of this idiocy, recovering from trust root compromises seems to have gone from being a once-in-a-lifetime catastrophe to a yearly, even monthly catastrophe, to the point that intelligent people think it's important to have a point-and-click UI to recover from it.

Your point was already addressed: http://news.ycombinator.com/item?id=2960504 http://news.ycombinator.com/item?id=2960504.

by nbpoole 15y ago

Your point was already addressed: http://news.ycombinator.com/item?id=2960504 http://news.ycombinator.com/item?id=2960504.

kragen 15y ago

Thanks! I thought that post was silly, and it doesn't address my point. You'd do the same thing with a compromised .COM cert that you'd do with a compromised Verisign or Thawte cert, whatever that might be, because the vast majority of .COM sites are certified by one of those CAs already.

tptacek 15y ago
No, this is simply wrong. Individual resolvers do not get to decide whether to trust or not trust zone signatures. Signatures in DNSSEC inherently chain to the root. You are shackled to one trust hierarchy for all time. This is in stark contrast to X.509 CAs; the "300 central CA" model we have today is a mere browser configuration setting, and one virtually anyone can change.
- kragen 15y ago
  (Rewritten to fix problem with clarity) The resolver software that ultimately makes the trust decision --- examining the RRSIG records in the response and deciding what to display or do as a result --- is running on computers under end-user control. If the end-user, or whoever maintains your browser or other software for them, decides that a particular key has probably been compromised and should not be trusted, no RFC can force their software to treat that key as valid simply because it has a valid DS from its parent zone. You can have a DNSSEC blacklist just as we have openssl-blacklist and openssh-blacklist. You can make your resolver do whatever you want. Now, this is considerably more work than clicking around your browser's Preferences UI to delete DigiNotar's keys, but it's not as if every user has to do it themself. However, I appreciate the information about what the DNSSEC quasi-standards say you should program your resolver to do.
  - tptacek 15y ago
    I can't understand what this comment is trying to say. Could you reword it? Thank you.
    - kragen 15y ago
      Yes, I've rewritten it. I'm sorry it was so unclear.
  - tptacek 15y ago
    Help me understand. In one corner, we have PKI protocol whose trust roots are configurable, so much so that every mainstream browser has point-and-click UI to change them. It so happens that this protocol is also the de facto standard with 15+ years of deployment history. In the other corner, we have a PKI protocol that, instead of providing configurable trust, hardcodes trust into DNS names. Instead making point-and-click configuration changes, to alter the PKI roots in this scheme you'd have to "violate" the standards of one of the core Internet protocols by building and deploying a noncompliant DNS resolver. Kragen, why on earth do you prefer the second solution to the first?
    - kragen 15y ago
      Two reasons. First, the existing PKI already hardcodes trust into DNS names. If Libya's registry decides vb.ly is immoral and should be redirected to a server serving up a placeholder page, Violet Blue can't make her site continue working. And they can almost certainly even obtain an X.509 certificate proving that they really do own vb.ly, so that you still get the placeholder page instead of a TLS error page even if you visit the site over https. Second, the existing PKI grants every CA power over the entire namespace, instead of merely over the names it was established to verify. That means I can't get my intranet site to authenticate properly without granting my company the authority to MITM every site in the world. As a result of this idiocy, recovering from trust root compromises seems to have gone from being a once-in-a-lifetime catastrophe to a yearly, even monthly catastrophe, to the point that intelligent people think it's important to have a point-and-click UI to recover from it.