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.
Comments
"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.