7 ms·

Not sure if you're the author, but thanks for the DNSSEC section!

by _lce0 11y ago

dvanduzer 11y ago
The defenses of DNSSEC are a bit confused. First, the proper comparison for X.509 trusted sources is between the root anchor and the browser vendors not the specific trust sources chosen by Mozilla (or Microsoft or whomever). Second, we can tell how many entities we have to trust, and the author just counted them: Mozilla's 177 delegates. Arguably, with DNSSEC, we can't tell how many entities to trust: how many zones has `com.` signed? Third, X.509 allows the signing of arbitrary names largely because DNS isn't trustworthy. (And also because DNS isn't the only naming system people care about.) Finally, with only one trusted path, there is only one place you need to attack to fool everyone.
- clinta 11y ago
  It's not just the trustworthyness of the browser vendor, but the scope. Any of the 177 delegates are trusted to sign for any domain on the internet. Further, those 177 delegates can mint CA=True certificates for anyone they like and our browsers trust those subordinates by default. That's what the author means by we can't know how many CA's we trust. With DNSSEC there is one public key hash stored in the com zone which authenticates the public key for the paypal.com domain. With many possible trusted paths for validation you only need to attack the weakest one, and because CA's are not restricted in what domains they can sign, you will still fool everyone.
- marcosdumay 11y ago
  I'm becoming a serial defender of DNSSEC here :) You are inverting your second question. Every zone that we trust 'com.' to sign can only be singed by Verizon. There's one single point of trust here, you know what it is, and can choose what point you want when getting a domain. About that one trusted path, you are also inverting the issue. With X.509 there are 100 places you can attack, any one of them being enough to fool everybody. With DNSSEC you have one single place (more like 3) you can attack, and can only fool people about a limited number of sites. Really, DNSSEC is objectively better than X509, as for every flaw in DNSSEC, there is one equal or worse equivalent flaw on X509. Except of course for the issue of publishing all the signed names, that is a different trade-off between DoS protection and obscurity, so you can have a subjective opinion about.
  - tptacek 11y ago
    You're leaving some details out, here: * The CA system is not overtly delegated to governments, and the top level domains of the DNS tree are. * Most of the world's most popular and privacy-sensitive websites are locked into domains controlled by governments with aggressive signals intelligence programs. * CAs are revokable without global coordination, and DNS zones are not, so if an DNS zone owner begins misbehaving, there will be few options to restore trust. * Modern X.509 doesn't merely rely on the CA tree, but also on (a) pinning and soon (b) CT logs, both of which create Internet-wide surveillance systems that make it extremely risky to subvert TLS sessions using compromised CAs. * For that matter, pinned certificate take X.509 almost entirely out of the equation for sensitive sites like Google Mail; attempts to MITM Google are probably what caused the last few CA compromises to be detected. * The cryptography in DNSSEC dates back to the 1990s; even the variant of RSA that it uses is obsolete.
  - dvanduzer 11y ago
    (I assume you meant to s/Verizon/Verisign/ there.) Are you saying that if I don't trust [current .com delegate] to manage my naming authentication, I can choose .ly or .io instead? I was trying to point out that DNSSEC can't do anything about googIe.com or similar i18n-style attacks. I'm glad that TACK exists, and I'm glad people like tptacek are advocating for it. But DNSSEC and X.509 aren't the only two possibilities for the future of secure infrastructure.
    - marcosdumay 11y ago
      Funny thing that TACK and the Google project for certificate transparency have exactly the same failure point of DNSSEC, in that both will make all the names public. TACK is great. Google's certificate transparency isn't. And, yes, we need more proposals. The more, the better. And, by the way, yes, it's Verisign, thanks.
jevinskie 11y ago
Another thing to keep in mind with DNSSEC is that DNS has a 512 byte limit when using UDP. Anything higher than that requires a full TCP connection - pretty costly. Anyone know if progress is being made on using ECC instead of RSA for DNSSEC?
- axaxs 11y ago
  EDNS0 extends this to 4096, and it seems pretty well supported. You can use ECC in DNSSEC, though not many people do yet.
  - tptacek 11y ago
    One reason they don't is that major DNSSEC validators have been seen rejecting ECC signatures. Also, however much ECC gets deployed in DNSSEC: * The roots and TLDs remain RSA-signed (until very recently, they were signed RSA-1024!) * Those RSA records are obsolete PKCS1v15 RSA * The ECC used by DNSSEC is NIST p- curve DSA; both that curve and that construction are also obsolete, and error-prone * There is virtually no chance any of this is going to change, since change would require coordinated updates to thousands of DNSSEC validators, which were --- against the advice of lots of people --- deployed aggressively and in advance of real demand, thus locking DNSSEC down to 1990s crypto despite the fact that it's first commercial use was in 2015. Thankfully, two of the four most popular browsers on the Internet have declared publicly that they're not going to support DNSSEC (or DANE, the DNSSEC CA replacement scheme). DNSSEC is a dead letter. People who are interested in DNS security should get to work designing SDNS or Secure-DNS or CryptoDNS or whatever the successor to DNSSEC will be called.
    - jevinskie 11y ago
      What is your opinion on DNScrypt? As far as I've seen it is somewhat the Yin to DNSSEC's Yang.
      - tptacek 11y ago
        DNSSEC is top-down. DNSCrypt is bottom-up. DNSSEC provides no value until the whole system works. DNSCrypt adds value even if just two systems use it. DNSSEC uses 1990s crypto. DNSCrypt uses 2010+ crypto. DNSSEC doesn't protect name resolution queries. DNSCrypt only protects name resolution queries.

