7 ms·

As long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS. At the moment, DNSSEC is th

by rocqua 8y ago

As long as domain validation is the standard for getting certs, the security of the DNS system will be part of the security of DNS. At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable. In the end, the DNS system is what we use for identity management, so it should be authenticated. As the recent attacks have shown, the actual administration of the DNS servers (Registrars) also needs to be secured. That is not DNSSEC's role. But in our current system, if a registrar is compromised, the system is compromised anyway. I'd love to hear an idea that obviates the need to trust Registrars. Without such an option, I don't think 'this doesn't defend against DNS account hijacking' counts, because nothing defends against DNS account hijacking. Once someone has that account, you are fucked. HPKP is essentially the only thing that could save you, and that has (rightly) been deprecated.

tptacek 8y ago
There is in fact very little evidence that we "need" the authentication provided by DNSSEC. Here we have an illustration of a phenomenon we've seen repeatedly: an attack for which DNSSEC has absolutely no utility, used deceptively as an argument for the necessity of DNSSEC. The same was true of claims that DNSSEC was a necessary response to BGP hijacking a few months ago. If there were actual routine attacks that DNSSEC was seriously defending against, you don't think its advocates would be sounding their trumpets about them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC deals with aren't occurring. Meanwhile: if the reason we need DNS security is for certificate issuance, DNSSEC is a stupid way to get that. We can and will create a secure channel directly between CAs and registrars (one such system is RDAP, the upcoming replacement for WHOIS). We also have systems in place that have demonstrably defeated misissuance, most notably certificate transparency, which does not in any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups, which are valuable (though imperfect) even against the BGP attacks that completely bypass DNSSEC. The history of Internet network security is largely the history of higher-layer systems routing around the insecurity of DNS; an insecure DNS is practically the premise of Internet security. And throughout that entire history, going all the way back to when I was in high school in the early-mid 1990s, DNSSEC advocates have been trying to foist this boondoggle of a protocol onto us. It was annoying when it was just a bad cryptosystem that was impossible to configure. But now it's a key escrow system as well. Fuck that. DNSSEC is still failing. Let it fail all the way away.
- Panino 8y ago
  > Let it fail all the way away. Given that just about everyone here recognizes the bad faith shown by ICANN on this issue, it seems to be an act of desperation on their part. Why? They've invested a lot into DNSSEC and are emotionally wrapped up in it, despite better alternatives. And maybe more importantly, if you consider DNS an asset, then its value rises by stuffing more "value" into it such as key escrow. Therefore DNS's principal holders (ICANN, TLDs) would see their asset depreciate if DNSSEC fizzles and dies.
- belorn 8y ago
  An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. As much as some is arguing against the introduction of authentication in DNS, there are a similar push in the opposite direction where people instead want to add encryption. For now most of that discussion is the two dominating methods to get encryption and authentication between the user and recursive resolver, but there are plenty of good reasons why we want the same standard of security between recursive resolver and authoritative resolver.
  - zrm 8y ago
    > An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. Telnet was replaced by ssh, but they're both connection-oriented protocols that create a session between two endpoints. The same is true of the transition from X to X-over-TLS for the various values of X. DNS isn't really a connection-oriented protocol to begin with and DNSSEC isn't really a protocol at all, it's a collection of DNS records for use in signature verification. Moreover, it's not encryption, only signatures. It doesn't provide privacy protection. The DNS equivalent to the transition to ssh or TLS would be something like DNSCurve, which is a transport protocol and does encrypt the data.
    - tptacek 8y ago
      Note that we actually got what DNSCurve was offering, in the form of DoTLS and DoH.
