DNSSEC Would Not Help Prevent Microsoft’s Seizure Of Domains(internetsociety.org)
internetsociety.org
DNSSEC Would Not Help Prevent Microsoft’s Seizure Of Domains
http://www.internetsociety.org/deploy360/blog/2014/07/no-dnssec-would-not-help-prevent-microsofts-seizure-of-domains/
28 comments
> DNSSEC does one task extremely well – but it does only this one task:
[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
[3] http://ianix.com/pub/dnssec-outages.html
DNSSEC ensures that the information the operator of a
domain[..] put into DNS is the exact same information
that a user gets out of DNS when they request info for
a domain.
DNSSEC suggests a complicated mechanism to essentially re-create many of the
same problems with X509 and CAs in DNS itself, by providing a chain of trust
to untrustworthy entities. Its intended goal is to secure DNS and thereby
assure clients that when they ask for apple.com, they are actually visiting
apple.com. This proposal does not protect against MITM attacks [2]. It suffers
from extreme and unnecessary complexity, a systemic fault that's antithetical
to secure systems. See also this list of resources on why DNSSEC is considered
harmful [3].
[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...
[3] http://ianix.com/pub/dnssec-outages.html
I'm a bit confused by the text you quote. DNSSEC does protect against MITM attacks. That is specifically what it is designed to do. Unless I am missing something (which could be), the article you reference as "[2]" does not seem to support the idea that DNSSEC doesn't protect against MITM attacks. The mentions specifically how DNSSEC and DANE can protect against those attacks, although the article then discusses the author's issues with trusting the parties involved in the chain of trust.
For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together.
I also like that there are other systems out there like okTurtles and Convergence looking at other alternative mechanisms for securing naming. It's good to have many different systems that in the end can lead to a more secure Internet.
For my part, I like the mechanism provided by DANE/DNSSEC because it puts me, as the DNS operator, in control of what TLS cert I want to publish. I can publish my own self-signed cert. I can publish a CA-signed cert (or a fingerprint). I can say that I only support TLS certs from a specific CA. I can designate my own trust anchor for the TLS certs coming from my site. I can publish those certs (or fingerprints) in TLSA records and have them then validated up the global chain of trust. I like how the system is put together.
I also like that there are other systems out there like okTurtles and Convergence looking at other alternative mechanisms for securing naming. It's good to have many different systems that in the end can lead to a more secure Internet.
DNSSEC merely attempts to protect against one MITM attack out of many many possible MITM attacks. In particular: DNSSEC doesn't even protect against DNS-based MITM attacks between browsers and DNS servers.
DANE does not put you as the DNS operator in control of what TLS cert you want to publish (TACK would do that, without requiring any change to the DNS hierarchy whatsoever.) Rather, DNSSEC adds you to a larger set of people who would have the ability to govern what TLS cert applies to your domain; everyone on the DNS hierarchy back up to the root would effectively have the same ability. In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. How could that possibly be a win?
DANE does not put you as the DNS operator in control of what TLS cert you want to publish (TACK would do that, without requiring any change to the DNS hierarchy whatsoever.) Rather, DNSSEC adds you to a larger set of people who would have the ability to govern what TLS cert applies to your domain; everyone on the DNS hierarchy back up to the root would effectively have the same ability. In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were. How could that possibly be a win?
> In a DNSSEC/DANE world, if you have a .LY name, the government of Libya would have a say in what your TLS certs were.
Please explain to me how this would be possible?
- I sign my .LY domain with DNSSEC and create the appropriate DNSKEY and RRSIG records.
- I create a DS record with a fingerprint of my DNSKEY and via my registrar (typically) upload this DS record to the TLD registry (.LY in this case).
- Additionally, I create a TLSA record in my zone that holds my TLS cert and sign that with my key (creating the associated RRSIG record).
When someone is querying DNS using a DNSSEC-validating DNS resolver, the resolver:
----
1. Gets my DNS records (A, AAAA, MX, TLSA, whatever) from the authoritative name server for my domain (let's assume I operate it), along with the associated RRSIG and DNSKEY records.
2. Gets my DS record from the .LY registry, along with the RRSIG and the DNSKEY for the .LY registry.
3. Gets the DS record for .LY from the root zone, along with the RRSIG and the DNSKEY for the root zone.
4. Presumably has the root's trust anchor already stored.
5. Validates that my DNSKEY has the same fingerprint as that in the DS record received from the .LY registry - and walks back up the chain of trust to ensure that all DS records and DNSKEYs match.
----
Where in there can the government of Libya have a say in what TLS certs I offer?
The best I could see is that the operator of the .LY registry could choose to modify or remove my DS record, which would then mean that my domain would fail DNSSEC validation. But the TLSA record is still coming from my site. All the .LY registry can do is potentially remove the link to the chain of trust.
I really would like to know if I am missing something here.
Please explain to me how this would be possible?
- I sign my .LY domain with DNSSEC and create the appropriate DNSKEY and RRSIG records.
- I create a DS record with a fingerprint of my DNSKEY and via my registrar (typically) upload this DS record to the TLD registry (.LY in this case).
- Additionally, I create a TLSA record in my zone that holds my TLS cert and sign that with my key (creating the associated RRSIG record).
When someone is querying DNS using a DNSSEC-validating DNS resolver, the resolver:
----
1. Gets my DNS records (A, AAAA, MX, TLSA, whatever) from the authoritative name server for my domain (let's assume I operate it), along with the associated RRSIG and DNSKEY records.
2. Gets my DS record from the .LY registry, along with the RRSIG and the DNSKEY for the .LY registry.
3. Gets the DS record for .LY from the root zone, along with the RRSIG and the DNSKEY for the root zone.
4. Presumably has the root's trust anchor already stored.
5. Validates that my DNSKEY has the same fingerprint as that in the DS record received from the .LY registry - and walks back up the chain of trust to ensure that all DS records and DNSKEYs match.
----
Where in there can the government of Libya have a say in what TLS certs I offer?
The best I could see is that the operator of the .LY registry could choose to modify or remove my DS record, which would then mean that my domain would fail DNSSEC validation. But the TLSA record is still coming from my site. All the .LY registry can do is potentially remove the link to the chain of trust.
I really would like to know if I am missing something here.
The TLSA record is going to come from wherever the DNS hierarchy says it should come from.
The A or AAAA record is also going to come from wherever the DNS hierarchy says it should come from. If one of the organisations upstream from you in the DNS hierarchy decides they want to police what TLS certificates sites can use by hijacking the sites' DNS and pointing it to their own servers, they can do that just as easily regardless of whether those certificates come from DNS or the traditional CAs. Once they've hijacked the domain, any major CA will happily automatically issue them a valid certificate for it.
So to your point you would see the attack being that the .LY registry would change the NS records for my (fictitious) .LY domain to point to a different set of name servers? i.e. removing my servers as the authoritative ones? And then being able to serve out whatever records they want to? (including a TLSA)
Is THAT the attack you see?
Is THAT the attack you see?
If you have a Libyan domain name, the entity responsible for Libyan domain names can also transfer or shut down your domain. What does that have to do with DNSSEC? Nothing.
With DANE you trade a model where 300 CAs around the world each acting alone have the ability to falsify your certificate, to one where you and your top domain do. That's a big win in every which way you look at it.
(It is also worth nothing that control over the domain name implies the power to generate valid certificates not only in DANE but also in today's CA model and most of the competing systems.)
TACK and other systems may or may not help. We don't know until it has been throughly peer reviewed. Most models like it turned out to be vulnerable to a Sybil attack, or be based on plain TOFU.
DNS-based MITM attacks between clients and validators is a red herring. The standard has assumed local validation for many years now.
With DANE you trade a model where 300 CAs around the world each acting alone have the ability to falsify your certificate, to one where you and your top domain do. That's a big win in every which way you look at it.
(It is also worth nothing that control over the domain name implies the power to generate valid certificates not only in DANE but also in today's CA model and most of the competing systems.)
TACK and other systems may or may not help. We don't know until it has been throughly peer reviewed. Most models like it turned out to be vulnerable to a Sybil attack, or be based on plain TOFU.
DNS-based MITM attacks between clients and validators is a red herring. The standard has assumed local validation for many years now.
If we used a blockchain based DNS system, we would never have this problem in the first place because we would be unable to take down malicious domains.
That is a good thing. No need to take down a malicious domain name, just like malware, add it to a blacklist (Google's Chrome already does this).
The whole point of DNS is that we don't have to pass lists of domain names around, like we did before DNS.
Erm, one is a lookup table for arbitrary (and unknown) names, the other is a blacklist. These are two very different things (the latter is perfectly practical and manageable).
But why wouldn't a blacklist of people trying to game the system be unmanageably huge?
> But why wouldn't a blacklist of people trying to game the system be unmanageably huge?
First, you don't have to leave every entry on the list until the end of time. At some point (possibly as a result of the domain being on the blacklist) the attacker is going to discontinue using it and it could then be removed. Second, you don't have to store the blacklist on every client device.
You could even just integrate it with the DNS. If you want to know if foo.com is on the blacklist, you do a lookup for foo.com.blacklist.google.com and if that resolves then it's blacklisted. If you don't trust Google to maintain the blacklist then you change a setting and your computer looks up foo.com.blacklist.microsoft.com or foo.com.blacklist.spamhaus.org or whatever else instead.
The point is to decentralize the decision of who maintains the blacklist, so that users can stop using a blacklist if its maintainer makes unpopular decisions.
First, you don't have to leave every entry on the list until the end of time. At some point (possibly as a result of the domain being on the blacklist) the attacker is going to discontinue using it and it could then be removed. Second, you don't have to store the blacklist on every client device.
You could even just integrate it with the DNS. If you want to know if foo.com is on the blacklist, you do a lookup for foo.com.blacklist.google.com and if that resolves then it's blacklisted. If you don't trust Google to maintain the blacklist then you change a setting and your computer looks up foo.com.blacklist.microsoft.com or foo.com.blacklist.spamhaus.org or whatever else instead.
The point is to decentralize the decision of who maintains the blacklist, so that users can stop using a blacklist if its maintainer makes unpopular decisions.
It could be "unmanageably huge" for clients, just like the blockchain itself is unmanageably huge for clients. This is the reason DNSChain is designed the way it is (having a personal, dedicated server to store the blockchain for "groups of friends"), thus allowing many client devices to send it arbitrary queries.
Perfect use case for a Bloom filter.
No need for a blacklist either, I don't believe there's been a single example of a malware using a purely DNS based C&C (e.g by utilizing TXT records) instead of using DNS to get the IP address for the C&C server.
Of course there's always an exception, in this case there exists DNS beacons included in pentesting suite Cobalt Strike, but that doesn't seem to be something widely used.
Of course there's always an exception, in this case there exists DNS beacons included in pentesting suite Cobalt Strike, but that doesn't seem to be something widely used.
But is that a good thing? Being "unable to take down malicious domains"? I don't know. There is a part of me that wants to protect against this ability to take down domains - and another part of me that says if there were domains spewing malware and facilitating botnets I'd like to see them taken down somehow.
[deleted]
While this article serves its intended purpose ("No, DNSSEC wouldn't help here"), I find it disappointing that it takes very little time dismissing the possibility of a technical solution preventing the hijacking ("legal" or otherwise) of a domain.
It seems unlikely that a technical solution based on the existing DNS infrastructure could prevent hijacking, but that doesn't make it impossible to design a naming infrastructure resilient against such attacks. There do exist at least some proof-of-concept technical solutions that would work, such as those based on blockchains; a production solution hardly seems impossible.
It seems unlikely that a technical solution based on the existing DNS infrastructure could prevent hijacking, but that doesn't make it impossible to design a naming infrastructure resilient against such attacks. There do exist at least some proof-of-concept technical solutions that would work, such as those based on blockchains; a production solution hardly seems impossible.
I wonder if most domain owners would want a system where it was not possible for a domain to be transferred against the owner's will?
As long as it is possible for domain owners to transfer ownership, it is possible to have your domain stolen if you have a security lapse that allows someone to impersonate you. If there is no mechanism to force a transfer back, then victims of that kind of domain theft will have no recourse other than to convince the thief to give it back.
I suspect that for most of us, getting hacked and impersonated would be the most likely way we would lose our domain.
As long as it is possible for domain owners to transfer ownership, it is possible to have your domain stolen if you have a security lapse that allows someone to impersonate you. If there is no mechanism to force a transfer back, then victims of that kind of domain theft will have no recourse other than to convince the thief to give it back.
I suspect that for most of us, getting hacked and impersonated would be the most likely way we would lose our domain.
> As long as it is possible for domain owners to transfer ownership, it is possible to have your domain stolen if you have a security lapse that allows someone to impersonate you. If there is no mechanism to force a transfer back, then victims of that kind of domain theft will have no recourse other than to convince the thief to give it back.
This is the kind of situation where you need something that will make your life hard only in proportion to the amount that you screwed up. See if you can find anything seriously wrong with the following.
Let's add a DNS record called change key. This record goes wherever there is a delegation to another nameserver. The change key signs the delegation without any timestamp and clients and resolvers cache the change key for a year. Every time the name is successfully resolved, the client resolves the change key again and resets the cache period back to a full year. The change key's corresponding private key doesn't go on any servers, it goes in a fire safe. If your servers get compromised you get out the change key, sign a revocation of the old delegation, sign the new one, and put it back in the fire safe. If you want to replace the change key (e.g. because the key length is now considered short) then you can sign the new one with the old one and present that signature to clients for a year. If you lose the change key then you can put a new one in the parent domain but no one will trust it for a year, in the meantime you can keep using the certificates signed by the old key, but for the next year you can't change the delegation and DNS resolvers will be writing errors to their logs telling the admins to investigate. If the change key is compromised then you're screwed for a year, but that's why it's offline in a locked container.
The result should be that you can't forge a delegation without anyone noticing. You can take the domain offline by just refusing to serve any records for it, you can reassign it after taking it offline for a year, you can't immediately point it somewhere else. That seems like a pretty good compromise.
This is the kind of situation where you need something that will make your life hard only in proportion to the amount that you screwed up. See if you can find anything seriously wrong with the following.
Let's add a DNS record called change key. This record goes wherever there is a delegation to another nameserver. The change key signs the delegation without any timestamp and clients and resolvers cache the change key for a year. Every time the name is successfully resolved, the client resolves the change key again and resets the cache period back to a full year. The change key's corresponding private key doesn't go on any servers, it goes in a fire safe. If your servers get compromised you get out the change key, sign a revocation of the old delegation, sign the new one, and put it back in the fire safe. If you want to replace the change key (e.g. because the key length is now considered short) then you can sign the new one with the old one and present that signature to clients for a year. If you lose the change key then you can put a new one in the parent domain but no one will trust it for a year, in the meantime you can keep using the certificates signed by the old key, but for the next year you can't change the delegation and DNS resolvers will be writing errors to their logs telling the admins to investigate. If the change key is compromised then you're screwed for a year, but that's why it's offline in a locked container.
The result should be that you can't forge a delegation without anyone noticing. You can take the domain offline by just refusing to serve any records for it, you can reassign it after taking it offline for a year, you can't immediately point it somewhere else. That seems like a pretty good compromise.
This still allows domain hijacking, just with more lag, and it has the failure mode "You are screwed for a year." As far as I can tell, this essentially makes touching DNS at all more onerous, but does not make theft particularly onerous compared to the burden added onto everything else.
This is where, for some people, "It won't happen to me" attitudes guide the policies they advocate.
Why would I care if stolen domains aren't recoverable? I'm too smart, nobody will be able to steal mine
Why would I care if stolen domains aren't recoverable? I'm too smart, nobody will be able to steal mine
On the site where I wrote this article the scope is to talk about DNSSEC deployment (and deployment of other technologies such as IPv6). Given those parameters, I have limits on what I can talk about in terms of other technical solutions. However, if someone wants to write an article on some other site about other potential technical solutions it may be something I can link to from an update to the post.
Technical notes aside, I still don't get how a private entity obtained the right to do law enforcement for their own interest, wrecking another business in the process.
https://github.com/okTurtles/dnschain/blob/master/README.md#...