
DNSSEC Would Not Help Prevent Microsoft’s Seizure Of Domains - danyork
http://www.internetsociety.org/deploy360/blog/2014/07/no-dnssec-would-not-help-prevent-microsofts-seizure-of-domains/
======
JoshTriplett
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.

~~~
tzs
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.

~~~
AnthonyMouse
> 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.

~~~
chc
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.

------
itistoday2
The blockchain, on the other hand, would:

[https://github.com/okTurtles/dnschain/blob/master/README.md#...](https://github.com/okTurtles/dnschain/blob/master/README.md#DNSChain)

~~~
dsl
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.

~~~
itistoday2
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).

~~~
sp332
The whole point of DNS is that we don't have to pass lists of domain names
around, like we did before DNS.

~~~
itistoday2
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).

~~~
sp332
But why wouldn't a blacklist of people trying to game the system be
unmanageably huge?

~~~
AnthonyMouse
> 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.

------
mariuolo
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.

