The US government said Wednesday it plans to digitally sign the internet's root zone by the end of the year, a move that would end years of inaction securing the internet's most important asset. The US Department of Commerce's National Telecommunications and Information Administration (NTIA) said it was turning to ICANN, or the …
15 years to develop and what do we get?
They hand over the keys to verisign. That means dnssec keys will cost $$$ to buy, meaning only corporates will use it.
You might say 'why not self sign?'.. well, because it's utterly pointless - DNSSEC has no encryption, so signing only serves to establish trust.. and without a chain of trust right back to the root it's pointless.
DNS spoofing is still possible, of course... just strip the security from the domain and return plaintext. If someone can inject DNS replies into your system you're hosed, and DNSSEC doesn't help with this.
I had a little hope there, right up 'til I read the words US government.
Have you got a link to this announcement because I can't find mention of it on either the NTIA or ICANN sites?
Here's the text of the NTIA's press release:
Commerce Department to Work with ICANN and VeriSign to Enhance the Security and Stability of the Internet’s Domain Name and Addressing System
For Immediate Release: June 3, 2009
NTIA Contact: Bart Forbes, [phone number and email address removed]
NIST Contact: Chad Boutin, [phone number and email address removed]
WASHINGTON — The U.S. Department of Commerce's National Telecommunications and Information Administration (NTIA) and National Institute of Standards and Technology (NIST) announced today that the two agencies are working with the Internet Corporation for Assigned Names and Numbers (ICANN) and VeriSign on an initiative to enhance the security and stability of the Internet. The parties are working on an interim approach to deployment, by year’s end, of a security technology -- Domain Name System Security Extensions (DNSSEC) -- at the authoritative root zone (i.e., the address book) of the Internet. There will be further consultations with the Internet technical community as the testing and implementation plans are developed.
The Domain Name and Addressing System (DNS) is a critical component of the Internet infrastructure. The DNS associates user-friendly domain names (e.g., www.commerce.gov) with the numeric network addresses (e.g., 22.214.171.124) required to deliver information on the Internet, making the Internet easier for the public to navigate. The accuracy, integrity, and availability of the data supplied by the DNS are essential to the operation of any system or service that uses the Internet. Over the years, vulnerabilities have been identified in the DNS protocol that threaten the authenticity and integrity of the DNS data. Many of these vulnerabilities are mitigated by DNSSEC, which is a suite of Internet Engineering Task Force (IETF) specifications for securing information provided by the DNS.
“The Internet is an ever-increasing means of communications and commerce, and this success is due in part to the Internet domain name and addressing system,” said Acting NTIA Administrator Anna M. Gomez. “The Administration is committed to preserving the stability and security of the DNS, and today’s announcement supports this commitment.”
"NIST has been an active participant within the international community in developing the DNSSEC protocols and has collaborated with various U.S. agencies in deploying DNSSEC within the .gov domain," said Cita M. Furlani, director of NIST's Information Technology Laboratory. "Signing the root will significantly speed up the global deployment of DNSSEC and enhance the security of the Internet.”
The NTIA in the U.S. Department of Commerce serves as the executive branch agency principally responsible for advising the President on communications and information policies. For more information about the NTIA, visit www.ntia.doc.gov.
As a non-regulatory agency, NIST promotes U.S. innovation and industrial competitiveness by advancing measurement science, standards and technology in ways that enhance economic security and improve our quality of life. For more information visit, www.nist.gov.
# # #
What in the world does "we need to socialize whatever decision is made" mean?
trusting trust on the Net
Currently with the lack of root zone signing, to verify a DNSSEC record for c.b.a you have to configure a trust anchor in either .a (the Top Level Domain) or in b.a. depending upon where secure DNSSEC provision starts. There is therefore nothing to prevent anyone willing to do the work involved who wants to verify the authenticity of whichever TLDs or lower level zones have DNSSEC from doing so directly. It's more work than deciding to trust the root key though, when the latter exists. But even having done so you don't need to look up the root signature every time if TLD signature trusts are cached, assuming you are less worried about a potential TLD key compromise and revocation than you are about misuse of the root key. Higher level zone key signature trusts will have to be cached for at least several days anyway, or AINA/Verisign or whoever else compiles the root zone simply wouldn't be able to handle all the lookup traffic.
So I think root key misuse, if it ever occurs, will tend to be a self-limiting phenomenon. If this ever happens then a more trustworthy root key signer and root zone will be adopted by the TLD DNS server operators within days. It's not as if the root zone, which is quite small, has to be updated very often and it isn't as if the many current TLD operators couldn't setup a mutually owned non-profit organisation to manage one in the event of demonstrated lack of competence to do so by Verisign.
What the latter strategy would make more difficult would be the politics associated with who gets to look after new TLDs, or an existing country code when a government is overthrown. The combination of these 2 issues - 1. politically motivated root zone changes where unilateral US authority over the International Internet becomes moot and 2. the need for secure root zone signing key management, will probably at some point result in IANA being managed by the ITU instead of ICANN: http://en.wikipedia.org/wiki/ITU .
re: 15 years to develop and what do we get get? get?
Tony Hoyle said "They hand over the keys to verisign. That means dnssec keys will cost $$$ to buy, meaning only corporates will use it.". This shows how little he knows about DNSSEC.
DNSSEC works on a zone-by-zone basis. It's up to the zone administrator to decide whether to sign their zone or not. If they use it, they add DNSSEC resource records -- keys, signatures, etc -- to their zone. In principle this is no different from how they'd add a new A record for a host or an MX record for mail delivery: they'd just use new tools to generate those keys and signatures. The zone administrator generates their own DNSSEC keys by whatever means they choose. There's no reason to buy them. in fact it would be unwise to buy DNSSEC keys from a third party, assuming anyone was stupid enough to sell them, in case those keys were weak, poorly managed or otherwise compromised somehow.
Paris icon because she knows a lot more about this subject than Tony Hoyle.
Hold on just a minute
When will they be consulting their masters in China and the EU?
yet more DNSSEC ignorance
Richard Kay said "Higher level zone key signature trusts will have to be cached for at least several days anyway, or AINA/Verisign or whoever else compiles the root zone simply wouldn't be able to handle all the lookup traffic.". This is profoundly stupid. A signed root is not going to make a significant difference to the query load on the world's DNS servers. DNSSEC-aware resolvers will get signed responses (which will be bigger than unsigned ones). However they will not be performing extra lookups to do DNSSEC validation: the data to do that validation will be in the responses to DNSSEC-aware queries. [Extra queries would be necessary if validation had to be done against an alternate trust anchor instead of a signed root zone.] And in any event, the validity of a DNSSEC signature over a delegation is likely to be of the order of a week or a month: far longer than the TTL for the actual delegation itself.
Oh and the DNS infrastructure for the root zone and the responsibly run TLDs already handles billions of queries a day. The overwhelming majority of those queries have no reason to go anywhere near those servers. So if DNSSEC was to add to the query load (which it doesn't) that traffic would be lost in the noise of the 99.9% of the crap and DDoS attacks that those important name servers get.
"Should it ever fall into the wrong hands, the internet could cease to function."
lol... how ignorant mr. journalist
Utterly pointless -and dangerous.
Unless I'm missing something. All it will do is allow a rotten corporation (Verisign) to make some more money, and give the US unfettered power over the whole Internet, none of which is a good thing (think Arkansas...). It will make it slightly more difficult -but in no way impossible- for a supervillain to take over the internet, but I very much doubt anyone would have tried anyway (see this stone? It repells green tigers. Only $5000 for you, my friend), maybe because no-one would achieve anything by doing so.
No, the internet won't "cease to function". You might have to type IP addresses sometimes, or rely on certificates issued by people or corporations you know, but the "chain of trust" was never really secure anyway, and it never will. Just wait till DNSSEC is broken (should happen roughly 3 hours after it's first deployed).
It looks suspiciously like the weapons of mass destruction thinggy: At long last we're doing something. Against an imaginary threat we just made up. Which gives us full rights for a massive landgrab. Of course. As I said, the chances of some supervillain wanting to take over the root zone are approximately the same as being eaten by a green tiger in the Square Mile, and the chances of said supervillain doing anything with this newfound power would be even slimmer -if you could go any slimmer. And even assuming that, it would be so easily thwarted in a (comparatively) cheap and efficient way using only readily-deployed strategies (one way may be exchanging certificated by IP-based connections between known and trusted peers et voila! "Chain of trust" restored. Admittedly it will be some work for the largest structures, but nothing comparable to DNSSEC deployment IMHO). But of course Verisign wouldn't make gazillions out of it, and the US government wouldn't get the power to exclude the "baddies"* from the domain name system -or just maliciously redirect unsuspecting visitors from a "bad" site to a (CIA/DHS/NSA) scam site harvesting your details. It would be a pity not to use these predator and airborne laser beams to good use, after all. So DNSSEC it is, then. Colour me paranoid, but I'll be far more suspicious about the DNS system *after* than I am now (depending on the way it's implemented. I'm voluntarily considering the worst case scenario here, which is stupid. It won't happen of course. ASBOs were never used against fly tippers, the WMDs actually existed, the Terrorism Act was never user to steal your camera, the anti-paedo laws are never used to prosecute "sexting" minors, ...)
The bright side is that you'll know where to find the really good stuff: if you have to type the IP address, you're on the right track!
Tombstone: it's not El Reg anymore, it's 126.96.36.199. That's what you get for criticizing the "anti-terror" laws!
*that would be China, Iran, Pakistan, North Korea, Europe every other year, Russia, Venezuela, Brazil, Cuba, Chile, two third of Africa, everyone in the Middle East but Israel, any site linking to links to links to links to Simpson porn images (or p2p trackers, or gambling site, or ...) etc. etc...
@the internet could cease to function.
> Should [the root key] ever fall into the wrong hands, the internet could cease to function
I think that's exaggerating. Here's how I would phrase it:
Should the root key ever fall into the wrong hands, then the extra protection provided by DNSSEC will be neutralised. I.e. an attacker with the root key will be able to carry out any DNS poisoning attack that is feasible today.
Or to put it another way, DNSSEC with a widely-known root key is no better or worse than the situation today. DNSSEC with a secret root key is much better than the situation today.
re: Utterly pointless -and dangerous
>>> Just wait till DNSSEC is broken (should happen roughly 3 hours after it's first deployed).
pierre, you haven't got the slightest clue about dnssec.
secure dns uses public key crypto to generate digital signatures of the output from strong hash algorithms like md5 and sha. 1024 or 2048 bit rsa keys are never going to be broken in "roughly 3 hours", except for the dumbest hollywood movie scripts. some parts of the dns have been using secure dns for a lot more than 3 hours. the .se tld was signed almost 4 years ago. the cryptosystem hasn't been broken yet.
In this context "socialize" is Enterprise-speek for "tell people".
Thus creating synergetic leverage amongst key stakeholders, building core competencies across a matrix of functional silos! *cough*
A little theory
OK, all you lot worrying about Verisign raking it in: ALL that should be in the root zone (.) are NS records of the TLDs and their DS sets if they're signed. That's it. Unless you are a TLD holder, you won't ever have to deal with Verisign. Your DS sets are never going to go near the root zone anyway.
When you finally secure your own zone, YOU publish the keys, sign the zone and your parent zone (e.g. co.uk., which in turn will have a DS set in uk. in the root zone) needs to import your DS set into its own zone. They don't sign your zone, you need no other outside services to deploy DNSSEC and if your parent zone isn't signed, you can use lookaside validation (in which case, the DLV publishes a DLV set rather than DS) instead. Honestly, guys, this isn't going to cost you a thing unless your parent zone starts charging. In fact, you don't *have* to implement DNSSEC at all. It's worth doing, though.
Validation on the resolver is simple, although keeping the trust-anchors current is a bit of a nuisance at present as, with no signed root, DNSSEC validation is very fragmented. Signing of the root zone should help immensely as we will eventually, assuming the TLDs play the game properly, only need the root trust-anchor in the resolver configuration which will probably get published in the same way as the root zone itself is.
Currently, key rollover is a pain in the arse (all sorts of timing rules and obscure commands to learn) but BIND9.6 has some useful tools (which I haven't read up on properly yet - I only upgraded to 9.6.0p1 when the .org zone got signed with NSEC3 on the 2nd) to deal with this little issue. All in all, DNSSEC is coming together nicely. What it isn't: Encryption or security on its own. What it is, which sounds a bit of a letdown after all the hype: Identity validation using a hierarchical PKI. However, that is rather useful on its own. Think PGP signed (not encrypted) e-mail verified using the sender's public key and message hash.
"secure dns uses public key crypto to generate digital signatures of the output from strong hash algorithms like md5 and sha. 1024 or 2048 bit rsa keys are never going to be broken in "roughly 3 hours", except for the dumbest hollywood movie scripts"
Uh isn't MD5 considered reasonably trivial amongst the available encryption algorithms? And a 1K or 2K key seems good but surely if this serves as the DNS root key you would anticipate that there would be a *lot* of parties interested in breaking this key with the computing power to throw at it.
But then I know little about DNS so flame away.
Nothing (much) to see here. Move along.
As much as I love a conspiracy theory, this aint it.
Having verisign and/or ICANN in charge of the root key is no big deal. The root key in DNSSEC is just an administrative function. Since these guys are already in charge of the root zone they already have absolute control of it and nothing changes.
The risk is if the 'merkins decide at some future date to remove the country level domains for North Korea, Iran, or Cuba (or whoever is the bad guy some time in the distant future - can they trace my email if I post anonymously?) then they can direct their agencies to do it. They can already do this. The religious nutters in the US have already proven this by blocking the .xxx top level domain when it should have been an international decision. However, if it ever gets too extreme it is currently possible for the rest of the world to use an alternate root domain through non-US controlled root name servers. This would be very difficult and would cause all manner of transitional pain and suffering but it is technically possible to do.
With DNSSEC and an American controlled root key, the complexity in moving away from a hypothetical rogue/hostile USA based DNS system would be more difficult to manage and would cause additional problems. But most importantly, it will still be technically possible to do.
Yes, it would be nice if ICANN wasn't a US government department. If it was a UN agency then that would answer some of the risks inherent in having it controlled by a single country. The reality is that that is a different question. Verisign and ICANN already control the root zone. The US government has directed them to sign it. They will sign it. They will still have control of it.
It is an administrative detail required to maintain the status-quo in a changing world.
(Not enough people have chosen the PH icon yet in comments on this article - come on, get with it people).
Root key security
According to AEP Networks (HSM vendor), ICANN's using FIPS140-2 level 4 devices for key storage and signing so the root keys should be as secure as is feasibly possible claiming to be "a sealed, designed-for-purpose unit with no moving parts. It runs an embedded operating system..."
So at least they're not in keys.txt on a Windows XP PC. More like on a physically secure device accessed by multiple security personnel, in a physically secure room, in a physically secure building.
MD5 has been broken, now that people can create bogus HTTPS certificates which validate using MD5. So web browsers recently had to be updated to not accept MD5 signatures as valid, rendering invalid MD5 based certificates not by then updated. SHA is a family of hash algorithms, http://en.wikipedia.org/wiki/SHA currently going up to SHA512, likely one of the strongest currently known in widespread use. Some earlier SHA versions are now thought to have weaknesses, though probably not yet as readily exploitable as MD5 now is.
What having a signed DNSSEC root creating a heirarchical global PKI for the first time will mean is that much more attention will be given to the strength of the algorithms used, resulting incorrespondingly more fame and fortune for whoever publishes successful attacks.
We will never know that a particular algorithm is secure, we only know when published insecurities exist. What can be said about their security, for algorithms developed within the public domain, is what it would be worth to the person who succeeds in breaking it and publishing a feasible attack, from which we can estimate the amount of talented effort directed towards doing so without published success. (For the paranoid, we don't known what the NSA and GCHQ knows about unpublished weaknesses, but we can still assume their budgets for maintaining the loyalty of those who do know to keep this knowledge secret is finite. We can also assume they can only use their top secret knowledge for attacks of high enough value to them that these justify the risks of leaking this knowledge in the process of using it. )
In the past attracting this kind of effort has required large prizes on offer to the first successful published attack. But we will need be in no doubt about the fame and fortune that will come to a cryptanalyst who can publish a paper which describes a feasible attack breaking the algorithms used to sign the DNSSEC root.
Breaking the key?
How would anyone need to break any key to break DNSSec?
Typical short-sighted gizmo-lovers, believing that the security of a system is this of it's stronger element. Hey, I've got whole-disk encryption, the key is a SuperSecureGaranteedUnbreakable Version 67 hash (4GB) stored on a stick labelled "enc. key" that sits on top of the machine. You'd need trillions of trillions years and more energy than is contained in the whole universe to break in. Or 30 seconds. Which is it?
You can get as strong a key as you want (which, dear AC, means NO MD5). It won't change a thing.
Anyway my point was that DNSSec would probably be broken very fast, if any bad guy really cared (the important part being that no-one is going to even remotely think about it. Because it has strictly no interest for a black hat.). The only people interested will be white hats, for the fame and glory (it means money).
Now deploy DNSSec all you want. It's certainly not going to make the internet any more secure. Hopefully it won't make it any *less* secure. And it certainly has the potential to make it *a lot* less neutral. Actually there's almost no way it's not completely and thoroughly abused and raped. Same as anti-terror laws used to chase fly-tippers and the like.
Same good old method: make up a fantastic (in all the meanings) threat, take "vigorous" action resulting in a "totally legitimate" landgrab. That's how the US annexed Iraq, that's how anti-paedo laws are used against, well, pretty much anyone including those they are supposed to protect, that's how your council can spy on you and how the plods can steal you camera for no good reason. That's also, closest to the point, how Arkansas got a bunch of oversea-based websites' domain names handed to them...
- +Comment Trips to Mars may be OFF: The SUN has changed in a way we've NEVER SEEN
- Vid Find email DIFFICULT? Print this article out and give it to someone 'techy'
- Back to the ... drawing board: 'Hoverboard' will disappoint Marty McFly wannabes
- Google+ goes TITSUP. But WHO knew? How long? Anyone ... Hello ...
- Pic Forget the $2499 5K iMac – today we reveal Apple's most expensive computer to date