bluejekyll 8y ago
To secure against these attacks, registrars and dns hosting providers need to improve the management of the zone. Things like allowing NS, DNSKEY, and DS record updates to be authorized separately from other record management. To limit the general updates to standard DNS records. This doesn’t fix the problem of course as access can still be gained to the master admin account if it’s credentials have been compromised, which is true about nearly every service on the internet. DNS is no different, except of course that it’s critical to serving traffic to a site. I agree with the GP in that ICANN is being dishonest in encouraging DNSSEC as a response to hijacked accounts. What they should be pushing for is better security practices, like 2FA, by the registrars and more authorization limited options for limiting the exposure of an account to common updates versus less common more critical ones.
behindmyscreen 8y ago
Full DNSSEC eliminates the need to have a trusted cert supplier. You can make your own very and the DNSSEC system will be able to validate you are you and not someone else in the system.
- tptacek 8y ago
  No, "full DNSSEC", in the hypothetical universe in which browsers ever supported DANE, simply moves you from having to trust CA's like LetsEncrypt to having to trust the registrars and the world governments that have (often de jure) control over domain registration. DNSSEC does not eliminate centralized external trust anchors; it depends utterly on them. † (spoiler: Apple, Google, and Mozilla dabbled with it and then rescinded their support; Mozilla and Google have both stated, Google more formally than Mozilla, that DANE isn't happening)
  - magila 8y ago
    As long as DV certs exist the registrars are trusted anyways[0]. DNSSEC + DANE, for all its faults, would at least reduce the set of trusted actors by cutting CAs out of the chain. [0] Yes there's CT to help catch dishonest registrars, but a similar regime could be applied to registrars directly to force transparency around changes to TLSA records.
    - tptacek 8y ago
      Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors; you can't even get things narrowed down to just the governments controlling your records. Further: a mis-issuing CA can be put to death (as happened to the largest CA when Google caught them mis-issuing). You can't revoke a TLD. Meanwhile, CT actually exists today and is meaningfully combating misissuance, and obviously does not rely on DNSSEC to function.
      - magila 8y ago
        I was speaking more in a hypothetical sense, but you're right. The DNS as currently implemented is sufficiently broken so as to preclude securing it.
mtgx 8y ago
Isn't dnscurve a better alternative? Dnscrypt? Etc
- bluejekyll 8y ago
  dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record. dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy. DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.
  - tptacek 8y ago
    And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.
  - zrm 8y ago
    > DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions. But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism. Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.
    - zaarn 8y ago
      Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.
btilly 8y ago
At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable. Your reasoning is of the form, "We need something. This is something. Therefore we need this." No, actually we don't. We don't need this unless we can demonstrate that it makes things better in the real world, with real problems that people really encounter. The problem isn't simply that it fails to protect against DNS account hijacking. The problem is that it makes the common problem of DNS account hijacking even worse than it is now. Which means that it makes an existing problem bigger than it is now. Yes, it also solves another problem. But now we have to look at it as a tradeoff between two problems, decide which is worse, and decide accordingly. Every security professional and network admin that I trust finds the tradeoff obvious, and not in DNSSEC's favor.
- dbrgn 8y ago
  To give an example of how things get better in the real world: Let's Encrypt won't issue a certificate if your DNSSEC records are invalid.
  - rocqua 8y ago
    Sadly, if you can spoof DNS replies, you can probably strip the DNSSEC records. You need fail-closed systems for security, but fail-closed systems are not user friendly, and thus won't be accepted.
    - Ajedi32 8y ago
      > if you can spoof DNS replies, you can probably strip the DNSSEC records You can't. DNSSEC has explicit protections against that.
      - rocqua 8y ago
        Those don't work if you claim to be a non DNSSEC compliant resolver. Should clients really fail closed when faced with a non DNSSEC resolver they got from e.g. the starbucks WiFi DHCP? And if they should, do you really think they will? Because users will complain loudly.

by rocqua 8y ago

tptacek 8y ago

