6 ms·

rant about DANE from tptacek incoming http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/ I don't have

by eloy 10y ago

rant about DANE from tptacek incoming http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/ I don't have a strong opinion on DNSSEC myself, but I agree with him that DANE is a bad replacement for standard TLS connections. DNSSEC is by far not the best security protocol ever designed, but it can protect to some threats, like cache poisoning.

tptacek 10y ago
Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN. Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.
- 0x0 10y ago
  But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
  - tptacek 10y ago
    First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
    - 0x0 10y ago
      Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
      - tptacek 10y ago
        Maybe we could actually fix the problem instead of just moving it around.
  - agwa 10y ago
    Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
    - Kadin 10y ago
      You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
      - tptacek 10y ago
        HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
      - agwa 10y ago
        The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
- garaetjjte 10y ago
  DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https) DNSSEC is a Government-Controlled PKI [...] Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it. DNSSEC is Incomplete [...] In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)" DNSSEC is Unsafe Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/) DNSSEC is Cryptographically Weak That's only point with I agree.
  - tptacek 10y ago
    Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.
  - icebraining 10y ago
    How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?
amalcon 10y ago
I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse. DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).

by eloy 10y ago

tptacek 10y ago

Honestly, while I do truly believe that DANE is an insane response to the Snowden disclosures that centralizes Internet trust and hands the keys over to the FVEY IC, that's not my biggest problem with DNSSEC. It's just the argument that I think has the strongest valence on HN. Most of that post isn't about NSA controlling the Internet. It's about what a mess DNSSEC is, and how little it does to protect anything on the Internet even in a universe where it's actually deployed.

0x0 10y ago
But in today's world where CAs issue certificates based on simple DNS A and MX record lookups for ownership verification, whoever controls the root zone or the relevant TLD zones can get "the keys" they want already.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- tptacek 10y ago
  First, nobody believes any part of the FVEY IC can't already get TLS certificates. DNS spoofing? They've already got CA=YES certificates. Second, DNSSEC doesn't even prevent this attack! All it does is attempt to protect name lookups. SMTP itself doesn't magically become secure just because there was a signature on an A record. Finally, we're already doing something that meaningfully blunts this attack. No matter how the CA system is compromised, browsers still monitor certificate pins. When pins break, the CA associated with the malicious certificate gets reported. When that happens, as we've seen repeatedly, the CA gets penalized --- or put out of business entirely. Public key pinning, CT, and surveillance is actually making a dent in the Internet trust problem. DNSSEC is a charade --- or, I think, something worse than that: you can't simply "revoke" .COM.
  - 0x0 10y ago
    Maybe we could 1. take away all the existing CA=YES certificates 2. stop using SMTP for domain verification, and issue the certificate at the same place that a domain's NS records are set (i.e. in a domain registrar's control panel), preferably in way that clients won't accept certificates issued by unrelated (and there unauthorized) domain registrars. As I mentioned the other day, nobody is talking about revoking ".com". We'd have multiple registrars under ".com", and if one behaves badly, revoke that particular registrar. Also, if ".com" itself is out to spoof you, then you have already lost as a .com domain owner, so maybe we SHOULD revoke all of .com if proof of that surfaces, so that everyone will know that .com can't be trusted at all anymore.
    - tptacek 10y ago
      Maybe we could actually fix the problem instead of just moving it around.
