7 ms·

DNSSEC doesn't help when the attacker controls your DNS control panel, just like DNSSEC doesn't help in almost every other practical attack scenario. Let's kil

by jaas 8y ago

DNSSEC doesn't help when the attacker controls your DNS control panel, just like DNSSEC doesn't help in almost every other practical attack scenario. Let's kill it off and focus on efforts that solve real problems. It's worse than pointless, the added complexity is a huge liability.

kadendogthing 8y ago
>Let's kill it off and focus on efforts that solve real problems Like what? It's pointless to distract from constructive proposals with no supporting material for what the problems are with the proposed solution, and then claim there are other things that need our attention and then not even pay lip service to them.
- ryanlol 8y ago
  DNSSEC is strictly not a constructive proposal.
  - kadendogthing 8y ago
    Oh okay.
- jcranmer 8y ago
  DNSSEC is quite famously a solution in search of a problem. It's pretty explicitly designed to secure the requests from the resolver to the nameservers, not from the actual end-users--and the number of actual attacks that would be prevented as a result are pretty damn minuscule.
  - phicoh 8y ago
    DNSSEC works perfectly fine for securing requests from end-users. Of course you need to link your application with a DNSSEC-validating library. But that's just a small matter of code. Things become slightly more complicated when you have to deal with broken home routers. But that code exists as well.
    - tptacek 8y ago
      No, it doesn't. DNSSEC is a server-to-server protocol. Your caching resolver, after completing a DNSSEC-signed lookup, signals your stub resolver that the request was "secure" by means of a single header bit. There is no security whatsoever between client resolvers and DNSSEC servers. What you meant to say was that DNSSEC works "perfectly fine for securing requests from end-users" so long as they run their own DNSSEC cache servers. But of course, nobody is going to do that. They'll run DoH/DoTLS instead.
      - phicoh 8y ago
        DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop spreading misinformation. Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.
        tptacek 8y ago
        You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].
        deleted 8y ago
        [deleted]
        Abekkus 8y ago
  - kadendogthing 8y ago
    >DNSSEC is quite famously a solution in search of a problem. I've only seen this sentiment every now and then in very particular circles. It's not really that famous.
    - tptacek 8y ago
      Here's a fun exercise: find the most reputable security or cryptography person you can that has publicly said nice things about DNSSEC. For extra fun, try to find one that isn't in some way affiliated with the IETF (most security and cryptography people aren't, so that shouldn't be too hard).
      - kadendogthing 8y ago
        Well I don't know about people but I do know that a lot of big names in networking support and enable DNSSEC by default. So again, the sentiment isn't that famous because it's a widely used security feature. named has it on by default. Here's a fun exercise: You could just say what you need to say to make a point and educate the people reading this thread. Otherwise your comment is kind of detracting from constructive conversation.
        tptacek 8y ago
        Which big names would those be?
        kadendogthing 8y ago
        >named has it on by default. I stated as such in my comment you're replying to. The software that basically everyone uses for DNS management. Google DNS supports it by default, requiring you to opt out. I gave you an example, it would be greatly appreciated for you to provide a substantive, informative comment about the problems with DNSSEC or at the very least provide other material authored by other people (blogs/articles/etc) who are famous security experts who do not support DNSSEC -- you seem to know who to go to.
ypolito 8y ago
I hope vendors like DigitalOcean would provide more fine tuned access controls in their APIs. Certbot, which I have setup to automatically renew my wildcard Let's Encrypt certificates, has access to my master API key on DO. I try to follow the best practices in keeping it safe, but I'd prefer if that specific API key would only have the required privileges to modify a set of specifically named TXT records and nothing more.
- geggam 8y ago
  use AWS and IAM roles like civilized folk
  - regecks 8y ago
    Route53/IAM doesn't have any way to restrict access to only _acme-challenge DNS labels. Use RFC2136 like civilized folk, I guess. ¯\_(ツ)_/¯
    - bashinator 8y ago
      I'm a little surprised that route53 IAM policies aren't granular enough to restrict access to specific records or record types. It seems obvious that a service (lambda or such) should be able to issue cert autorenewal records without any other route53 access, and I wouldn't be surprised if this were already on a roadmap.
  - Avamander 8y ago
    Wish it supported all my TLDs.
Ajedi32 8y ago
> DNSSEC doesn't help in almost every other practical attack scenario It helps against BGP attacks. https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche... DNSSEC + a CAA record with the validationmethods parameter set to DNS would prevent that attack.
- koheripbal 8y ago
  Exactly. I'm all for adding authentication elsewhere, but there's no need to kill DNSSEC.

