9 ms·

DNSSEC is Open for Beta

73 points by tilt 11y ago

mtgx 11y ago
Why are people pushing DNSSEC adoption when it uses such obsolete crypto? What happens when 80% of the web adopts it, and then we find out 5 years later that all of DNSSEC keys can be cracked? Upgrade the protocol first, then come back telling us how great DNSSEC is.
- throwaway2048 11y ago
  the protocol suports both ecdsa and sha-2
  - sarciszewski 11y ago
    But not EdDSA.
- FiloSottile 11y ago
  CloudFlare DNSSEC uses ECDSA on P256 and SHA256 exclusively. That's what modern TLS uses. https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/
  - tptacek 11y ago
    That's what current TLS uses. Modern TLS, Google TLS, uses better crypto than that. In particular, as you know, ECDSA is outmoded. Also: Cloudflare may use ECDSA, but the roots and TLDs do not. And because DNSSEC is a stupid design, it matters a lot that they don't.
  - sarciszewski 11y ago
    Haha Filo did you really call ECDSA modern?
    - FiloSottile 11y ago
      Yeah. That's the best thing you can get for TLS certificates now, and most likely for the next five years. So that's what modern TLS uses, yeah. I hate it as much as the next cryptographer, and I actually gave talks begging people to at least do deterministic ECDSA. But there's no EdDSA on the horizon. Also, I think Thomas in the sister comment was referring to handshakes, but I was talking about X509.
      - sarciszewski 11y ago
        Fair enough. I'm still hoping we'll see EdDSA (22519 and 448) sooner rather than later. :)
