4 ms·

At this point, someone should just file a high severity / high impact CVE against DNSSEC in its entirety, and ensure the box-tickers all across the world mandat

At this point, someone should just file a high severity / high impact CVE against DNSSEC in its entirety, and ensure the box-tickers all across the world mandate its eradication. While I'm sure (even stronger: I know) that at some point DNSSEC was a good idea, it's just a liability-slash-infrastructure-tax these days (a footgun at best, an additional DoS vector in most cases), and it's time for it to go. 99% of DNSSEC deployments come down to "I trust the entity I have outsourced my DNS management to with my private key management as well", which makes no sense whatsoever, and the reasoning behind the remaining 1% doesn't inspire much confidence either. DoH satisfies the DNS privacy/security requirements of most Internet users just fine, and with or without DNSSEC, the management of the underlying infrastructure remains the same as it was before, i.e. "trust us"...

pornel 3y ago
DNSSEC doesn't have encryption, and does nothing for end-user privacy, so that's not even an alternative to DoH or DNSCurve. The only thing it deems a potential privacy issue is possibility of enumeration of subdomains, which is security by obscurity for the domain owner, from a time before certificate transparency logs ruined that anyway.
- RegnisGnaw 3y ago
  NSEC3 pretty much solves this issue.
  - tptacek 3y ago
    It doesn't, at all. NSEC3 is crackable like a 1990s password file, and several tools exist to do it. The "standard" solution to this is "whitelies" (RFC4470), which requires your DNSSEC server to be an online signer so it can generate chaff records; the supposedly upcoming solution is NSEC5, which fixes the broken cryptography in NSEC3.
- jcranmer 3y ago
  > from a time before certificate transparency logs ruined that anyway. Isn't it possible under WebPKI rules to get an intermediate cert for all of your subdomains so that only the intermediate cert needs to get logged in certificate transparency? Or at the very least, you could use a wildcard underneath the domain you own...
  - woodruffw 3y ago
    I don’t think CAB would prevent that kind of intermediate, but I don’t know of any CA that issues them. The domain set would need to be enforced with name constraints, which are notoriously buggy in a lot of validators. But yes, a wildcard accomplishes the same thing, and I think that’s the route (almost?) everyone goes if a service’s subdomains really need to be kept out of a transparency log.
    - hsbauauvhabzb 3y ago
      I was under the impression you could flag your domain to not be in cert transparency logs. Security through obscurity is generally considered a bad idea (to which I think exceptions or nuance exist), but the likelihood of dns names being burnt via other mechanisms (isps/‘security’ products and platforms logging dns requests and selling them being a reasonable assumption).
      - woodruffw 3y ago
        I don’t believe this is true. CT is wholly encompassing by design: if you could somehow opt out, an attacker could use that mechanism to bypass CT. (As far as I know, the only way to “opt out” is to use a wildcard to obscure the true subdomain being accessed.) Edit: from a quick look online, CT became mandatory for CA issued certificates in the Web PKI in 2018.
JackSlateur 3y ago
Hum, DNSSEC is highly useful tho Both DNSSEC and DoT/DoH prevent hijack between the customer and the resolver However, only DNSSEC prevents hijacks between the resolver and the authoritative servers DNSSEC is the only way to trust a zone's content Or maybe DoT/DoH shall be the only way to resolve things, and the DNS over UDP/TCP shall be deleted from the surface of the earth ?
- ekr____ 3y ago
  It's important to understand why one might care about trusting the zone's content. From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack. I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance. Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE). Taking the opportunity to reference myself, the following longer writeups might be useful on this topic: https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/ https://educatedguesswork.org/posts/dns-security-dane/
- PreInternet01 3y ago
  > DNSSEC is highly useful tho Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus). And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys. Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...
belorn 3y ago
It sounds good as long we apply it to all outsourcing where security relies on a third-party. End-to-end encryption was never designed with the concept of clouds and anycast providers, including the whole idea of virtual servers. They all depend on "I trust the entity who owns this hardware" which can be any partner which the cloud provider deemed worthy.

pornel 3y ago

DNSSEC doesn't have encryption, and does nothing for end-user privacy, so that's not even an alternative to DoH or DNSCurve. The only thing it deems a potential privacy issue is possibility of enumeration of subdomains, which is security by obscurity for the domain owner, from a time before certificate transparency logs ruined that anyway.