- agwa 10y ago
  Verifying based on DNS records is only a baseline. CAs can and do require more. If you want higher security for your domain, you can: 1. Make business arrangements with a handful of CAs to require additional verification when issuing certificates for your domain. 2. Use public key pinning to restrict your domain to those CAs. 3. Monitor certificate transparency logs to ensure that your chosen CAs are only issuing authorized certificates, and that other CAs are not issuing certificates for your domain. (CT does not have full coverage yet, but it has already done more to improve PKI security than DNSSEC has.) If one of your chosen CAs violates your trust, you drop them like a hot potato. DNSSEC removes this agility, leaving you at the mercy of your registrar and every zone operator higher than you in the hierarchy.
  - Kadin 10y ago
    You're already at the mercy of every CA whose certificates are trusted by default by browsers. You can request additional verification, but that's not going to stop someone from turning the screws on a CA on the other side of the planet, whose certificates are nonetheless accepted-by-default by users' systems, and as long as they're not totally foolish in deploying that cert (i.e. it's used in targeted attacks only), you'd never see it via certificate transparency. (And yes, for the record, HPKP blunts the compromised-CA weapon somewhat, but adoption has been pretty crummy. IIRC the latest iOS Safari and IE don't support it at all.)
    - tptacek 10y ago
      HPKP works no matter how many people adopt it. The most important sites on the Internet are all generally pinned (very few of them are DNSSEC-signed). Moreover, the surveillance aspect of HPKP doesn't require IE and Safari adoption. Chrome and Firefox are way more than substantial enough to make the risk of detection not worth the reward of trying to deploy a forged certificate. Note how many times in the past few years Google has slapped down CAs for "accidentally" issuing Google certificates.
    - agwa 10y ago
      The end game for certificate transparency is that browsers will reject a certificate unless the server can prove that it has been submitted to at least two logs. In fact, as of the next version of Chrome, this will be required of all Symantec certificates due to their past misdeeds. The fact that HPKP and CT have not been fully adopted yet is not a good argument against them when the alternative under discussion is DNSSEC+DANE, which has seen even less adoption and doesn't even solve the problem.
garaetjjte 10y ago
DNSSEC is Unnecessary All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Yes, because without DNSSEC they ARE insecure. With DNSSEC, we can store data in DNS that requires security. (eg. certificates for https) DNSSEC is a Government-Controlled PKI [...] Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys. How is that diffirent from current CA system, where any CA can issue certificate for any domain? Not only Muammar Gaddafi controlled bit.ly TLS keys, but anyone who can force/exploit any CA to issue certificate for it. DNSSEC is Incomplete [...] In fact, it does nothing for any of the “last mile” of DNS lookups: the link between software and DNS servers. It’s a server-to-server protocol. If client software want to be sure that reply received from ISP provided server is legitimate, it must verify DNSSEC trust chain. Though, if single DNS server is fully trusted, there is RFC 7858: "Specification for DNS over Transport Layer Security (TLS)" DNSSEC is Unsafe Yes, I agree that these chained NSEC are stupid, but it is not critical problem. CloudFlare solved that by: "We return an answer that says, “sure, the name exists, but the type you asked for does not”. This allows us to return only one NSEC record in negative answers!" (https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/) DNSSEC is Cryptographically Weak That's only point with I agree.
- tptacek 10y ago
  Yours is a rebuttal that literally leads off by suggesting we store certificates for HTTPS in a PKI that is --- not by innuendo, not by implication, not just as a consequence of how the real world works, but de jure, as labeled on the tin --- controlled at the top by world governments, most prominently those of the Five Eyes Intelligence Community. There's an FAQ, linked at the top of that post, which probably addresses any of the other arguments you'd try to raise here. DNSSEC is a failed project, and a dodged bullet.
- icebraining 10y ago
  How is that diffirent from current CA system The current CA system is already in place; an alternative should be better in the goals we wish to achieve, otherwise why incur in the switching costs?

amalcon 10y ago

I'm of more or less the opposite opinion: DNSSEC overall is pretty terrible. DANE is possibly a slight improvement over the existing CA system for some threat models, though only very slight. That improvement is frequently zero depending on the chosen threat model, though I've yet to see a real-world scenario where it's worse. DNSSEC is a complicated proposal with basically no adoption that requires widespread adoption to accomplish anything. We've had much better (though still not perfect) ways to improve authority-resolver security for years (DJB's DNSCurve for example). Given this, its only purpose is to make DANE happen. That benefit is way below the cost (again, maybe actual zero benefit depending on your point of view). It may even have a negative benefit by delaying a switch to an actually-good solution once someone figures one out (which nobody has, quite yet).