There is in fact very little evidence that we "need" the authentication provided by DNSSEC. Here we have an illustration of a phenomenon we've seen repeatedly: an attack for which DNSSEC has absolutely no utility, used deceptively as an argument for the necessity of DNSSEC. The same was true of claims that DNSSEC was a necessary response to BGP hijacking a few months ago. If there were actual routine attacks that DNSSEC was seriously defending against, you don't think its advocates would be sounding their trumpets about them incessantly? Occam's Razor argues emphatically that the attacks DNSSEC deals with aren't occurring. Meanwhile: if the reason we need DNS security is for certificate issuance, DNSSEC is a stupid way to get that. We can and will create a secure channel directly between CAs and registrars (one such system is RDAP, the upcoming replacement for WHOIS). We also have systems in place that have demonstrably defeated misissuance, most notably certificate transparency, which does not in any way depend on DNSSEC. CAs can and will do multi-perspective DNS lookups, which are valuable (though imperfect) even against the BGP attacks that completely bypass DNSSEC. The history of Internet network security is largely the history of higher-layer systems routing around the insecurity of DNS; an insecure DNS is practically the premise of Internet security. And throughout that entire history, going all the way back to when I was in high school in the early-mid 1990s, DNSSEC advocates have been trying to foist this boondoggle of a protocol onto us. It was annoying when it was just a bad cryptosystem that was impossible to configure. But now it's a key escrow system as well. Fuck that. DNSSEC is still failing. Let it fail all the way away.

Panino 8y ago
> Let it fail all the way away. Given that just about everyone here recognizes the bad faith shown by ICANN on this issue, it seems to be an act of desperation on their part. Why? They've invested a lot into DNSSEC and are emotionally wrapped up in it, despite better alternatives. And maybe more importantly, if you consider DNS an asset, then its value rises by stuffing more "value" into it such as key escrow. Therefore DNS's principal holders (ICANN, TLDs) would see their asset depreciate if DNSSEC fizzles and dies.
belorn 8y ago
An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. As much as some is arguing against the introduction of authentication in DNS, there are a similar push in the opposite direction where people instead want to add encryption. For now most of that discussion is the two dominating methods to get encryption and authentication between the user and recursive resolver, but there are plenty of good reasons why we want the same standard of security between recursive resolver and authoritative resolver.
- zrm 8y ago
  > An other view of the history of Internet network security is largely the history of plain text protocols getting encryption and authentication. Telnet was replaced by ssh, but they're both connection-oriented protocols that create a session between two endpoints. The same is true of the transition from X to X-over-TLS for the various values of X. DNS isn't really a connection-oriented protocol to begin with and DNSSEC isn't really a protocol at all, it's a collection of DNS records for use in signature verification. Moreover, it's not encryption, only signatures. It doesn't provide privacy protection. The DNS equivalent to the transition to ssh or TLS would be something like DNSCurve, which is a transport protocol and does encrypt the data.
  - tptacek 8y ago
    Note that we actually got what DNSCurve was offering, in the form of DoTLS and DoH.

bluejekyll 8y ago

To secure against these attacks, registrars and dns hosting providers need to improve the management of the zone. Things like allowing NS, DNSKEY, and DS record updates to be authorized separately from other record management. To limit the general updates to standard DNS records. This doesn’t fix the problem of course as access can still be gained to the master admin account if it’s credentials have been compromised, which is true about nearly every service on the internet. DNS is no different, except of course that it’s critical to serving traffic to a site. I agree with the GP in that ICANN is being dishonest in encouraging DNSSEC as a response to hijacked accounts. What they should be pushing for is better security practices, like 2FA, by the registrars and more authorization limited options for limiting the exposure of an account to common updates versus less common more critical ones.

behindmyscreen 8y ago

Full DNSSEC eliminates the need to have a trusted cert supplier. You can make your own very and the DNSSEC system will be able to validate you are you and not someone else in the system.

