8 ms·

Rather than talking about what’s wrong with DNSSEC, let’s focus on what it’s intended to do for security. DNSSEC is a set of related DNS record types that allow

Rather than talking about what’s wrong with DNSSEC, let’s focus on what it’s intended to do for security. DNSSEC is a set of related DNS record types that allow zones to sign individual records with a key, and chain that back to parent zones. In practice, this looks very much like X509 certificate chains, if you’re familiar with those. The intention is to authenticate all data in the DNS graph with the root zones being signed by a root key, and then every sub-zone signing itself and all other sub-zones until you reach the leaf records signed by the current zones DNSKEY. Many people take issue with the fact that the root key is a single, long-lived, somewhat weak RSA key, that could be compromised. The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary.

tptacek 8y ago
The bigger issue is that it adds to the ~50-odd CAs we're required to trust a collection of new CAs --- the owners of commercially relevant TLDs --- who, unlike existing CAs, we can't just kill when we detect misbehavior.
- teddyh 8y ago
  X.509 CA’s are problematic precisely because any one of them, no matter how sketchy, can issue certificates for any name. DNSSEC does not have that problem: TLD’s in DNSSEC are restricted to their TLD, and you can decide yourself if you trust the domains in the hypothetical “.sketchy” TLD to be properly DNSSEC signed.
  - tptacek 8y ago
    And every one of them can be monitored and will be killed if they mis-issue. If Google can kill Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, what hope does some random small CA have? The same thing is absolutely not the case of TLD owners. There is no mechanism at all to "revoke" them. You can't "distrust" them without the entire TLD vanishing from the Internet.
    - toast0 8y ago
      On the other hand, we implicitly trust the TLD owners to not just take over whatever domains they want. If they change the NS records, they can get a cert issued from their choice of CA, and the CA didn't misissue. It seems to me, that we would be in a better place with additional explicit trust on TLD providers, eventually leading towards not needing to trust external CAs.
      - tptacek 8y ago
        I don't even understand the premise of this argument. You're in effect saying that we should replace commercial trust roots that are accountable to browser vendors with government-run trust roots accountable to no-one. How could that be an improvement?
        toast0 8y ago
        My argument is, the TLDs already fully control the domain. Given that they fully control the domain, they can use that to request issuance of a domain controlled certificate. If at the end of the day, the TLD controls everything, I'd rather not have anybody else to worry about.
        tptacek 8y ago
        That's not true. If Verisign tomorrow altered .COM to temporarily claim a Google name sufficient to acquire a DV Google.com cert, the CA that issued that certificate would be dead the next day.
        toast0 8y ago
        That's great if you're Google, but if neustar took over my .org domain, any CA would be happy to issue, and I'd be SOL. I don't see a whole lot of difference between that and if they take over my .org and that enables them to issue certs directly through DANE or whatever.
auslander 8y ago
> TLS is enough authentication of a site What about other records? MX, TXT, NS? How they are protected from tampering, both in transit and by rogue DNS servers? > weak RSA key Better than plaintext, harder to modify, is it not?
- Fnoord 8y ago
  > What about other records? MX, TXT, NS? How they are protected from tampering, both in transit DNSCrypt, DNS over TLS, DNS over HTTPS. > and by rogue DNS servers By querying multiple DNSCrypt servers and comparing the results. > Better than plaintext, is it not? Depends. People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning."
  - auslander 8y ago
    > By querying ... and comparing Checking crypto signature is more reliable, imho I think best way to go is both, DNSSEC and DoT. > People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning." I'm one of those suckers :D
  - bluejekyll 8y ago
    Everything you mention as alternatives don’t actually solve the authentication issue. They do make joining the DNS network harder. Those technologies authenticate the DNS servers, and encrypt the channels, but they do not authenticate the records. We should have techniques for both privacy, DNSCrypt/DoT/DoH, and authenticity, DNSSEC. I won’t offer an opinion on the root key management in DNS, but the underlying technologies for authenticating and signing records in DNSSEC are good.
    - pvg 8y ago
      What does 'authenticated records' actually get you?
      - bluejekyll 8y ago
