18 ms·

Some bad news for DANE and DNSSEC

81 points by okket 7y ago

theamk 7y ago
> The efforts of the CAB Forum to instil some level of additional trust in the system appear to be about as effective as sticking one’s fingers into a leaking dam. The number of trusted CAs has extended conventional credibility well beyond the normal boundaries and has pushed the unsuspecting user into a fragile state of credulity. > Efforts to improve this mess, such as Extended Validation (EV) certificates, have gained no traction with users, as they are largely immune to subtle changes in the content and colours of the browser’s navigation bars, and certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. That’s a pretty extreme opinion. I am surprised it appeared on official apnic.net site. I do wonder if it has anything to do with the fact that most major browsers, who actually decide who get to be CA, are US based.
- rschoultz 7y ago
  I don't think Geoff Huston argued for more CAs or a different distribution. His view is, in my experience, shared by many, regardless of nationality, though not as vocal. There are simply too many examples of compromised CAs, and the webpki system makes anyone vulnerable to the weakest of them.
  - theamk 7y ago
    Are compromised CAs worse than other software bugs though? Yes, we have too many CAs, and some of them are pretty suspicious. It would be great to be able to give them TLD limits. But becoming a CA is still very slow and expensive, and certificate transparency will catch bad behavior. So there is a very strong incentive for each CA to be good. Compare this to random server exploit, which is deployed anonymously and has no direct monetary harm to the maker company. No wonder there has been very few cases of CA-based compromise compared to good old software exploits.
  - snowwrestler 7y ago
    I find it hard to square the paranoia about CAs with the imposed death penalty on Symantec's certificate business. If no one is watching the CA's, how did Symantec get caught and punished? And for what seemed like relatively minor infractions? I think its possible that the average web developer underestimates the degree to which the web PKI is monitored by private and government organizations. And public cert logging only makes that easier.
  - cryptonector 7y ago
    "More CAs" == worse. I don't know what "different distribution" means. Anything that doesn't have a strong hierarchical binding to the names users understand (domainnames) is simply not going to have better security than WebPKI.
- throwaway2048 7y ago
  Its hardly extreme, your browser quite literally trusts hundreds of CAs. How much do you trust: GUANG DONG CERTIFICATE AUTHORITY Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK Unizeto Sp. z o.o. XRamp Security Services Inc [1] AC RAIZ FNMT-RCM etc, To have not been compromised, or selectively delivering certs to "interesting" targets. Because they can tell you practically any host on the internet is a valid SSL domain. Stuff like DNS CAA records, and certificate transparency help somewhat, but are either trivially stripped by MITM attacks or not implemented at the CA or software level. [1] Appears to have went out of business entirely, how safe is that SSL cert now?
  - tptacek 7y ago
    As Adam Langley has observed, fully implementing DANE doesn't get rid of these "hundreds of CAs", but rather adds a hundredsth-and-first --- the DNS hierarchy. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Meanwhile, CT has done more to protect the Web PKI in a couple years than DNSSEC ever has, and without forklifting out infrastructure. In fact, if rumors are true and at least some of the CA misissuance was detected due to broken pins, you can say the same thing about HTTP certificate pinning, and that technology wasn't even successful.
    - peterwwillis 7y ago
      Doing anything to detect or prevent cert mis-issuance would have resulted in better outcomes, because DNSSEC has nothing to do with HTTPS. All the previous attempts were lame, optional hacks that had obvious workarounds. I keep repeating the following and people ignore it, but it's a guaranteed way to stop mis-issuance cold - not detect it after a few hours, not make it less likely when a domain and website opt to jump through five separate hoops. The registrar should coordinate between domain owners and certificate authorities to provide a second factor, second party, cryptographic verification of the intent to issue a cert. Rather than say "ok, this organization says who owns this domain", and then "ok, this other organization controls who can make domain certs", you actually validate the second thing based on the first thing. A hacker can control a domain, but that doesn't mean they own it, or that they control the private key(s) used to purchase or transfer the domain. And you can automate this a dozen different ways for large organizations, it's not difficult. The difficult part is getting the registrars, CAs, and browsers to accept it.