Not sure if you're the author, but thanks for the DNSSEC section!

by _lce0 11y ago

Not sure if you're the author, but thanks for the DNSSEC section!

The defenses of DNSSEC are a bit confused. First, the proper comparison for X.509 trusted sources is between the root anchor and the browser vendors not the specific trust sources chosen by Mozilla (or Microsoft or whomever). Second, we can tell how many entities we have to trust, and the author just counted them: Mozilla's 177 delegates. Arguably, with DNSSEC, we can't tell how many entities to trust: how many zones has `com.` signed? Third, X.509 allows the signing of arbitrary names largely because DNS isn't trustworthy. (And also because DNS isn't the only naming system people care about.) Finally, with only one trusted path, there is only one place you need to attack to fool everyone.

clinta 11y ago
It's not just the trustworthyness of the browser vendor, but the scope. Any of the 177 delegates are trusted to sign for any domain on the internet. Further, those 177 delegates can mint CA=True certificates for anyone they like and our browsers trust those subordinates by default. That's what the author means by we can't know how many CA's we trust. With DNSSEC there is one public key hash stored in the com zone which authenticates the public key for the paypal.com domain. With many possible trusted paths for validation you only need to attack the weakest one, and because CA's are not restricted in what domains they can sign, you will still fool everyone.
marcosdumay 11y ago
I'm becoming a serial defender of DNSSEC here :) You are inverting your second question. Every zone that we trust 'com.' to sign can only be singed by Verizon. There's one single point of trust here, you know what it is, and can choose what point you want when getting a domain. About that one trusted path, you are also inverting the issue. With X.509 there are 100 places you can attack, any one of them being enough to fool everybody. With DNSSEC you have one single place (more like 3) you can attack, and can only fool people about a limited number of sites. Really, DNSSEC is objectively better than X509, as for every flaw in DNSSEC, there is one equal or worse equivalent flaw on X509. Except of course for the issue of publishing all the signed names, that is a different trade-off between DoS protection and obscurity, so you can have a subjective opinion about.
- tptacek 11y ago
  You're leaving some details out, here: * The CA system is not overtly delegated to governments, and the top level domains of the DNS tree are. * Most of the world's most popular and privacy-sensitive websites are locked into domains controlled by governments with aggressive signals intelligence programs. * CAs are revokable without global coordination, and DNS zones are not, so if an DNS zone owner begins misbehaving, there will be few options to restore trust. * Modern X.509 doesn't merely rely on the CA tree, but also on (a) pinning and soon (b) CT logs, both of which create Internet-wide surveillance systems that make it extremely risky to subvert TLS sessions using compromised CAs. * For that matter, pinned certificate take X.509 almost entirely out of the equation for sensitive sites like Google Mail; attempts to MITM Google are probably what caused the last few CA compromises to be detected. * The cryptography in DNSSEC dates back to the 1990s; even the variant of RSA that it uses is obsolete.
- dvanduzer 11y ago
  (I assume you meant to s/Verizon/Verisign/ there.) Are you saying that if I don't trust [current .com delegate] to manage my naming authentication, I can choose .ly or .io instead? I was trying to point out that DNSSEC can't do anything about googIe.com or similar i18n-style attacks. I'm glad that TACK exists, and I'm glad people like tptacek are advocating for it. But DNSSEC and X.509 aren't the only two possibilities for the future of secure infrastructure.
  - marcosdumay 11y ago
    Funny thing that TACK and the Google project for certificate transparency have exactly the same failure point of DNSSEC, in that both will make all the names public. TACK is great. Google's certificate transparency isn't. And, yes, we need more proposals. The more, the better. And, by the way, yes, it's Verisign, thanks.

jevinskie 11y ago

Another thing to keep in mind with DNSSEC is that DNS has a 512 byte limit when using UDP. Anything higher than that requires a full TCP connection - pretty costly. Anyone know if progress is being made on using ECC instead of RSA for DNSSEC?

axaxs 11y ago
EDNS0 extends this to 4096, and it seems pretty well supported. You can use ECC in DNSSEC, though not many people do yet.
- tptacek 11y ago
  One reason they don't is that major DNSSEC validators have been seen rejecting ECC signatures. Also, however much ECC gets deployed in DNSSEC: * The roots and TLDs remain RSA-signed (until very recently, they were signed RSA-1024!) * Those RSA records are obsolete PKCS1v15 RSA * The ECC used by DNSSEC is NIST p- curve DSA; both that curve and that construction are also obsolete, and error-prone * There is virtually no chance any of this is going to change, since change would require coordinated updates to thousands of DNSSEC validators, which were --- against the advice of lots of people --- deployed aggressively and in advance of real demand, thus locking DNSSEC down to 1990s crypto despite the fact that it's first commercial use was in 2015. Thankfully, two of the four most popular browsers on the Internet have declared publicly that they're not going to support DNSSEC (or DANE, the DNSSEC CA replacement scheme). DNSSEC is a dead letter. People who are interested in DNS security should get to work designing SDNS or Secure-DNS or CryptoDNS or whatever the successor to DNSSEC will be called.
  - jevinskie 11y ago
    What is your opinion on DNScrypt? As far as I've seen it is somewhat the Yin to DNSSEC's Yang.
    - tptacek 11y ago
      DNSSEC is top-down. DNSCrypt is bottom-up. DNSSEC provides no value until the whole system works. DNSCrypt adds value even if just two systems use it. DNSSEC uses 1990s crypto. DNSCrypt uses 2010+ crypto. DNSSEC doesn't protect name resolution queries. DNSCrypt only protects name resolution queries.