RegnisGnaw 3y ago
NSEC3 pretty much solves this issue.
- tptacek 3y ago
  It doesn't, at all. NSEC3 is crackable like a 1990s password file, and several tools exist to do it. The "standard" solution to this is "whitelies" (RFC4470), which requires your DNSSEC server to be an online signer so it can generate chaff records; the supposedly upcoming solution is NSEC5, which fixes the broken cryptography in NSEC3.
jcranmer 3y ago
> from a time before certificate transparency logs ruined that anyway. Isn't it possible under WebPKI rules to get an intermediate cert for all of your subdomains so that only the intermediate cert needs to get logged in certificate transparency? Or at the very least, you could use a wildcard underneath the domain you own...
- woodruffw 3y ago
  I don’t think CAB would prevent that kind of intermediate, but I don’t know of any CA that issues them. The domain set would need to be enforced with name constraints, which are notoriously buggy in a lot of validators. But yes, a wildcard accomplishes the same thing, and I think that’s the route (almost?) everyone goes if a service’s subdomains really need to be kept out of a transparency log.
  - hsbauauvhabzb 3y ago
    I was under the impression you could flag your domain to not be in cert transparency logs. Security through obscurity is generally considered a bad idea (to which I think exceptions or nuance exist), but the likelihood of dns names being burnt via other mechanisms (isps/‘security’ products and platforms logging dns requests and selling them being a reasonable assumption).
    - woodruffw 3y ago
      I don’t believe this is true. CT is wholly encompassing by design: if you could somehow opt out, an attacker could use that mechanism to bypass CT. (As far as I know, the only way to “opt out” is to use a wildcard to obscure the true subdomain being accessed.) Edit: from a quick look online, CT became mandatory for CA issued certificates in the Web PKI in 2018.

JackSlateur 3y ago

Hum, DNSSEC is highly useful tho Both DNSSEC and DoT/DoH prevent hijack between the customer and the resolver However, only DNSSEC prevents hijacks between the resolver and the authoritative servers DNSSEC is the only way to trust a zone's content Or maybe DoT/DoH shall be the only way to resolve things, and the DNS over UDP/TCP shall be deleted from the surface of the earth ?

ekr____ 3y ago
It's important to understand why one might care about trusting the zone's content. From the perspective of something like a browser, the mapping from the domain name to the IP address (i.e., the A or AAAA records) need not be secured via DNS because the connection to the server is secured via TLS and the WebPKI. So DNSSEC isn't helping here, especially because the clients don't check DNSSEC, so it doesn't protect them from attack on the local network, which is one of the main loci. If the DNS server provides the wrong IP, this is mostly a DoS attack. I am aware that the situation is somewhat different in email but I'm not sure how different really. Note that it is the case that DNSSEC could help secure ACME validation queries, but as tpacek observes, CT has greatly reduced the risk of misissuance. Of course there are other mappings in the DNS, but as a general matter those are being designed under the assumption that the DNS is untrustworthy, due to the low level of DNSSEC deployment. For instance, if you look at the HTTPS RR, it's fine to put a key for Encrypted Client Hello in it because the resolver already knows the desired domain name, so lying about the key doesn't really help. However, we can't safely publish the server's public key to be used for TLS 1.3 early data ("Zero RTT priming") because that would require trusting the DNS. So, any features which require the DNS to be secure have the usual chicken-and-egg deployment problems (this is also to a great extent what happened with DANE). Taking the opportunity to reference myself, the following longer writeups might be useful on this topic: https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/ https://educatedguesswork.org/posts/dns-security-dane/
PreInternet01 3y ago
> DNSSEC is highly useful tho Not as it's deployed today. Since over 80% (conservative guesstimate) of the zones that most people care about are not signed, it's pretty much useless. The 'evil ISP or IT MITMs my DNS traffic' scenario is much more effectively addressed with DoH (since it only requires clients and some resolvers to coordinate, not the entire Internet, and it looks like regular HTTPS, which implementers already understand how to deal with, as a bonus). And the 'evil government redirects some or all zones' play is still very much possible even with DNSSEC, since, guess who ultimately controls the keys. Even if you think that making the latter scenario more difficult to implement is worth it, getting more people to sign their zones is a losing battle, since they're very much likely to self-DoS themselves in the process, significantly reducing their enthusiasm...

belorn 3y ago

It sounds good as long we apply it to all outsourcing where security relies on a third-party. End-to-end encryption was never designed with the concept of clouds and anycast providers, including the whole idea of virtual servers. They all depend on "I trust the entity who owns this hardware" which can be any partner which the cloud provider deemed worthy.