- cryptonector 7y ago
  DNSSEC is the only true PKI we have. It has one set of roots and is workable even if we have competing roots, provided they sign roughly the same TLDs. The DNSSEC PKI is also truly hierarchical, while the WebPKI is absolutely not. The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users cannot understand x.500 naming. So the web absolutely needs a reliable way to authenticate domainnames. WebPKI is not reliable, no way, not even with CT. That leaves DNSSEC as the only remaining alternative. It's DNSSEC or WebPKI, and WebPKI is no good. So it's DNSSEC or nothing.
  - jcranmer 7y ago
    > The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users don't actually understand domain names. If Google were to make the result of searching for "facebook" return a facebook.google.com that MITM'd Facebook, they could capture ¼-⅓ of Facebook's traffic without any software complaining about it. Your comments have a strong sense of "if we just made sure that the server is truly using the domain name, then everything would be hunky-dory." In fact, as far as I can tell from actual security problems, fully securing the domain name (or even authenticating the server properly in the first place) wouldn't improve security meaningfully for most people.
    - comex 7y ago
      By your logic, why use HTTPS in the first place? (Or at least why care about certificate validation at all?) Hint: Because ISPs are in a position to intercept and even MitM traffic, but generally not in a position to decide what URLs you go to.
      - tialaramex 7y ago
        Only what is possible can be done. We have the technology to actually ensure that https://news.ycombinator.com/ https://news.ycombinator.com/ is really https://news.ycombinator.com/ https://news.ycombinator.com/ but we do not have technology that could ensure this is where you get when you type "Hacker News" into Bing. Part of what has to happen to civilisations around technology is that they adjust to what is possible. Different adjustments are possible, the egg washing thing is an example: in some countries you purchase eggs in the state they're laid (which means sometimes there is dirt on the shell), and you don't keep them in a refrigerator; in other countries you purchase eggs "washed" clean and they're refrigerated. Either of these approaches works fine, but mixing them up doesn't work. So, for example, teaching people to bookmark sites is an adjustment that works with our technology, whereas teaching them to get everywhere by following sponsored links on Google not so much. WebAuthn is another example. A Security Key doesn't care that you thought mybnak.example was your bank, doesn't care if you got there from a phishing email, from a bogus advert or you just can't spell when typing. It will resolutely refuse to provide mybnak.example with your mybank.example credentials because those strings are not the same. You can press the button over and over, swear, throw things, but because it's based on the URL it won't let you screw yourself.
skywhopper 7y ago
Not sure I see how making easily-hijackable DNS the authority for TLS certificate trust would solve these problems. In fact, I would expect that would make it worse, by putting all your eggs into one basket.
- amluto 7y ago
  It’s already the authority for TLS trust. How do you think domain validation works?
  - icedchai 7y ago
    Yep. Let's just cut out the middlemen already.