by jaas 8y ago

kadendogthing 8y ago

>Let's kill it off and focus on efforts that solve real problems Like what? It's pointless to distract from constructive proposals with no supporting material for what the problems are with the proposed solution, and then claim there are other things that need our attention and then not even pay lip service to them.

ryanlol 8y ago
DNSSEC is strictly not a constructive proposal.
- kadendogthing 8y ago
  Oh okay.
jcranmer 8y ago
DNSSEC is quite famously a solution in search of a problem. It's pretty explicitly designed to secure the requests from the resolver to the nameservers, not from the actual end-users--and the number of actual attacks that would be prevented as a result are pretty damn minuscule.
- phicoh 8y ago
  DNSSEC works perfectly fine for securing requests from end-users. Of course you need to link your application with a DNSSEC-validating library. But that's just a small matter of code. Things become slightly more complicated when you have to deal with broken home routers. But that code exists as well.
  - tptacek 8y ago
    No, it doesn't. DNSSEC is a server-to-server protocol. Your caching resolver, after completing a DNSSEC-signed lookup, signals your stub resolver that the request was "secure" by means of a single header bit. There is no security whatsoever between client resolvers and DNSSEC servers. What you meant to say was that DNSSEC works "perfectly fine for securing requests from end-users" so long as they run their own DNSSEC cache servers. But of course, nobody is going to do that. They'll run DoH/DoTLS instead.
    - phicoh 8y ago
      DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop spreading misinformation. Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.
      - tptacek 8y ago
        You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].
        deleted 8y ago
        [deleted]
        Abekkus 8y ago
- kadendogthing 8y ago
  >DNSSEC is quite famously a solution in search of a problem. I've only seen this sentiment every now and then in very particular circles. It's not really that famous.
  - tptacek 8y ago
    Here's a fun exercise: find the most reputable security or cryptography person you can that has publicly said nice things about DNSSEC. For extra fun, try to find one that isn't in some way affiliated with the IETF (most security and cryptography people aren't, so that shouldn't be too hard).
    - kadendogthing 8y ago
      Well I don't know about people but I do know that a lot of big names in networking support and enable DNSSEC by default. So again, the sentiment isn't that famous because it's a widely used security feature. named has it on by default. Here's a fun exercise: You could just say what you need to say to make a point and educate the people reading this thread. Otherwise your comment is kind of detracting from constructive conversation.
      - tptacek 8y ago
        Which big names would those be?
        kadendogthing 8y ago
        >named has it on by default. I stated as such in my comment you're replying to. The software that basically everyone uses for DNS management. Google DNS supports it by default, requiring you to opt out. I gave you an example, it would be greatly appreciated for you to provide a substantive, informative comment about the problems with DNSSEC or at the very least provide other material authored by other people (blogs/articles/etc) who are famous security experts who do not support DNSSEC -- you seem to know who to go to.

ypolito 8y ago

I hope vendors like DigitalOcean would provide more fine tuned access controls in their APIs. Certbot, which I have setup to automatically renew my wildcard Let's Encrypt certificates, has access to my master API key on DO. I try to follow the best practices in keeping it safe, but I'd prefer if that specific API key would only have the required privileges to modify a set of specifically named TXT records and nothing more.

geggam 8y ago
use AWS and IAM roles like civilized folk
- regecks 8y ago
  Route53/IAM doesn't have any way to restrict access to only _acme-challenge DNS labels. Use RFC2136 like civilized folk, I guess. ¯\_(ツ)_/¯
  - bashinator 8y ago
    I'm a little surprised that route53 IAM policies aren't granular enough to restrict access to specific records or record types. It seems obvious that a service (lambda or such) should be able to issue cert autorenewal records without any other route53 access, and I wouldn't be surprised if this were already on a roadmap.
- Avamander 8y ago
  Wish it supported all my TLDs.

Ajedi32 8y ago

> DNSSEC doesn't help in almost every other practical attack scenario It helps against BGP attacks. https://www.blackhat.com/docs/us-15/materials/us-15-Gavrichenkov-Breaking-HTTPS-With-BGP-Hijacking.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Gavriche... DNSSEC + a CAA record with the validationmethods parameter set to DNS would prevent that attack.

koheripbal 8y ago
Exactly. I'm all for adding authentication elsewhere, but there's no need to kill DNSSEC.