teddyh 8y ago
> somewhat weak RSA key 2048-bit RSA is “weak”? If I understand things correctly, 2048-bit keys are considered safe for more than ten years still, and the design of DNSSEC is such that the root keys can be rolled over at any time, so when the time comes, the key can simply be substitued for a stronger one. And the comparison with X.509 is unsuitable. The DNSSEC root key could be compromised? How about the fact that if any CA loses its key, the entire X.509 system is vulnerable until that key can be revoked by every single end user?
- tptacek 8y ago
  2048 bit keys? What about all the 1024 bit keys that litter the DNSSEC PKI? How about the fact that CA keys can be revoked? Google and Mozilla killed one of the largest CAs in the market for misissuance. How do you kill .COM? You think if Symantec had a say in the matter, they'd let Google kill their CA business? How about the fact that weeks after the KSK roll, more than half the Internet still depends on the old root key?
  - teddyh 8y ago
    > What about all the 1024 bit keys that litter the DNSSEC PKI? You’re moving the goalposts. The parent comment was explicitly about the root key. Yes, there are still weak keys below the root, just as there are still weak certifikates with MD5 hashes out there, but that is neither here nor there.
    - tptacek 8y ago
      No, modern browsers won't honor MD5 (or, for that matter SHA-1) certificates. But there's nothing they can do about 1024 bit RSA keys in DNSSEC. Starting to see the pattern?
    - akerl_ 8y ago
      Just to clarify, bluejekyll referred to the root keys as a "somewhat weak RSA key", you pointed out that the root keys are 2048 bit, and tptacek responded pointing out that while the root keys are 2048 bit, the chain between them and basically any site with DNSSEC has 1024 bit keys involved. That's not really "moving the goalpost", so much as "a conversation involving more than 2 people". I pulled up the chain for cloudflare.com on the grounds that they'd care more than the average site about DNSSEC, and here was the result: http://dnsviz.net/d/cloudflare.com/dnssec/ http://dnsviz.net/d/cloudflare.com/dnssec/ So that's a 2048 bit root, and then as the chain passes through .com there's a 1024 bit RSA key, and then they have ECC keys for their zone. If their TLS cert had a hop in the chain that used MD5 hashes, Chrome would be refusing to trust their site.

tptacek 8y ago

The bigger issue is that it adds to the ~50-odd CAs we're required to trust a collection of new CAs --- the owners of commercially relevant TLDs --- who, unlike existing CAs, we can't just kill when we detect misbehavior.

teddyh 8y ago
X.509 CA’s are problematic precisely because any one of them, no matter how sketchy, can issue certificates for any name. DNSSEC does not have that problem: TLD’s in DNSSEC are restricted to their TLD, and you can decide yourself if you trust the domains in the hypothetical “.sketchy” TLD to be properly DNSSEC signed.
- tptacek 8y ago
  And every one of them can be monitored and will be killed if they mis-issue. If Google can kill Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, what hope does some random small CA have? The same thing is absolutely not the case of TLD owners. There is no mechanism at all to "revoke" them. You can't "distrust" them without the entire TLD vanishing from the Internet.
  - toast0 8y ago
    On the other hand, we implicitly trust the TLD owners to not just take over whatever domains they want. If they change the NS records, they can get a cert issued from their choice of CA, and the CA didn't misissue. It seems to me, that we would be in a better place with additional explicit trust on TLD providers, eventually leading towards not needing to trust external CAs.
    - tptacek 8y ago
      I don't even understand the premise of this argument. You're in effect saying that we should replace commercial trust roots that are accountable to browser vendors with government-run trust roots accountable to no-one. How could that be an improvement?
      - toast0 8y ago
        My argument is, the TLDs already fully control the domain. Given that they fully control the domain, they can use that to request issuance of a domain controlled certificate. If at the end of the day, the TLD controls everything, I'd rather not have anybody else to worry about.
        tptacek 8y ago
        That's not true. If Verisign tomorrow altered .COM to temporarily claim a Google name sufficient to acquire a DV Google.com cert, the CA that issued that certificate would be dead the next day.
        toast0 8y ago
        That's great if you're Google, but if neustar took over my .org domain, any CA would be happy to issue, and I'd be SOL. I don't see a whole lot of difference between that and if they take over my .org and that enables them to issue certs directly through DANE or whatever.