tptacek 8y ago
No, "full DNSSEC", in the hypothetical universe in which browsers ever supported DANE, simply moves you from having to trust CA's like LetsEncrypt to having to trust the registrars and the world governments that have (often de jure) control over domain registration. DNSSEC does not eliminate centralized external trust anchors; it depends utterly on them. † (spoiler: Apple, Google, and Mozilla dabbled with it and then rescinded their support; Mozilla and Google have both stated, Google more formally than Mozilla, that DANE isn't happening)
- magila 8y ago
  As long as DV certs exist the registrars are trusted anyways[0]. DNSSEC + DANE, for all its faults, would at least reduce the set of trusted actors by cutting CAs out of the chain. [0] Yes there's CT to help catch dishonest registrars, but a similar regime could be applied to registrars directly to force transparency around changes to TLSA records.
  - tptacek 8y ago
    Adam Langley explains in "Why Not DANE In Browsers" that this is not in fact the case, and that DANE will ultimately just expand the number of trust anchors; you can't even get things narrowed down to just the governments controlling your records. Further: a mis-issuing CA can be put to death (as happened to the largest CA when Google caught them mis-issuing). You can't revoke a TLD. Meanwhile, CT actually exists today and is meaningfully combating misissuance, and obviously does not rely on DNSSEC to function.
    - magila 8y ago
      I was speaking more in a hypothetical sense, but you're right. The DNS as currently implemented is sufficiently broken so as to preclude securing it.

mtgx 8y ago

Isn't dnscurve a better alternative? Dnscrypt? Etc

bluejekyll 8y ago
dnscurve and dnscrypt handle a different use case than DNSSEC. DNSSEC allows for the records in a DNS zone to be verified via signatures, also stored in the zone, RRSIGs, against keys also registered in the zone, DNSKEYs, which are pinned to the zone along with the NS records in the parent zone via a record called a DS record. dnscurve and dnscrypt are in the same space as DNS-over-HTTPS, DoH, and DNS-over-TLS, DoT. What they do is authenticate the dns server (resolver) and also encrypt the channel giving you privacy. DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions.
- tptacek 8y ago
  And, of course, one of these is a real problem and is seeing widespread deployment and has a bright future, and the other isn't and has been failing since approximately 1994.
- zrm 8y ago
  > DNSSEC == authenticated records. dnscurve, dnscrypt, DoH, and DoT == authenticated and encrypted resolutions. But notice that authenticated resolutions get you authenticated records provided you do them all the way to the root. The root servers on down could support DNSCurve or similar and you could operate recursively using it, or have your trusted recursive resolver do so as you in turn reach it using the same mechanism. Meanwhile that wouldn't break the cases where you want your DNS server to modify records, e.g. for blocking tracking domains.
  - zaarn 8y ago
    Authenticated resolution does not give you authenticated records. You cannot verify that the response between root and your resolver wasn't manipulated or that some DNS Server in the chain is sending malicious responses, even if they had DNSCurve.

btilly 8y ago

At the moment, DNSSEC is the only off-the-shelf authenticated DNS system. We need that authentication between the DNS servers and the Certificate Authorities. DNSSEC between the DNS server and hosts doesn't matter much. There are other ways to MitM, and insecure fallback is inevitable. Your reasoning is of the form, "We need something. This is something. Therefore we need this." No, actually we don't. We don't need this unless we can demonstrate that it makes things better in the real world, with real problems that people really encounter. The problem isn't simply that it fails to protect against DNS account hijacking. The problem is that it makes the common problem of DNS account hijacking even worse than it is now. Which means that it makes an existing problem bigger than it is now. Yes, it also solves another problem. But now we have to look at it as a tradeoff between two problems, decide which is worse, and decide accordingly. Every security professional and network admin that I trust finds the tradeoff obvious, and not in DNSSEC's favor.

dbrgn 8y ago
To give an example of how things get better in the real world: Let's Encrypt won't issue a certificate if your DNSSEC records are invalid.
- rocqua 8y ago
  Sadly, if you can spoof DNS replies, you can probably strip the DNSSEC records. You need fail-closed systems for security, but fail-closed systems are not user friendly, and thus won't be accepted.
  - Ajedi32 8y ago
    > if you can spoof DNS replies, you can probably strip the DNSSEC records You can't. DNSSEC has explicit protections against that.
    - rocqua 8y ago
      Those don't work if you claim to be a non DNSSEC compliant resolver. Should clients really fail closed when faced with a non DNSSEC resolver they got from e.g. the starbucks WiFi DHCP? And if they should, do you really think they will? Because users will complain loudly.