5 ms·

It's important to note that DNSSEC does not provide encryption. Additionally, very few client resolvers validate DNSSEC. In typical MitM scenarios, DNS over TLS

by pfg 8y ago

It's important to note that DNSSEC does not provide encryption. Additionally, very few client resolvers validate DNSSEC. In typical MitM scenarios, DNS over TLS or HTTPS provides much better protection. If the resolver happens to validate DNSSEC, you're probably adding a bit of protection for other scenarios, but overall I'd still rather not see DNSSEC succeed. The confidentiality win is not huge, most use-cases will let an attacker make a good guess at the query through the destination IP (for IPs serving only one site) or via SNI. Still, there's definitely a win for other types of queries, and it'll get more useful once we figure out how to encrypt SNI.

jedisct1 8y ago
Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNSSEC validation if only because your own zones can be signed. You know, the ones you will be constantly ssh'ing to, and blindly accept new ssh server keys from because hey, it's your zone and you trust it.
- deleted 8y ago
  [deleted]
- tptacek 8y ago
  A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.
- pfg 8y ago
  Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.
tialaramex 8y ago
"overall I'd still rather not see DNSSEC succeed" Can you explain why it's important _not_ to have DNSSEC ? In the most threatening MitM scenarios that we see, an adversary controls IP traffic to their victims (usually only relatively briefly). If we can use DNSSEC this gets them a denial of service and nothing further. But with your preferred options they are able to silently interpose as the victim, and tools you've worked on like Let's Encrypt will help "re-assure" the public that nothing is wrong. I have no doubt that ISRG would say they have no liability when the relying parties are screwed over - that's after all exactly what their commercial equivalents say all the time - but it'd be an easier argument to make if you weren't here saying that when it comes to the one thing that _would_ work you'd "rather not see it succeed". Do you at least have something _instead_ you think would give people these benefits ?
- pfg 8y ago
  In the modern Web PKI, it seems to me that the only thing DNSSEC is good for is mitigating BGP hijacking and similar attacks (in combination with CAA and either some contractual agreement with your CA or the ACME CAA extension). That's an important issue to solve, but you wouldn't need anything with the complexity and baggage of DNSSEC to do that. DNSSEC, to a degree, stands in the way of a better solution. And while I have no problem with people using DNSSEC as an additional layer of defense as such, I feel like there's a risk that people will use it as the only layer of defense if it becomes a success, effectively blindly trusting DNS.
  - tptacek 8y ago
    Wait, how would DNSSEC possibly mitigate BGP hijacking? I heard this last time there was a publicized BGP-hijacking incident and it made no sense to me then and still doesn't now. Attackers who control BGP control IP addresses themselves, the things DNS records point to. They don't even need to touch the DNS to intercept traffic.
    - pfg 8y ago
      The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far off target) and that they properly validate DNSSEC (good luck with that, I don't think there's even consensus on what the Baseline Requirements consider compliant). Anyway, in this mostly hypothetical world where all of that works as intended, you could use a CAA record with just one or two CAs with which you have some kind of contractual relationship requiring out-of-band verification. Alternatively (and, IMO, preferable, since the controls are technical), you can use the ACME CAA extension[1] to lock down the validation methods to just DNS-based ones, or bind the the whole validation flow to a key. Let's Encrypt is working on this currently[2]. [1]: https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4 https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4 [2]: https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125 https://community.letsencrypt.org/t/acme-caa-validationmetho...

by pfg 8y ago

jedisct1 8y ago

Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNSSEC validation if only because your own zones can be signed. You know, the ones you will be constantly ssh'ing to, and blindly accept new ssh server keys from because hey, it's your zone and you trust it.

deleted 8y ago
[deleted]
tptacek 8y ago
A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.
pfg 8y ago
Note that I was referring to client/stub resolvers specifically. Last time I checked, it was rather uncommon for them to perform their own DNSSEC validation rather than trusting the AD bit sent by their upstream resolver. In practice that means any MitM between you and your DNS resolver can spoof DNS regardless of DNSSEC status. DoH/DoT, on the other hand, mitigates this.

tialaramex 8y ago

"overall I'd still rather not see DNSSEC succeed" Can you explain why it's important _not_ to have DNSSEC ? In the most threatening MitM scenarios that we see, an adversary controls IP traffic to their victims (usually only relatively briefly). If we can use DNSSEC this gets them a denial of service and nothing further. But with your preferred options they are able to silently interpose as the victim, and tools you've worked on like Let's Encrypt will help "re-assure" the public that nothing is wrong. I have no doubt that ISRG would say they have no liability when the relying parties are screwed over - that's after all exactly what their commercial equivalents say all the time - but it'd be an easier argument to make if you weren't here saying that when it comes to the one thing that _would_ work you'd "rather not see it succeed". Do you at least have something _instead_ you think would give people these benefits ?

pfg 8y ago
In the modern Web PKI, it seems to me that the only thing DNSSEC is good for is mitigating BGP hijacking and similar attacks (in combination with CAA and either some contractual agreement with your CA or the ACME CAA extension). That's an important issue to solve, but you wouldn't need anything with the complexity and baggage of DNSSEC to do that. DNSSEC, to a degree, stands in the way of a better solution. And while I have no problem with people using DNSSEC as an additional layer of defense as such, I feel like there's a risk that people will use it as the only layer of defense if it becomes a success, effectively blindly trusting DNS.
- tptacek 8y ago
  Wait, how would DNSSEC possibly mitigate BGP hijacking? I heard this last time there was a publicized BGP-hijacking incident and it made no sense to me then and still doesn't now. Attackers who control BGP control IP addresses themselves, the things DNS records point to. They don't even need to touch the DNS to intercept traffic.
  - pfg 8y ago
    The magic sauce would be CAA. This is under the assumption that all publicly trusted CAs respect CAA and have no bypass bugs (CAs probably aren't ... too far off target) and that they properly validate DNSSEC (good luck with that, I don't think there's even consensus on what the Baseline Requirements consider compliant). Anyway, in this mostly hypothetical world where all of that works as intended, you could use a CAA record with just one or two CAs with which you have some kind of contractual relationship requiring out-of-band verification. Alternatively (and, IMO, preferable, since the controls are technical), you can use the ACME CAA extension[1] to lock down the validation methods to just DNS-based ones, or bind the the whole validation flow to a key. Let's Encrypt is working on this currently[2]. [1]: https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4 https://tools.ietf.org/html/draft-ietf-acme-caa-05#section-4 [2]: https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125 https://community.letsencrypt.org/t/acme-caa-validationmetho...