DHS Wants Master Key for DNS

An anonymous reader writes "At an ICANN meeting in Lisbon, the US Department of Homeland Security made it clear that it has requested the master key for the DNS root zone. The key will play an important role in the new DNSSec security extension, because it will make spoofing IP-addresses impossible. By forcing the IANA to hand out a copy of the master key, the US government will be the only institution that is able to spoof IP addresses and be able to break into computers connected to the Internet without much effort. There's a further complication, of course, because even 'if the IANA retains the key ... the US government still reserves the right to oversee ICANN/IANA. If the keys are then handed over to ICANN/IANA, there would be even less of an incentive [for the U.S.] to give up this role as a monitor. As a result, the DHS's demands will probably only heat up the debate about US dominance of the control of Internet resources.'"

Comments

DNSSec

[tronicum]

...it will make spoofing IP-addresses impossible...

No. It secures DNS. So you cant spoof domain names. It secures that the DNS Server is authorative so the DNS query was answered right. If somebody spoofes an IP in your network, you won't be saved.

Re:DNSSec

[Score Whore]

Switzerland isn't neutral. They are firmly on their side. You can tell by the way they looted jewish deposits during world war ii.

Subby failed reading comprehension

[Anonymous Coward]

No where in that article did it say that DNSSEC would prevent spoofed IP Addresses. This is about DNS, not about IP addresses. Also, the fact that the DHS wants they master keys does not mean they'll be able to hack into your computer without any problem. It boggles my mind that this Summary was allowed to hit the main page. wow...just wow.

Re:Multiple keys

[Eric Smith]

In principle, there is no reason why a ccTLD key needs to be signed by IANA, ICANN, the US DoD, or anyone else, as long as the DNS implementation on client computers is configured to trust that ccTLD key.

The result is that instead of computers being configure to trust a single root zone key from IANA, it is likely that every ccTLD will have its own key, and that the standard configuration of DNS as shipped with an OS or distribution will contain the public keys or hashes for every one of them. This is arguably a good thing.

Note that few if any OS distributions come configured to support secure DNS and verify signed DNS records.

DNS Trust Anchors (how to trust who you trust)

[hardaker]

DNSSEC provides the ability for the data to be signed. The politics have come in, of course, as to who has those keys. (Now mind you, right now the US government or anyone at all can already spoof DNS responses today and interestingly enough when politics get involved, it takes longer for deployment of secure protocols to happen. whee....)

But, DNSSEC does provide every zone owner with the ability to hold a very special key so that no one else may be able to spoof stuff in their zone. Everyone would want to trust .com's key, because they're the one with all the data you need. The roots hold all the information about the TLDs, so you need to trust the roots to be able to get information about .com's servers. If someone controlled the keys for the roots and you trusted those keys (had them configured as "trust anchors") then they could spoof (signed) .com record, the .com keys, etc down until example.com so you'd trust the results for example.com as secure.

But here's the secret: if you don't trust the root zone owners, then instead you can choose to set trust anchors tied to the .com key instead. You don't have to trust the root zone keys, it just makes it easier to trust only one. Paranoid people are certainly welcome to maintain a list of trusted keys for any zones they deem to be "importantly" critical. If you had a trust anchor configured for .com, then it wouldn't matter what someone with the real root zone key could do with it... You wouldn't trust the eventual results from a fake .com server a root had told you about because the cryptography would warn you that it didn't match up to your expected trust anchor for .com. I suspect that most country TLDs will already do this for their own government results (IE, .se, who already runs a secured zone, will configure the .se keys as trust anchors in its government systems).

Here's an interesting proposal for the root zone: pick two countries that hate each other and are likely to never have the same agenda. Let's call them X and Y. Give each of these countries a root key, and make the root zone use and publish results from both of them. Then, you could configure trust anchors pointing to both the X and Y keys. You could configure your system to make sure to check the DNSSEC results to validate the information up to both of these keys. That way you could ensure that since you trusted X and Y to never conspire against you together, and you would know that neither X or Y alone could have spoofed DNS data then you suddenly find yourself safe. Because of the distrust. I love the irony.

(now: you don't want to have a zillion keys for the roots... The packet sizes get larger as you add more keys, and it turns out you probably don't want more than 3 at most).