parent5446 11y ago
Unfortunately, still waiting on AWS Route 53. If only DNSSEC was a worthwhile enough feature to migrate DNS services.
- stevekemp 11y ago
  Route53 is awesome, but yes it is missing at least two things a lot of people crave: * IPv6 nameservers. * DNSSec support.
  - antod 11y ago
    AXFR and/or IXFR? RFC 2136 / TSIG compatible updates? Those would be my personal wish list items ie better interoperability/compatibility with published standards. Those things may have been added recently though (I haven't checked in a while), but I doubt it.
    - stevekemp 11y ago
      AXFR is one of those things that is perhaps less valuable - after all _you_ put the data there, via their API, so you have it to-hand. On that basis you don't need to do a zone-transfer to get the data out, just use your existing source of truth. (In my case I upload to Route53 via a git repository and push, and regard that repository as the source of truth - https://dns-api.com/ https://dns-api.com/ )
steckerbrett 11y ago
Cloudflare-ternet.
- deleted 11y ago
  [deleted]
Zash 11y ago
But will they control the keys? It would be pretty neat if they did not have to. Like their TLS thing where you still control the private key, but call out to you to use it.
- throwaway2048 11y ago
  This is actually a lot more managable with DNSSEC because it is designed around the idea of offline signing of records.
hsivonen 11y ago
What's the use case? Thanks to TLS, you don't need DNSSEC for the Web. For email, if your DNSSEC-enabled domain delegates to a provider that isn't DNSSEC-enabled, you haven't accomplished anything of true value.
- captn3m0 11y ago
  I was gonna reply how we need to prevent DNS queries from being eavesdropped. But it seems, DNSSEC does not support traffic encryption: >DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. (From the wiki) However, DNS poisoning attacks are still relevant because not all of the web is on HTTPS.
  - hsivonen 11y ago
    Addressing non-HTTPS Web issues with migration to DNSSEC instead of migration to HTTPS is totally bogus. It's especially bogus as a use case in the Cloudflare case, since Cloudflare had HTTPS first.
davidu 11y ago
The use-case for DNSSEC is still far from clear to me. DANE is the closest thing to a valid use case and it looks like Chrome and others are exploring better solutions than DANE. Moreover -- The lack of encryption is still a major issue IMHO. Validation is great, except that when a record fails to validate the end user experience is essentially NXDOMAIN which is not a very friendly user experience. At least with SSL certificate failures, the application has visibility into the cause of the failure. In DNSSEC, it's hard to distinguish between a failed validation and any other kind of DNS resolution failure. I just can't see a world where people enable validating resolvers that reject non-validating responses. And if that's true, then the entire point of DNSSEC is largely compromised -- with the possible exception of using DNSSEC to validate in-line verifications (a la DANE).
- zurn 11y ago
  You can do all kinds of nice DANE-like things. For example keys for SSH, IPSec, OpenVPN, NFS, etc. "We already have something for web browsers" isn't a big counterargument. I agree they should add confidentiality. That shouldn't be too hard since all the key handling is already taken care of.
gwu78 11y ago
"... because DNS, invented in 1983 before the public consumption of the Internet, does not perform any authentication." Authentication of what? An end point? No. A domainname? OK, I'll play along. And why would "authentication" of a dommainname be necessary? Maybe because the end user is communicating with a shared DNS cache operated by a third party instead of using their own? But I do not use shared DNS caches. I use my own cache. Moreover I use CurveDNS which provides encryption of DNS packets in transit and is at least as good at "authenticating" the proper authoritative server for each domainname as DNSSEC. How would DNSSEC serve me? DNSSEC could be a way for certain groups to maintain control over the use of DNS. Similar to the way SSL CA system has been used to control the use of encryption. Both the use of domainnames and SSL certificates are each commercial in nature (pay to play). They do not have to be, but schemes like CA system and DNSSEC allow for this to occur via centralisation of authority.
- talideon 11y ago
  Authentication of whether the records have been tampered with or not. That includes the very authoritative nameserver you fetched them from in the first place, which might have been compromised. This is why DNSSEC allows zones to be signed offline by the zone's owner rather than trusting the nameserver. Even if you run your own DNS cache, some bad actor between you and zone owner (including the aforementioned authoritative DNS server) can still potentially provide you with bad data. DNSCurve gives you _encrypted traffic_, but DNSSEC gives you _accurate results_. They solve two different problems.
  - gwu78 11y ago
    "They solve two different problems." Well-known fact. And truthfully the most sensible approach would be to use both. Yet I never see anyone doing that. Given the choice between the two problems, I know which one I consider more serious. The results might be "accurate" when stored on the nameserver but if they get tampered with in transit went sent over the wire then they are not "accurate" when they are received. In that case DNSSEC does not give me accurate results. Moreover I am not keen on the widepread sniffing of DNS traffic. Name lookups and other DNS requests and responses are just as important as HTTP traffic. Why encrypt one and not the other? Finally, I could be wrong but I think getting redirected to a bogus nameserver run by a "bad actor" seems (easier for the bad actor and) more likely than accessing the correct nameserver without the knowledge it has secretly been compromised.
FullyFunctional 11y ago
DDoSers [1] around the world rejoice. [1] http://cr.yp.to/talks/2009.08.10/slides.pdf http://cr.yp.to/talks/2009.08.10/slides.pdf http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/talks/2009.03.21/slides.pdf http://cr.yp.to/talks/2009.03.21/slides.pdf etc etc but also http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html

73 points by tilt 11y ago

mtgx 11y ago

Why are people pushing DNSSEC adoption when it uses such obsolete crypto? What happens when 80% of the web adopts it, and then we find out 5 years later that all of DNSSEC keys can be cracked? Upgrade the protocol first, then come back telling us how great DNSSEC is.

throwaway2048 11y ago
the protocol suports both ecdsa and sha-2
- sarciszewski 11y ago
  But not EdDSA.
FiloSottile 11y ago
CloudFlare DNSSEC uses ECDSA on P256 and SHA256 exclusively. That's what modern TLS uses. https://blog.cloudflare.com/dnssec-done-right/ https://blog.cloudflare.com/dnssec-done-right/
- tptacek 11y ago
  That's what current TLS uses. Modern TLS, Google TLS, uses better crypto than that. In particular, as you know, ECDSA is outmoded. Also: Cloudflare may use ECDSA, but the roots and TLDs do not. And because DNSSEC is a stupid design, it matters a lot that they don't.
- sarciszewski 11y ago
  Haha Filo did you really call ECDSA modern?
  - FiloSottile 11y ago
    Yeah. That's the best thing you can get for TLS certificates now, and most likely for the next five years. So that's what modern TLS uses, yeah. I hate it as much as the next cryptographer, and I actually gave talks begging people to at least do deterministic ECDSA. But there's no EdDSA on the horizon. Also, I think Thomas in the sister comment was referring to handshakes, but I was talking about X509.
    - sarciszewski 11y ago
      Fair enough. I'm still hoping we'll see EdDSA (22519 and 448) sooner rather than later. :)

parent5446 11y ago

Unfortunately, still waiting on AWS Route 53. If only DNSSEC was a worthwhile enough feature to migrate DNS services.