auslander 8y ago

> TLS is enough authentication of a site What about other records? MX, TXT, NS? How they are protected from tampering, both in transit and by rogue DNS servers? > weak RSA key Better than plaintext, harder to modify, is it not?

Fnoord 8y ago
> What about other records? MX, TXT, NS? How they are protected from tampering, both in transit DNSCrypt, DNS over TLS, DNS over HTTPS. > and by rogue DNS servers By querying multiple DNSCrypt servers and comparing the results. > Better than plaintext, is it not? Depends. People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning."
- auslander 8y ago
  > By querying ... and comparing Checking crypto signature is more reliable, imho I think best way to go is both, DNSSEC and DoT. > People are going to assume "I am using DNSSEC so I cannot be vulnerable to DNS poisoning." I'm one of those suckers :D
- bluejekyll 8y ago
  Everything you mention as alternatives don’t actually solve the authentication issue. They do make joining the DNS network harder. Those technologies authenticate the DNS servers, and encrypt the channels, but they do not authenticate the records. We should have techniques for both privacy, DNSCrypt/DoT/DoH, and authenticity, DNSSEC. I won’t offer an opinion on the root key management in DNS, but the underlying technologies for authenticating and signing records in DNSSEC are good.
  - pvg 8y ago
    What does 'authenticated records' actually get you?
    - bluejekyll 8y ago

teddyh 8y ago

> somewhat weak RSA key 2048-bit RSA is “weak”? If I understand things correctly, 2048-bit keys are considered safe for more than ten years still, and the design of DNSSEC is such that the root keys can be rolled over at any time, so when the time comes, the key can simply be substitued for a stronger one. And the comparison with X.509 is unsuitable. The DNSSEC root key could be compromised? How about the fact that if any CA loses its key, the entire X.509 system is vulnerable until that key can be revoked by every single end user?

tptacek 8y ago
2048 bit keys? What about all the 1024 bit keys that litter the DNSSEC PKI? How about the fact that CA keys can be revoked? Google and Mozilla killed one of the largest CAs in the market for misissuance. How do you kill .COM? You think if Symantec had a say in the matter, they'd let Google kill their CA business? How about the fact that weeks after the KSK roll, more than half the Internet still depends on the old root key?
- teddyh 8y ago
  > What about all the 1024 bit keys that litter the DNSSEC PKI? You’re moving the goalposts. The parent comment was explicitly about the root key. Yes, there are still weak keys below the root, just as there are still weak certifikates with MD5 hashes out there, but that is neither here nor there.
  - tptacek 8y ago
    No, modern browsers won't honor MD5 (or, for that matter SHA-1) certificates. But there's nothing they can do about 1024 bit RSA keys in DNSSEC. Starting to see the pattern?
  - akerl_ 8y ago
    Just to clarify, bluejekyll referred to the root keys as a "somewhat weak RSA key", you pointed out that the root keys are 2048 bit, and tptacek responded pointing out that while the root keys are 2048 bit, the chain between them and basically any site with DNSSEC has 1024 bit keys involved. That's not really "moving the goalpost", so much as "a conversation involving more than 2 people". I pulled up the chain for cloudflare.com on the grounds that they'd care more than the average site about DNSSEC, and here was the result: http://dnsviz.net/d/cloudflare.com/dnssec/ http://dnsviz.net/d/cloudflare.com/dnssec/ So that's a 2048 bit root, and then as the chain passes through .com there's a 1024 bit RSA key, and then they have ECC keys for their zone. If their TLS cert had a hop in the chain that used MD5 hashes, Chrome would be refusing to trust their site.