Against DNSSEC (2015)
sockpuppet.org
sockpuppet.org
for d in Amazon.com Facebook.com Apple.com Google.com Netflix.com ; do delv "$d" @1.1.1.1; done1. The overwhelming majority of those names are meaningless, just as it doesn't change anything about Internet security if I do or don't sign the "paulgra-ham.com" domain I bought on Hover years ago when I was drunk.
2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
The total adoption of DNSSEC in commercial zones is between 1-4% right now, right?
> 2. Registrar signatures are more or less security theater, because those customers aren't even controlling their own keys.
It would be nifty if DNSSEC (or some superior technology) provided a degree of protection against a compromised registrar, but I don’t think that’s the primary benefit. Of course the registrar can change the DNS data.
DNSSEC purports to secure the transfer of data from the combination of the registrar and the domain owner to the resolver. For example, the combination of DNSSEC and CAA can, in principle, prevent even an arbitrarily privileged attacker on the network from getting a bogus certificate issued. Without DNSSEC, services like Let’s Encrypt rely on a degree or network voodoo to protect against MITM attack.
(Of course, a much simpler and more robust mechanism could accomplish the same goal. For example, there could be a standardized out of band mechanism by which a CA could securely ask a registry for the certificate policy for a domain. Something like this wouldn’t have the admin-screwed-up—and-the-whole-domain-is-down failure modes.)
edit: It looks like RDAP is moderately close to being able to do that out-of-band verification. I wonder if anyone is working on CAA integration with RDAP.
P.S. Lots of hypothetical examples were given, but I'd like to see an actual case.
P.P.S. tptacek try to hold your tongue for at least a little bit before piping in with your usual response. :)
https://www.icann.org/en/system/files/files/sac-121-en.pdf
The attackers took over the authoritative DNS servers and answered queries with lies.
https://en.wikipedia.org/wiki/DNS_hijacking
DNSSEC gives you end-to-end protection against DNS hijacking if your local resolver does DNSSEC verification and the domain being looked up uses DNSSEC.
All you have to do is install a local resolver like https://www.knot-resolver.cz which does DNSSEC verification by default.
It can be configured to talk to your upstream DNS servers or some other DNS-over-TLS servers if you want (like the Cloudflare DNS servers).
It does if you run a local caching resolver with DNSSEC validation which is what I mentioned in the post you replied to.
This caching resolver works as your system resolver, i.e., it sits on your machine and acts as an intermediary between your local apps and the upstream ISP DNS servers to cache responses and also rejects any spoofed DNS response from the upstream ISP as long as the domain has DNSSEC enabled.
You are only considering DNSSEC from the point of view of a stub resolver, which nowadays is more appropriate for a microcontroller-based system rather than a modern system (including things like smartphones, home routers and cheap Raspberry Pi-like machines).
Note that many modern Linux systems and home routers already have caching resolvers, it's just that most of them are not DNSSEC-validating (by default, at least).
also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
Sorry but I don't follow. The 99.9% of people that do not know what DNS is, don't need to know what DNSSEC is either. It works regardless of whether you know what it is.
All you need is for microsoft/apple to start validating DNS, like you mention below.
> also, it'd receive enormous pushback from governments if microsoft/apple were to start validating DNS, as it would prevent them from blocking sites in the most common way, rewriting DNS queries for illegal sites (for example, in australia, we have blocks on various torrent sites like thepiratebay)
No, because DNSSEC doesn't prevent DNS responses from being blocked, so the governments and ISPs can continue doing that.
DNSSEC validation only prevents responses from being spoofed/forged. The ISP DNS server can still refuse to answer queries if it wants.
DoH is what can prevent DNS queries from being blocked, and DoH has already been implemented in Firefox and Android as far as I know.
Also, DNSSEC and DoH can (and should) be implemented together, they are not mutually exclusive, rather, they complement each other, as DoH by itself doesn't protect against forgeries by the upstream DNS server.
Supposedly this still has some compatibility problems, which is why Fedora (at least) still has DNSSEC=no as the default, overriding the upstream systemd-resolved default.
It would be great to identify and fix the majority of those compatibility problems so that DNSSEC validation could be enabled by default.
Once a large enough mass of users would have DNSSEC validation enabled by default, the incentive would then be on the network operators to fix the remaining compatibility problems, as the users' devices would work just fine on other networks and they would perceive the fault to be on the incompatible network they were using, not on their device.
Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... by default. Doesn't mean that the software doesn't support it (by simply flipping DNSSEC=no to DNSSEC=yes in resolved.conf). It also doesn't mean they can't switch the default once most compatibility issues are solved.
> Obviously, an ISP can simply flip the `AD` bit in any DNS response it wants to edit.
... which would be rejected by DNSSEC validation in the client.
Besides, many DNSSEC queries are currently validated by trusted DNS servers like Cloudflare's and Google's which don't flip the `AD` bit and can communicate to the clients via a secure protocol like DNS-over-HTTPS (implemented in Firefox and Android) or DNS-over-TLS.
So don't dismiss the value that it already has, even without client-side DNSSEC validation.
You're right, good point. Let's give up on DNSSEC then. :)
1) Some DNS servers don't yet support DNSSEC (presumably including the DNS servers of some ISPs?)
Presumably this could be solved by contacting the admins of the affected DNS servers and asking them to update their DNS server software. I think this is the biggest issue I know of.
2) The hostnames of NTP servers on DNSSEC domains can't be resolved when the client's clock is too out-of-sync.
As another poster mentioned, this is not an inherent problem with DNSSEC, as TLS or any other similar security scheme would have the same problem.
Presumably, until the issue can be solved in some better way, you'd have to have a couple of NTP servers on your config on non-DNSSEC domains or addressed by their IP addresses. For corporate networks, perhaps you could have a trusted NTP server (or servers) with stable clocks (or even GPS clocks) on your private network and address them by IP address.
Further: when Apple and Microsoft operating systems rely on the `AD` bit for DNSSEC verification, they are using the protocol as it was designed. That's what the bit is there for. The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
You can see that this fully-recursive verification thing isn't what the DNSSEC designers want just from the fact that they themselves attempted to solve this problem, over a decade ago, with TSIG (iirc; it might have been a different weirdo DNS subprotocol). There was an actual stub-to-server DNS protocol. Nobody uses it because nobody in the real world cares about DNSSEC.
What you're really saying is that Linux nerds can just run their own DNS servers. They can! But we don't design global Internet security to serve people who want to sysadmin their own phones. It has to work for normal people.
You mentioned yourself that DNSSEC can be activated automatically by registries, like what has been done in Europe, so I don't really see that as being an issue.
Sure, you can fuck up if you start messing around with DS records and whatnot, like Slack did (and BTW, they're still using DNSSEC even after experiencing that outage), but once you start messing around with DNS you can also fuck up in many other ways that have nothing to do with DNSSEC. So that is not really a problem with DNSSEC itself.
> The protocol was designed to trust the link between the OS stub resolver and the DNS server, because it was designed in 1995 when even small networks ran and trusted their own BIND servers.
Sure, but we're not in 1995 anymore, so there's no issue with running a resolver with DNSSEC validation at the client level anymore.
> What you're really saying is that Linux nerds can just run their own DNS servers.
No, I'm saying OS manufacturers like Google, Apple and Microsoft can implement DNSSEC validation on the DNS resolvers of their OSes, just like Google implemented DNS-over-HTTPS transport (which also wasn't an option in 1995).
> But we don't design global Internet security to serve people who want to sysadmin their own phones.
Fortunately, that's not what I'm proposing.
> It has to work for normal people.
Agreed :)
* The increasing salience of multi-perspective verification at CAs (LetsEncrypt won't depend on a single DNS response to domain-validate a certificate request, but will distribute that request to resolvers around the world and make sure they agree with each other).
* The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates --- instead of doing a weird DNS dance, you can just ask the registrar directly.
* The design and deployment of MTA-STS, the HSTS-style TLS continuity protocol for SMTP; SMTP is basically the final use case for DNSSEC, where DNSSEC can serve as a signaling mechanism to ensure that SMTP connections actually use TLS and aren't negotiated down to plaintext by a MITM. MTA-STS was designed specifically to replace DNSSEC for this use case, by the major email providers.
* The ironic increase in domain takeover attacks --- ironic because they're overwhelmingly (probably universally?) done by compromising registrar accounts rather than playing games with the DNS protocol, such that even after a forklift upgrade to enable DNSSEC, we'd still mostly have the same DNS security problem.
* The mass adoption of DNS-over-HTTPS, which is "bottom-up" DNS security that (unlike DNSSEC) protects the "last mile" between browsers and the DNS servers they talk to; in a world where most users talk to just a couple trusted DNS resolvers, all of which speak DoH, DoH might be all the DNS security we need?
* The rise in BGP4 takeover attacks, which completely bypass name resolution altogether; as these attacks continue to mainstream, they too strike right at the heart of the problem DNSSEC was supposed to solve.
* The incredibly bad track record DNSSEC has for reliability; for instance, Slack had a multi-hour total sitewide outage earlier this year that came from attempting to turn it on. This was predicted --- it's predicted in the "Against DNSSEC" post! --- and it's come to pass: DNSSEC is easy to screw up, easier than TLS, and when you screw DNSSEC up, your site falls of the entire Internet without warnings.
* The success of Certificate Transparency and CA surveillance in the WebPKI, to the point where the largest and most commercially important CAs were actually ripped out of browsers after surveillance systems detected misissuance. Also, the most trusted CA on the Internet in 2022 is... free? The WebPKI of 2022 is just not the WebPKI of 2015.
Against this backdrop, the important thing to know about DNSSEC is that it is simply not widely deployed; you can quickly measure this by taking any list of the top domains (the "Moz 500" is an easy-to-download version) and then feeding it through dig:
for DOMAIN in $(cat list); do
dig ds $DOMAIN +short
done
I see a much different (and worse) opportunity cost to DNSSEC: if we stick a fork in it, we can get to work on something better. I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Maybe DNS is worth protecting anyways! Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
At any rate: I feel like the ~8 years since I wrote this post have pretty much totally vindicated my argument. I felt a little like I was going out on a limb when I wrote it. Now I feel like the argument is pretty banal. :)
Just one place to go to for all those TLDs. ccTLD support is hit or miss.
Also good info here: https://about.rdap.org
That doesn't protect against attacks from occurring, it only protects against future attacks from the same people who already attacked (assuming the same people don't create a new CA?).
And when Chrome and Mozilla distrusts a new CA, good luck on updating the certificate chains included in the operating systems of all the devices in the world, especially those that never update (old Android phones? IoT devices?).
> there's no way to revoke .COM
I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
> I think there is no need to revoke .COM because .COM can attack any domain within .COM anyway, even with/without DNSSEC and/or with/without CAs? Or what am I missing?
The point is you don't build a system that assumes DNS is trustworthy, because it isn't.
But the current CA PKI system already assumes DNS is trustworthy, even much more than if you were using DNSSEC-protected DNS PKI system, since it is not only vulnerable to almost all the same attackers/attacks, but it is also vulnerable to many more attackers (since any CA can also do an attack at any time, regardless of any possible future consequences it may experience or not).
If they are caught — and CT has made that very likely, but hijinks like in Kazakhstan sidestep CT.
Why do you seem to always be talking like if DNSSEC is incompatible with other security technologies?
DNSSEC isn't incompatible with DoH either, but you also seem to be implying that we need to only use one or the other?
I'm not trying to be a jerk, I'm just saying, this thing you're talking about doesn't exist. Moreover: it's unlikely ever to exist. CT didn't get rolled out because the CA's wanted CT; I assume they actively detest it (other than LetsEncrypt). CT got rolled out because the browsers required it. The browsers have no leverage to make the DNS PKI do anything, because, once again, they can't revoke .COM.
With WebPKI we have multiple mutually-distrusting parties keeping each other in check. It has become a better system.
It's not more power, it's the same power it already has!
This too-big-to-fail monopolist you're talking about can already hijack your domain, regardless of whatever WebPKI does.
> CAs have been doing shady stuff before CT and there's no reason why they wouldn't resurrect MITM-for-cash business given DANE.
Sorry, but I don't follow. Given DANE, CAs wouldn't even exist.
Unless you're talking about the transition period, which would be strictly better than what we have now, because the not-yet-transitioned domains would use WebPKI like today, while the already-transitioned domains would use DANE which has superior guarantees.
I'm not talking about transition period. DANE makes TLD owners effectively a CAs. The technical details are different, but the role of root-trust-anchored private-key-holding ownership-attesting authority is the same. And unlike WebPKI CAs, browsers can't remove DNSSEC roots for abuse of trust.
DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up. This isn't just a technical problem of a protocol for securing packets. It's also a meta problem of ensuring the organizations involved behave in a trustworthy way, even when it would be profitable to cheat, even when NSA and other 3-letter agencies put pressure on them.
And then what? Like you said, browsers can't remove Verisign for abuse of trust, because Verisign isn't part of their roots of trust.
And they can't remove the certificate authority who issued the certificate because 1) the certificate authority is not at fault in that scenario, and 2) Verisign could just use another one to issue a new certificate.
Whatever answer you give here would apply to DANE as well.
> If DANE was used, they could do whatever they want
See above: they can already do whatever they want, so you wouldn't be leaning on them more than you are right now.
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
We already have a centralized system of trust, called the DNS system. It's just that currently it is still relatively insecure (DNSSEC is not widely deployed yet), so we have another fake security layer on top of it (the CA PKI system) which, because it's backed by Google and other organizations that people like so much, for some reason people trust that layer even though its security depends on the security of DNS and is actually even more flawed (since it has even more points of attack).
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
You can implement a CT-like system on top of it which would give you more transparency regarding what certificates are being used (where clients, rather than certificate authorities, would publish new certificate fingerprints to CT logs or even directly to some server managed by the domain owner).
But of course, the real issue is how to deal with Verisign if it starts hijacking domains, but this is already exactly the same problem we have today with the CA PKI system.
You have to understand how CT works before you (a) dismiss it, like someone else did upthread when they claimed CAs can just ignore CT, or (b) assume it trivially ports over to DNS.
[citation needed]
> It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates.
So? In a DNS PKI system, browsers would already distrust ALL CAs. So by that argument, it's in a much better footing to begin with.
What's happening is that you're thinking that in a DNS PKI system, TLD operators like Verisign would be equivalent to certificate authorities.
Except that they wouldn't, because Verisign couldn't create rogue certificates for other TLDs like certificate authorities can. And even if Verisign could create rogue certificates for .COM domains, this is already something that they can do today with the WebPKI system in place, since they can hijack any .COM domain at any time.
And even if Verisign is caught hijacking a domain to create rogue certificates with the WebPKI system, the browsers can't do anything about it, because Verisign is not part of their roots of trust.
So basically, you wouldn't be any worse than today (because Verisign can still attack your domain, regardless) but you'd certainly be much better, because you wouldn't have to keep a database of certificate authorities from all over the world who can create certificates for any domain in the entire world.
Oh, by the way, we're talking about a database of fully-trusted authorities that even if they are caught in any wrongdoing, can never actually be distrusted (like you mention) in hundreds of millions of deployed systems out there who might take months or even years to update, or worse, who never update (Android devices, IoT devices, etc).
All you're saying at this point is that CT doesn't, in your opinion, matter. But now you're contradicting your own argument, which was, previously, that DNSSEC can easily copy CT to do DNS PKI transparency.
In fact, a certificate transparency-like system for DNS PKI would probably be a lot easier and more scalable to implement, as you'd need to store a log of at most 1 DNSKEY and/or DS records per TLD per day (as per their usual TTL), or much less actually, because those DNSKEYs don't actually change often, I believe.
You don't even need the TLDs' cooperation to do it, as those public keys are publicly available, unlike certificates issued by certificate authorities!
You'd then need a way to check that the keys match what you've got from the upstream DNS server. You could probably implement this at the DNS server and DNSSEC resolver level. You'd return an error if the keys that you've got aren't available in the log. You could discard old keys, so a locally-stored copy of the log would be really small and wouldn't keep growing indefinitely.
The point is, something like this would be doable and has nothing to do with all the other points I've been making which are a lot more important.
Well, that's the entire point of the log, isn't it? To make sure that everybody is seeing the same keys.
If the keys you got from the upstream link in the DNS chain doesn't match the one in the log, you reject them, because you are being spoofed.
> to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency > now that you've learned that Certificate Transparency won't work for DNSSEC
It wouldn't work exactly like it is, obviously, which is why I've been saying "CT-like" system, not the exact same CT incantation that exists right now which was explicitly designed for WebPKI, not a DNS PKI.
Your argument is like saying in the year 2002: "electric vehicles can't possibly work because gas stations are not designed for electric vehicles". Well, not exactly a sound argument you have there, now is it? :)
> You've vindicated my argument.
I highly doubt that :)
TLS itself is used for securing almost every network communication that goes over the Internet nowadays, including SMTP (and even DNS with DNS-over-TLS or DoH, ironically).
So how does Mozilla notice that a CA misissued a certificate for my SMTP server or my upstream DNS server? (Answer: it doesn't).
Specifically, what kind of attack would a TLD owner be able to perform on a domain that uses DANE that they wouldn't be able to perform if the domain weren't using DANE?
Of course those "couple trusted DNS resolvers" (and all the ones operated by enthusiastic "Home labs" types) need to know whether the answers are trustworthy, otherwise we're just centralising the problem not fixing it.
You're a smart person so I'm sure you guessed what the canonical solution is, it's DNSSEC.
> The potential inclusion of RDAP, the successor to Whois, as a mechanism for verifying domain ownership for certificates
This is technology, wishful thinking won't move the bar. ACME RDAP isn't a thing, doesn't appear to have even a draft, don't think it was even discussed. So this "potential" seems rather nebulous. RDAP is a cute trick, it'd be nice if it someday displaces WHOIS properly but it doesn't really have great applicability to this problem.
> explore alternate models with clearer, more realistic trust models.
I have experience with the "Surely anything would be better than this" crowd, they voted for Brexit. You presumably don't need to ask how that's going since I believe in your country they voted for Trump.
What you're saying here is, "if you do bottom-up DNS security, all you know is that the links were secure; you still don't know if the data was authentic". Sure, but that's not dispositive, because:
(a) Bottom-up DNS security can continue to succeed to the point where it links resolvers and caches to authority servers
(b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
So, I guess what I'm saying is that it's clear on it's face that there's no "canonical solution" to this problem; there's a solution space. DNSSEC advocates have been telling us for (checks notes) 27-28 years that DNSSEC is "the canonical solution" to DNS security. The information security field has ignored the DNSSEC advocates, and, I'd argue, largely vindicated themselves in that approach.
Britain, for what it's worth, was already a member of the EU when they voted for Brexit. The circumstances of DNSSEC are not similar. It's a weird, inapposite emotional appeal either way, but the premise fails, too.
Even if that would happen, the client would have no way to know if all the links were indeed secured. And even it would know it, it would have no way to know if any of the resolvers in those links forged a DNS response.
With DNSSEC the client can verify that the response is indeed authentic.
> (b) Regardless of whether it does, the costs attackers incur against DoH-protected hosts might be wildly higher than the benefits (the risk-of-failure-adjusted value of a misissuance via a DNS attack).
Actually, it can be profitable for the DoH-protected hosts themselves to forge DNS responses, no attacker is needed. There are many consumer ISPs that do that already to display advertisements, collect statistics or straight up hijack domain names (e.g. due to piracy laws). DoH does nothing to prevent that, while a client resolver with DNSSEC support does protect against that.
In fact, DNSSEC can work just as well with DoH, which is what I do on my laptop. These two technologies are not mutually exclusive and I see no reason why we can't use both at the same time.
This just isn't a real problem.
If the client expected all the links to be secured (which is what you propose with a bottom-up security model) and if it would know whether they are or not, then it could fail to resolve if any link is not currently secured, if the user so desired.
In your bottom-up security model proposal, this would protect against any external man-in-the-middle attack in the entire chain (but not an attacker within the chain).
If the client doesn't know if all links are secured, then it is vulnerable as long as any link in the chain can be attacked (except for its own link), not to mention of course, by attackers within the chain as well. Since it has no way to know whether it was attacked or not, it has no way to prevent forged responses.
> DNS data is either hard to spoof (even now, that's the case)
It's really not hard. Otherwise, this page wouldn't list ongoing cases that affect millions of users right now, every single day:
https://en.wikipedia.org/wiki/DNS_hijacking
> if it wasn't for the fact that all of DNSSEC security collapses down to a single, resolver-controlled header bit on the link between your browser and your DNS server.
Maybe on your system, not mine.
If you use a local caching resolver with DNSSEC support (and why wouldn't you, unless you're using a microcontroller with close to zero resources?) then no application on your local system will get a forged response from domains with DNSSEC support (unless it was attacked at the source, origin DNS server or at the TLD level, of course, no way to prevent that), regardless of what your DNS server does or pretends to be doing, or any other DNS server in the chain, or even an external attacker that tries to attack any link in the chain, for that matter.
You could also implement a DNS resolver with DNSSEC support on your browser, if you really wanted. But a local caching resolver is an even more generic solution, as it protects all local applications, not just your browser.
Second: whatever weird thingy your system does, I respect it, but it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon. People love to point out that they can just run their own DNS server on their Linux box, which is obviously true, because that's how ISPs run DNS servers, too. I'm suitably impressed with your sysop ability, but I don't know what that has to do with Internet security.
Both DNSSEC and DoH can protect against DNS hijacking. DNSSEC can give you end-to-end protection if you use a DNSSEC-enabled resolver and the domain supports DNSSEC, while DoH can only protect one link in the chain, no matter what you do.
> whatever weird thingy your system does, I respect it
What is weird about running a local caching resolver? Most modern Linux systems do that, as far as I know. I simply use one that does DNSSEC verification by default.
I don't see why Android/iOS phones or Windows systems wouldn't be able to do that by default in 2022, if their developers really wanted to implement that.
> it is simply not the case that millions of mainstream users are going to run fully recursive DNS caches on their phones and laptops any time soon.
Yeah, not with that attitude :)
That no mainstream operating system in the world does this is all the evidence I need to dispose of this part of the argument.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.
It's neither "top down" nor "bottom up", it's horses for courses. (Is that phrase clear? I have a feeling it might not translate but I'm not sure what the equivalent is in American)
From my reading of dnsop the IETF isn't likely to reach consensus on how authoritative traffic should do encryption anytime soon. Remember DoH and DoT for stub to resolver traffic happened because of the browser people, not the DNS people. Unfortunately the browser people don't have the same leverage elsewhere, or we'd have seen more come from the Cloudflare/Facebook DoT experiment by now.
I don't particularly want to defend DNSSEC here but Slack picked Route 53, who both have had and continue to have well known compliance issues with DNS, and they expected them to get DNSSEC right. I'm a little surprised it's gone as well as it has and that they still have DNSSEC on.
Apple's recent revisiting of DNSSEC is possibly the only glimmer of hope for more mainstream adoption of DNSSEC. Their software's got a large installed base and their API is opt-in for DNS consuming software. It'd be nice if more DNSSEC implementations made DNSSEC opt-in but the evangelical DNSSEC set wouldn't abide that.
> I think we've more or less established that a top-down government-controlled PKI is not the future of Internet security. Ending the 26-year DNSSEC boondoggle would free us up to explore alternate models with clearer, more realistic trust models.
I don't think that's clear at all. What is clear is that the DNS hasn't moved much in that period and that the only things that have been adopted are things that authorities and resolvers can silently implement. Putting a fork in DNSSEC won't change much. At this point whatever replaces DNS will be how this space gains some security.
It was actually from turning it _off_, relying on expert advice that turned out to be incorrect:
>Our Traffic team was confident that reverting the DS record published in MarkMonitor was sufficient to eventually resolve DNS resolution problems. As things were not getting any better, and given the severity of the incident, we decided to rollback DNSSEC signing in our slack.com authoritative and delegated zones, wanting to recover our DNS configuration to the last previous healthy state, allowing us to completely rule out DNSSEC as a problem.
>As soon as the rollback was pushed out things got much worse; our Traffic team was paged due to DNS resolution issues for slack.com from multiple resolvers across the world.
>Based on expert advice, our understanding at the time was that DS records at the .com zone were never cached, so pulling it from the registrar would cause resolvers to immediately stop performing DNSSEC validation. This assumption turned out to be untrue. The ‘.com.’ zone will ask resolvers to cache the slack.com DS record for 24h by default (non modifiable by zone owners). Luckily, some resolvers cap that TTL with a lower value (i.e. Google’s 8.8.8.8 has a 6h TTL on DS records).
https://slack.engineering/what-happened-during-slacks-dnssec...
All DNSSEC gives you is a false sense of security as you merrily validate signatures on spoofed records because they're generated by the same people who own the DS record responses.
And what happens when you (and everyone else) finds out you can no longer trust DNSSEC signatures on .com.? Stop using all of .com?
> but the power lies with the configuration of a device's DNS resolver. Any recursive resolver is free to configure other root servers (e.g. OpenNIC).
How does OpenNIC know how to answer the question "where is ycombinator.com"?
As opposed to the current system, which also gives you a false sense of security while being vulnerable to exactly the same .COM attack, but also to even more types of attacks?
Furthermore, what we build on top of DNS and which is supposed to protect from DNS attacks and does claim to be secure, like the CA PKI system, actually depends on DNS to be secure (which it isn't) in order to obtain the certificates. Not to mention the CA PKI system also depends on all certificates authorities in the entire world to be well-behaved.
Presumably the CA would have to have published an entry to the CT log for this certificate. This would allow browsers to verify that the certificate generated by the attacker can be trusted and therefore it could be used by the attacker to perform a man-in-the-middle attack on the Gmail interface against any user in the entire world, without anyone noticing it during the attack.
Some time after the attack has already occurred, Google or someone else would presumably notice that the certificate wasn't actually created by Google, even though everything was correctly published in the CT logs like it was expected for any other normal certificate (I'm being very generous here, multiple companies don't even notice their domains are about to expire until it's too late, including Microsoft).
At this point, it would be expected for browser vendors like Mozilla and Google to distrust this CA because they would assume the CA generated a certificate for a Google domain fraudulently. However, the CA wasn't actually the perpetrator of the attack but it also couldn't prove that it wasn't, and since the browsers don't trust them anymore, the innocent company would be ruined and all their employees would be fired and become miserable.
Meanwhile, hundreds of millions or possibly billions of devices (like Android smartphones) who don't update their system software for months or years (or even never) would still have the now-bankrupt CA in their certificate root stores for a very long time (remember, not all certificate root stores are managed by browsers, some are installed at the OS level), so the attacker could still keep attacking these devices, almost indefinitely, without any issue (especially if he repeats the attack, which he can do indefinitely, ruining many CAs until he somehow got caught).
This is all assuming we're talking about a certificate for an HTTPS server, which is the best case scenario.
If we're talking about a certificate for an SMTP server or a DNS server then the problem is even worse, not in this exact scenario, but in the scenario where one of the many certificate authorities behaves maliciously and generates a fraudulent certificate itself (signing it) but doesn't publish an entry to a CT log, so the attack would never be noticed because SMTP servers and DNS servers don't check SCTs.
However, it's the system we've got. Unless you do some kind of on-the-fly domain generation or an outdated DNS registrar, it's quite easy to enable and it helps prevent all kind of weird DNS malarkey for those that care about their internet security.
2. It's not quite easy to enable it. Evidence for that position: the litany of stories where companies have tried to enable it, like Slack did, and had multi-hour worldwide outages as a result.
Good times.
Seen more than one org disable dnnsec, in bind, because of this.
Authenticated time synchronization faces intrinsic dilemmas no matter the technology.
Sigh.
2. All I needed to do was enable a checkbox and paste a key (that I generated myself because I didn't want to hit the "generate" button) so I know it can be easy. Most companies aren't Slack or Google with their custom resolver setups and complicated cloud configurations.
Other note is I've had exactly two people who it prevented from using a site. One was at a coffee shop and another in a hospital where I assume they both were rewriting DNS for some reason.
> Not with any attitude: what you and the phone sysadmins propose is, effectively, to eliminate all shared DNS caching from the Internet. A beautiful dream! But that's all it is.
No, a local caching resolver (with or without DNSSEC verification enabled by default) would talk to the upstream DNS server by default, like a stub resolver, so it benefits from the upstream DNS server cache.