ryacko 7y ago
Any change in how PKI is used in a browser must be done by browser vendors, no change has been their decision. The idea spread that TLS should be used after Snowden is a bizarre antipattern. HTTP cache appliances have been rendered obsolete, and domain-validated certificates only provide assurances that you are connecting to the same server that LetsEncrypt had connected to.
tptacek 7y ago
This is a long and interesting summary of a DNS operations research workshop. The "bad news" bit is just one part of it. The "bad news" here is that the TLS dnssec-chain-extension was dropped by tls-wg. Chain-extension staples DNSSEC records to TLS handshakes, so that you don't need to do extra DNS lookups to get them. This is important because a pretty big fraction of Internet users are on networks that can't reliably look up DNSSEC records using the actual DNS protocol. If you're hungry for the details (of course you are!), I believe they can be summed up as follows: 1. The point of dnssec-chain-extension is to enable browsers to use DANE, either as an alternative or an enhancement to the X.509 CA hierarchy. 2. That means the threat model for dnssec-chain-extension has to include attackers with valid certificates; define them out of the threat model and you've defined DANE out of having a point. 3. An attacker with a valid certificate can strip dnssec-chain-extension out of a TLS handshake. 4. So they had to reinvent certificate pinning to make dnssec-chain-extension make sense. 5. But certificate pinning is already a dead letter as a browser standard, because of operational concerns around abuse and also consequences of misconfiguration. If you're just here for another dose of my DNSSEC snark, I will observe for you this: Geoff Huston, a giant in the Internet/DNS operations research community, concedes in this post that DANE is the whole "reason DNSSEC is worth the effort". He also believes that dnssec-chain-extension was vital to getting it deployed in browsers (I'm skeptical Google, Microsoft, or Apple were going to dip their toes in this swamp-water again, but whatever). And Huston apparently didn't notice until today that the tls-wg killed this draft last year. If you're keeping score, the DNSSEC "stick-a-fork-in-it-ometer" is currently registering: * The elimination of DNSSEC from macOS, Mozilla, and Chrome (in that last case accompanied by a statement about why the team doesn't believe DANE is workable). * The success of DNS-over-TLS and DNS-over-HTTPS, both of which accomplish 96% of the bottom-up, fuck-DNSSEC goals of DNSCrypt (or whatever it was Dan Bernstein called it). * The success of Certificate Transparency and, more broadly, Google's success at cracking down on CAs and getting CT deployed, which further deflates the impetus for DANE. * LetsEncrypt (and, I guess, Amazon's Certificate Manager), which took money out of this whole contest (I don't think money was ever the big deal in the real world that IETF people thought it was, but it sure drove a lot of dumb mailing list posts). * MTA-STS, the SMTP strict transport security system that locks down TLS between MTAs, which was standardized by all the major email providers, specifically (stated in the draft!) to avoid the need for DNSSEC, and which is now being rolled out at GMail. * And now I guess we'll pretend that DANE in browsers was somehow on the table and that it just died. I'm just happy we agree it's not happening. I don't think I'm quite ready to stick a fork in it, but it's getting close. My favorite detail from this writeup, by the way, is the fact that Sweden and the Netherlands got their DNSSEC adoption by paying people to use the protocol.
cjbprime 7y ago
> certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. In what sense is this true? They're effective because browsers only accept certs which can first prove that they were submitted to a CT log, and it's easy to search the CT logs for e.g. gmail.com to find potential misissuance events. This is the first time I've heard CT described as ineffective. What gives?
- tptacek 7y ago
  Huston has re-set the bar at "real-time", and implies that DANE would provide such real-time assurance, when in fact even DANE advocates acknowledge that, were DANE to see wide use, we'd need to develop a DANE equivalent of CT.
  - cjbprime 7y ago
    I guess I don't even buy that CT is ineffective in real-time. If attacks don't happen because of the knowledge that misissuance would necessarily be publicly noticed and then severely punished, then it seems your users have been protected against real-time attacks, even if that's an emergent social phenomenon rather than a protocol guarantee.
- agwa 7y ago
  It's unclear what Huston means by "real time", but in the comments section he cites the fact that it took 6 months for the misissued Symantec certificates for example.com to be noticed. That's because the owner of example.com wasn't monitoring CT. Had they been monitoring, they would have been alerted quite quickly. As a case in point, when Certinomis misissued a certificate for test.com, my monitor notified me 16 minutes after issuance, I filed a report with Mozilla two hours after issuance, and a representative of Mozilla responded less than 3.5 hours after issuance.[1] That's pretty fast. And now Mozilla is kicking Certinomis out, providing yet another example of how CT is improving the Web PKI. CT works. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 https://bugzilla.mozilla.org/show_bug.cgi?id=1496088
  - 7y ago

81 points by okket 7y ago

> The efforts of the CAB Forum to instil some level of additional trust in the system appear to be about as effective as sticking one’s fingers into a leaking dam. The number of trusted CAs has extended conventional credibility well beyond the normal boundaries and has pushed the unsuspecting user into a fragile state of credulity. > Efforts to improve this mess, such as Extended Validation (EV) certificates, have gained no traction with users, as they are largely immune to subtle changes in the content and colours of the browser’s navigation bars, and certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. That’s a pretty extreme opinion. I am surprised it appeared on official apnic.net site. I do wonder if it has anything to do with the fact that most major browsers, who actually decide who get to be CA, are US based.

rschoultz 7y ago
I don't think Geoff Huston argued for more CAs or a different distribution. His view is, in my experience, shared by many, regardless of nationality, though not as vocal. There are simply too many examples of compromised CAs, and the webpki system makes anyone vulnerable to the weakest of them.
- theamk 7y ago
  Are compromised CAs worse than other software bugs though? Yes, we have too many CAs, and some of them are pretty suspicious. It would be great to be able to give them TLD limits. But becoming a CA is still very slow and expensive, and certificate transparency will catch bad behavior. So there is a very strong incentive for each CA to be good. Compare this to random server exploit, which is deployed anonymously and has no direct monetary harm to the maker company. No wonder there has been very few cases of CA-based compromise compared to good old software exploits.
- snowwrestler 7y ago
  I find it hard to square the paranoia about CAs with the imposed death penalty on Symantec's certificate business. If no one is watching the CA's, how did Symantec get caught and punished? And for what seemed like relatively minor infractions? I think its possible that the average web developer underestimates the degree to which the web PKI is monitored by private and government organizations. And public cert logging only makes that easier.
- cryptonector 7y ago
  "More CAs" == worse. I don't know what "different distribution" means. Anything that doesn't have a strong hierarchical binding to the names users understand (domainnames) is simply not going to have better security than WebPKI.
throwaway2048 7y ago
Its hardly extreme, your browser quite literally trusts hundreds of CAs. How much do you trust: GUANG DONG CERTIFICATE AUTHORITY Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK Unizeto Sp. z o.o. XRamp Security Services Inc [1] AC RAIZ FNMT-RCM etc, To have not been compromised, or selectively delivering certs to "interesting" targets. Because they can tell you practically any host on the internet is a valid SSL domain. Stuff like DNS CAA records, and certificate transparency help somewhat, but are either trivially stripped by MITM attacks or not implemented at the CA or software level. [1] Appears to have went out of business entirely, how safe is that SSL cert now?
- tptacek 7y ago
  As Adam Langley has observed, fully implementing DANE doesn't get rid of these "hundreds of CAs", but rather adds a hundredsth-and-first --- the DNS hierarchy. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Meanwhile, CT has done more to protect the Web PKI in a couple years than DNSSEC ever has, and without forklifting out infrastructure. In fact, if rumors are true and at least some of the CA misissuance was detected due to broken pins, you can say the same thing about HTTP certificate pinning, and that technology wasn't even successful.
  - peterwwillis 7y ago
    Doing anything to detect or prevent cert mis-issuance would have resulted in better outcomes, because DNSSEC has nothing to do with HTTPS. All the previous attempts were lame, optional hacks that had obvious workarounds. I keep repeating the following and people ignore it, but it's a guaranteed way to stop mis-issuance cold - not detect it after a few hours, not make it less likely when a domain and website opt to jump through five separate hoops. The registrar should coordinate between domain owners and certificate authorities to provide a second factor, second party, cryptographic verification of the intent to issue a cert. Rather than say "ok, this organization says who owns this domain", and then "ok, this other organization controls who can make domain certs", you actually validate the second thing based on the first thing. A hacker can control a domain, but that doesn't mean they own it, or that they control the private key(s) used to purchase or transfer the domain. And you can automate this a dozen different ways for large organizations, it's not difficult. The difficult part is getting the registrars, CAs, and browsers to accept it.
cryptonector 7y ago
DNSSEC is the only true PKI we have. It has one set of roots and is workable even if we have competing roots, provided they sign roughly the same TLDs. The DNSSEC PKI is also truly hierarchical, while the WebPKI is absolutely not. The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users cannot understand x.500 naming. So the web absolutely needs a reliable way to authenticate domainnames. WebPKI is not reliable, no way, not even with CT. That leaves DNSSEC as the only remaining alternative. It's DNSSEC or WebPKI, and WebPKI is no good. So it's DNSSEC or nothing.
- jcranmer 7y ago
  > The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users don't actually understand domain names. If Google were to make the result of searching for "facebook" return a facebook.google.com that MITM'd Facebook, they could capture ¼-⅓ of Facebook's traffic without any software complaining about it. Your comments have a strong sense of "if we just made sure that the server is truly using the domain name, then everything would be hunky-dory." In fact, as far as I can tell from actual security problems, fully securing the domain name (or even authenticating the server properly in the first place) wouldn't improve security meaningfully for most people.
  - comex 7y ago
    By your logic, why use HTTPS in the first place? (Or at least why care about certificate validation at all?) Hint: Because ISPs are in a position to intercept and even MitM traffic, but generally not in a position to decide what URLs you go to.
    - tialaramex 7y ago
      Only what is possible can be done. We have the technology to actually ensure that https://news.ycombinator.com/ https://news.ycombinator.com/ is really https://news.ycombinator.com/ https://news.ycombinator.com/ but we do not have technology that could ensure this is where you get when you type "Hacker News" into Bing. Part of what has to happen to civilisations around technology is that they adjust to what is possible. Different adjustments are possible, the egg washing thing is an example: in some countries you purchase eggs in the state they're laid (which means sometimes there is dirt on the shell), and you don't keep them in a refrigerator; in other countries you purchase eggs "washed" clean and they're refrigerated. Either of these approaches works fine, but mixing them up doesn't work. So, for example, teaching people to bookmark sites is an adjustment that works with our technology, whereas teaching them to get everywhere by following sponsored links on Google not so much. WebAuthn is another example. A Security Key doesn't care that you thought mybnak.example was your bank, doesn't care if you got there from a phishing email, from a bogus advert or you just can't spell when typing. It will resolutely refuse to provide mybnak.example with your mybank.example credentials because those strings are not the same. You can press the button over and over, swear, throw things, but because it's based on the URL it won't let you screw yourself.

skywhopper 7y ago

Not sure I see how making easily-hijackable DNS the authority for TLS certificate trust would solve these problems. In fact, I would expect that would make it worse, by putting all your eggs into one basket.

amluto 7y ago
It’s already the authority for TLS trust. How do you think domain validation works?
- icedchai 7y ago
  Yep. Let's just cut out the middlemen already.

ryacko 7y ago

Any change in how PKI is used in a browser must be done by browser vendors, no change has been their decision. The idea spread that TLS should be used after Snowden is a bizarre antipattern. HTTP cache appliances have been rendered obsolete, and domain-validated certificates only provide assurances that you are connecting to the same server that LetsEncrypt had connected to.

tptacek 7y ago

This is a long and interesting summary of a DNS operations research workshop. The "bad news" bit is just one part of it. The "bad news" here is that the TLS dnssec-chain-extension was dropped by tls-wg. Chain-extension staples DNSSEC records to TLS handshakes, so that you don't need to do extra DNS lookups to get them. This is important because a pretty big fraction of Internet users are on networks that can't reliably look up DNSSEC records using the actual DNS protocol. If you're hungry for the details (of course you are!), I believe they can be summed up as follows: 1. The point of dnssec-chain-extension is to enable browsers to use DANE, either as an alternative or an enhancement to the X.509 CA hierarchy. 2. That means the threat model for dnssec-chain-extension has to include attackers with valid certificates; define them out of the threat model and you've defined DANE out of having a point. 3. An attacker with a valid certificate can strip dnssec-chain-extension out of a TLS handshake. 4. So they had to reinvent certificate pinning to make dnssec-chain-extension make sense. 5. But certificate pinning is already a dead letter as a browser standard, because of operational concerns around abuse and also consequences of misconfiguration. If you're just here for another dose of my DNSSEC snark, I will observe for you this: Geoff Huston, a giant in the Internet/DNS operations research community, concedes in this post that DANE is the whole "reason DNSSEC is worth the effort". He also believes that dnssec-chain-extension was vital to getting it deployed in browsers (I'm skeptical Google, Microsoft, or Apple were going to dip their toes in this swamp-water again, but whatever). And Huston apparently didn't notice until today that the tls-wg killed this draft last year. If you're keeping score, the DNSSEC "stick-a-fork-in-it-ometer" is currently registering: * The elimination of DNSSEC from macOS, Mozilla, and Chrome (in that last case accompanied by a statement about why the team doesn't believe DANE is workable). * The success of DNS-over-TLS and DNS-over-HTTPS, both of which accomplish 96% of the bottom-up, fuck-DNSSEC goals of DNSCrypt (or whatever it was Dan Bernstein called it). * The success of Certificate Transparency and, more broadly, Google's success at cracking down on CAs and getting CT deployed, which further deflates the impetus for DANE. * LetsEncrypt (and, I guess, Amazon's Certificate Manager), which took money out of this whole contest (I don't think money was ever the big deal in the real world that IETF people thought it was, but it sure drove a lot of dumb mailing list posts). * MTA-STS, the SMTP strict transport security system that locks down TLS between MTAs, which was standardized by all the major email providers, specifically (stated in the draft!) to avoid the need for DNSSEC, and which is now being rolled out at GMail. * And now I guess we'll pretend that DANE in browsers was somehow on the table and that it just died. I'm just happy we agree it's not happening. I don't think I'm quite ready to stick a fork in it, but it's getting close. My favorite detail from this writeup, by the way, is the fact that Sweden and the Netherlands got their DNSSEC adoption by paying people to use the protocol.

cjbprime 7y ago

> certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. In what sense is this true? They're effective because browsers only accept certs which can first prove that they were submitted to a CT log, and it's easy to search the CT logs for e.g. gmail.com to find potential misissuance events. This is the first time I've heard CT described as ineffective. What gives?

tptacek 7y ago
Huston has re-set the bar at "real-time", and implies that DANE would provide such real-time assurance, when in fact even DANE advocates acknowledge that, were DANE to see wide use, we'd need to develop a DANE equivalent of CT.
- cjbprime 7y ago
  I guess I don't even buy that CT is ineffective in real-time. If attacks don't happen because of the knowledge that misissuance would necessarily be publicly noticed and then severely punished, then it seems your users have been protected against real-time attacks, even if that's an emergent social phenomenon rather than a protocol guarantee.
agwa 7y ago
It's unclear what Huston means by "real time", but in the comments section he cites the fact that it took 6 months for the misissued Symantec certificates for example.com to be noticed. That's because the owner of example.com wasn't monitoring CT. Had they been monitoring, they would have been alerted quite quickly. As a case in point, when Certinomis misissued a certificate for test.com, my monitor notified me 16 minutes after issuance, I filed a report with Mozilla two hours after issuance, and a representative of Mozilla responded less than 3.5 hours after issuance.[1] That's pretty fast. And now Mozilla is kicking Certinomis out, providing yet another example of how CT is improving the Web PKI. CT works. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 https://bugzilla.mozilla.org/show_bug.cgi?id=1496088
- 7y ago