stevekemp 11y ago
Route53 is awesome, but yes it is missing at least two things a lot of people crave: * IPv6 nameservers. * DNSSec support.
- antod 11y ago
  AXFR and/or IXFR? RFC 2136 / TSIG compatible updates? Those would be my personal wish list items ie better interoperability/compatibility with published standards. Those things may have been added recently though (I haven't checked in a while), but I doubt it.
  - stevekemp 11y ago
    AXFR is one of those things that is perhaps less valuable - after all _you_ put the data there, via their API, so you have it to-hand. On that basis you don't need to do a zone-transfer to get the data out, just use your existing source of truth. (In my case I upload to Route53 via a git repository and push, and regard that repository as the source of truth - https://dns-api.com/ https://dns-api.com/ )

steckerbrett 11y ago

Cloudflare-ternet.

deleted 11y ago
[deleted]

Zash 11y ago

But will they control the keys? It would be pretty neat if they did not have to. Like their TLS thing where you still control the private key, but call out to you to use it.

throwaway2048 11y ago
This is actually a lot more managable with DNSSEC because it is designed around the idea of offline signing of records.

hsivonen 11y ago

What's the use case? Thanks to TLS, you don't need DNSSEC for the Web. For email, if your DNSSEC-enabled domain delegates to a provider that isn't DNSSEC-enabled, you haven't accomplished anything of true value.

captn3m0 11y ago
I was gonna reply how we need to prevent DNS queries from being eavesdropped. But it seems, DNSSEC does not support traffic encryption: >DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. (From the wiki) However, DNS poisoning attacks are still relevant because not all of the web is on HTTPS.
- hsivonen 11y ago
  Addressing non-HTTPS Web issues with migration to DNSSEC instead of migration to HTTPS is totally bogus. It's especially bogus as a use case in the Cloudflare case, since Cloudflare had HTTPS first.

davidu 11y ago

The use-case for DNSSEC is still far from clear to me. DANE is the closest thing to a valid use case and it looks like Chrome and others are exploring better solutions than DANE. Moreover -- The lack of encryption is still a major issue IMHO. Validation is great, except that when a record fails to validate the end user experience is essentially NXDOMAIN which is not a very friendly user experience. At least with SSL certificate failures, the application has visibility into the cause of the failure. In DNSSEC, it's hard to distinguish between a failed validation and any other kind of DNS resolution failure. I just can't see a world where people enable validating resolvers that reject non-validating responses. And if that's true, then the entire point of DNSSEC is largely compromised -- with the possible exception of using DNSSEC to validate in-line verifications (a la DANE).

zurn 11y ago
You can do all kinds of nice DANE-like things. For example keys for SSH, IPSec, OpenVPN, NFS, etc. "We already have something for web browsers" isn't a big counterargument. I agree they should add confidentiality. That shouldn't be too hard since all the key handling is already taken care of.

gwu78 11y ago

"... because DNS, invented in 1983 before the public consumption of the Internet, does not perform any authentication." Authentication of what? An end point? No. A domainname? OK, I'll play along. And why would "authentication" of a dommainname be necessary? Maybe because the end user is communicating with a shared DNS cache operated by a third party instead of using their own? But I do not use shared DNS caches. I use my own cache. Moreover I use CurveDNS which provides encryption of DNS packets in transit and is at least as good at "authenticating" the proper authoritative server for each domainname as DNSSEC. How would DNSSEC serve me? DNSSEC could be a way for certain groups to maintain control over the use of DNS. Similar to the way SSL CA system has been used to control the use of encryption. Both the use of domainnames and SSL certificates are each commercial in nature (pay to play). They do not have to be, but schemes like CA system and DNSSEC allow for this to occur via centralisation of authority.

talideon 11y ago
Authentication of whether the records have been tampered with or not. That includes the very authoritative nameserver you fetched them from in the first place, which might have been compromised. This is why DNSSEC allows zones to be signed offline by the zone's owner rather than trusting the nameserver. Even if you run your own DNS cache, some bad actor between you and zone owner (including the aforementioned authoritative DNS server) can still potentially provide you with bad data. DNSCurve gives you _encrypted traffic_, but DNSSEC gives you _accurate results_. They solve two different problems.
- gwu78 11y ago
  "They solve two different problems." Well-known fact. And truthfully the most sensible approach would be to use both. Yet I never see anyone doing that. Given the choice between the two problems, I know which one I consider more serious. The results might be "accurate" when stored on the nameserver but if they get tampered with in transit went sent over the wire then they are not "accurate" when they are received. In that case DNSSEC does not give me accurate results. Moreover I am not keen on the widepread sniffing of DNS traffic. Name lookups and other DNS requests and responses are just as important as HTTP traffic. Why encrypt one and not the other? Finally, I could be wrong but I think getting redirected to a bogus nameserver run by a "bad actor" seems (easier for the bad actor and) more likely than accessing the correct nameserver without the knowledge it has secretly been compromised.

FullyFunctional 11y ago

DDoSers [1] around the world rejoice. [1] http://cr.yp.to/talks/2009.08.10/slides.pdf http://cr.yp.to/talks/2009.08.10/slides.pdf http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/talks/2009.03.21/slides.pdf http://cr.yp.to/talks/2009.03.21/slides.pdf etc etc but also http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html