DNSSEC Would Not Help Prevent Microsoft’s Seizure Of Domains
internetsociety.org
internetsociety.org
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.
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.
Why would I care if stolen domains aren't recoverable? I'm too smart, nobody will be able to steal mine
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.
https://github.com/okTurtles/dnschain/blob/master/README.md#...
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...
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.
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?
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.
Is THAT the attack you see?
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.
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.
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.