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.
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 ?
I'll bite. Reasons that you might not only not want to use DNSSEC yourself, but also believe it's important for the protocol not to find any success:
* It creates a global tree-based PKI rooted in world governments (and, on the 2018 Internet, particularly the "Five Eyes" governments), many of which have already demonstrated an eagerness to manipulate Internet infrastructure to capture intelligence.
* Simply in order to reach parity with the (poor) security UX we have today, it will require major forklift-grade updates to libraries and code already deployed, because virtually all Internet software is written with the assumption that DNS lookups fail only because of network failures or user errors, and DNSSEC introduces a third basic class of failures. All this new code will be costly and that money could be spent on better things, and all that new code will be buggy.
* We now know from years of niche experience that our predictions about DNSSEC and reliability were right, that DNSSEC is rarely deployed reliably (major providers routinely screw it up), and that it creates frequent outages that wouldn't occur were DNSSEC not deployed in the first place.
Against these and other concerns you have to weigh the benefits of DNSSEC. But unfortunately for the protocol, the last 25 years of protocol development has proceeded based on the premise that the DNS isn't trustworthy to begin with --- you have to draw a line in the protocol "stack" somewhere, with "insecure" stuff below and "secure" stuff above, and we've essentially spent the last quarter century with that line drawn above DNS. As a result: the benefits of DNSSEC are marginal, bordering on vanishing.
It used to be that there was a coherent argument for DNSSEC around email; DNSSEC would enable MTAs to establish secure connections reliably. But major email providers have given up on DNSSEC even for that application: SMTP STS doesn't depend on DNSSEC.
We know that a very large group of internet users are directly or indirectly using Google's public resolvers, which do DNSSEC validation.
Therefor, any DNS stub library in common use already has to know about DNSSEC failures, because in some countries, like The Netherlands, or Sweden, a very large fraction of the domains are DNSSEC signed.
Due to those Google public resolvers, broken DNSSEC doesn't go unnoticed. So broken DNSSEC is actually quite rare these days.
I have domains that have deliberate broken DNSSEC. Does that that count toward DNSSEC being broken? Same for TLS, I have websites with broken certs.
If you want to say something about how the internet is broken, then look at production traffic. Don't just take the list of all .com domains. Because many of them will never see any traffic.
Of course, nobody is going to report on the alexa 1 million. Because that would be completely boring.
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.
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.
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].
My understanding is (a) the current interpretation of the BR's does not require DNSSEC, and that (b) validation of DNSSEC among CAs is not the norm; CAs have disabled it because it proved unreliable.
It's certainly not an interpretation I'd punish a CA for, the language in section 3.2.2.8 is rather ambiguous.
Let's Encrypt is running a fail-close setup for DNSSEC, so I wouldn't quite say it's too unreliable in this particular context. Still, it's quite clear that DNSSEC's complexity is getting in the way of things here. A solution just for this specific use-case would be much simpler overall, and I'm not buying into any of the other benefits DNSSEC claims to bring, so I'd rather just see it die.
DNSSEC, to a degree, stands in the way of a better solution.
When no such "better solution" exists this is wishful thinking, we might make the same argument for any number of core systems and protocols.
In particular you've offered no evidence whatsoever that a system could be developed (much less _has_ been developed and thus offers a viable alternative) which avoids "blindly" trusting authoritative answers from name owners about their names...
Historically the rationale for why we can't do DNSSEC on clients is that it won't work because of middleboxes. The present topic is of course about deliberately altering clients so as to bypass middleboxes and so actually this is a world where DNSSEC works much _better_ than ever before.
This doesn't make any sense. First, it's plainly obvious that we could design replacements for essentially any protocol. Second, the fundamental design problems that would motivate and be corrected in a new DNSSEC are obvious:
* Offline signers was a mistake, since virtually all leaf authority servers are online signers due to the NSEC debacle.
* A protocol with less than 20% saturation in 2018 that expects to be deployed would be based on a modern signature scheme, not RSA.
Just altering those two elements of the design would allow for a radically improved protocol.
I'm 41 years old. The DNSSEC design being promoted right now was started when I was still in high school, during the phlogiston era of cryptographic protocol design. It is lunacy to believe that it is the best thing we can come up with.
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.
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.
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.
Comments
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.
"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 ?
I'll bite. Reasons that you might not only not want to use DNSSEC yourself, but also believe it's important for the protocol not to find any success:
* It creates a global tree-based PKI rooted in world governments (and, on the 2018 Internet, particularly the "Five Eyes" governments), many of which have already demonstrated an eagerness to manipulate Internet infrastructure to capture intelligence.
* Simply in order to reach parity with the (poor) security UX we have today, it will require major forklift-grade updates to libraries and code already deployed, because virtually all Internet software is written with the assumption that DNS lookups fail only because of network failures or user errors, and DNSSEC introduces a third basic class of failures. All this new code will be costly and that money could be spent on better things, and all that new code will be buggy.
* We now know from years of niche experience that our predictions about DNSSEC and reliability were right, that DNSSEC is rarely deployed reliably (major providers routinely screw it up), and that it creates frequent outages that wouldn't occur were DNSSEC not deployed in the first place.
Against these and other concerns you have to weigh the benefits of DNSSEC. But unfortunately for the protocol, the last 25 years of protocol development has proceeded based on the premise that the DNS isn't trustworthy to begin with --- you have to draw a line in the protocol "stack" somewhere, with "insecure" stuff below and "secure" stuff above, and we've essentially spent the last quarter century with that line drawn above DNS. As a result: the benefits of DNSSEC are marginal, bordering on vanishing.
It used to be that there was a coherent argument for DNSSEC around email; DNSSEC would enable MTAs to establish secure connections reliably. But major email providers have given up on DNSSEC even for that application: SMTP STS doesn't depend on DNSSEC.
We know that a very large group of internet users are directly or indirectly using Google's public resolvers, which do DNSSEC validation.
Therefor, any DNS stub library in common use already has to know about DNSSEC failures, because in some countries, like The Netherlands, or Sweden, a very large fraction of the domains are DNSSEC signed.
Due to those Google public resolvers, broken DNSSEC doesn't go unnoticed. So broken DNSSEC is actually quite rare these days.
I didn't just make that up; there was a measurement study at last year's Usenix. It's a debacle.
https://www.usenix.org/system/files/conference/usenixsecurit...
I have domains that have deliberate broken DNSSEC. Does that that count toward DNSSEC being broken? Same for TLS, I have websites with broken certs.
If you want to say something about how the internet is broken, then look at production traffic. Don't just take the list of all .com domains. Because many of them will never see any traffic.
Of course, nobody is going to report on the alexa 1 million. Because that would be completely boring.
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.
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.
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
[2]: https://community.letsencrypt.org/t/acme-caa-validationmetho...
My understanding is (a) the current interpretation of the BR's does not require DNSSEC, and that (b) validation of DNSSEC among CAs is not the norm; CAs have disabled it because it proved unreliable.
It's certainly not an interpretation I'd punish a CA for, the language in section 3.2.2.8 is rather ambiguous.
Let's Encrypt is running a fail-close setup for DNSSEC, so I wouldn't quite say it's too unreliable in this particular context. Still, it's quite clear that DNSSEC's complexity is getting in the way of things here. A solution just for this specific use-case would be much simpler overall, and I'm not buying into any of the other benefits DNSSEC claims to bring, so I'd rather just see it die.
When no such "better solution" exists this is wishful thinking, we might make the same argument for any number of core systems and protocols.
In particular you've offered no evidence whatsoever that a system could be developed (much less _has_ been developed and thus offers a viable alternative) which avoids "blindly" trusting authoritative answers from name owners about their names...
Historically the rationale for why we can't do DNSSEC on clients is that it won't work because of middleboxes. The present topic is of course about deliberately altering clients so as to bypass middleboxes and so actually this is a world where DNSSEC works much _better_ than ever before.
This doesn't make any sense. First, it's plainly obvious that we could design replacements for essentially any protocol. Second, the fundamental design problems that would motivate and be corrected in a new DNSSEC are obvious:
* Offline signers was a mistake, since virtually all leaf authority servers are online signers due to the NSEC debacle.
* A protocol with less than 20% saturation in 2018 that expects to be deployed would be based on a modern signature scheme, not RSA.
Just altering those two elements of the design would allow for a radically improved protocol.
I'm 41 years old. The DNSSEC design being promoted right now was started when I was still in high school, during the phlogiston era of cryptographic protocol design. It is lunacy to believe that it is the best thing we can come up with.
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.
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.
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.