The Internet engineering community is forging ahead with an alternative approach to allow DNSSEC deployment without the DNS root zone being signed. Known as a Trust Anchor Repository, the alternative was announced by the Internet Corporation for Assigned Names and Numbers (ICANN) last week.
Forty years ago, when the U.S. government created the packet switching network that became the Internet, one of its goals was to create a robust network where traffic would be dynamically routed around blockages.
Now the Internet engineering community has developed a strategy to route around a different kind of blockage – one that is political, rather than technical – and one that has been caused by the U.S. government itself.
At issue is the deployment of security mechanisms for the Internet's Domain Name System, which matches domain names with corresponding IP addresses.
The Internet engineering community wants to deploy DNS Security Extensions (DNSSEC) to prevent hackers from hijacking Web traffic and redirecting it to bogus sites. DNSSEC uses digital signatures and public-key encryption to allow Web sites to verify their domain names and corresponding IP addresses. DNSSEC is viewed as the best way to bolster the DNS against vulnerabilities such as the Kaminsky bug discovered this summer (and about which Dan Kaminsky spoke at last week's Black Hat event in Washington, D.C.). It's because of DNS threats like these that the U.S. government is rolling out DNSSEC across its .gov domain.
Despite its efforts to deploy DNSSEC on .gov, the U.S. government is delaying widespread DNSSEC deployment by failing to cryptographically sign the 13 "root" servers that operate at the pinnacle of the Internet's hierarchical DNS. The root servers make it possible for top-level domains including .gov, .com and .net to resolve DNS requests for names registered in these domains.
Last fall, the U.S. government sought comments from industry about how best to deploy DNSSEC on the root zone, but it hasn't taken action since then. Internet policy experts anticipate further delays because the Obama Administration only this week named Gary Locke as Secretary of Commerce, a position in which he would oversee Internet addressing issues.
View slideshow on Big name techies who could influence Obama
Meanwhile, the Internet engineering community is forging ahead with an alternative approach to allow DNSSEC deployment without the DNS root zone being signed. Known as a Trust Anchor Repository, the alternative was announced by the Internet Corporation for Assigned Names and Numbers (ICANN) last week.
ICANN's Interim Trust Anchor Repository – or ITAR -- allows top-level domains such as .se for Sweden and .br for Brazil to have fully functioning DNSSEC deployments without waiting for the root zone to be signed.
ICANN officials were quick to say that their Trust Anchor Repository would be disabled as soon as the U.S. Department of Commerce requires root zone operators to deploy DNSSEC.
"The ideal scenario is that the root zone is signed," said Kim Davies, manager of root zone services for ICANN."Currently, we have a situation where the root isn't signed, which is largely a political discussion. And in the immediate future, it is not likely that we'll have a signed zone. So we're looking at what's the next best thing."
ICANN's ITAR serves as a central clearinghouse for top-level domains to share their DNSSEC public keys. The ITAR publishes the public keys for each participating top-level domain in a single file on a regular basis so that domain operators can validate against the latest security information.
"This is a temporary service until the root is signed," Davies said."It's kind of a stop-gap measure. Technologists would agree that it is not ideal, but it is the best we can do for now."
ICANN's ITAR has been operating in test mode since October. Fifteen top-level domains are using ITAR, including some domains such as .gov and .museum that are experimenting with DNSSEC. ITAR is available free to top-level domain operators through ICANN's Internet Assigned Numbers Authority.
ITAR proponents say it will encourage domain name operators to forge ahead with DNSSEC deployments without worrying that their efforts to authenticate DNS queries will be stymied because the root zone isn't cryptographically signed.
"I don't think ITAR is as scalable as having the root zone signed, and it's not a replacement for having the root zone signed. But it does make early adopters have an easier time deploying DNSSEC," Davies said.
The ITAR comes with some risk. Some argue that its existence could slow DNSSEC deployment. Others say that it could end up on the Internet forever, which would complicate DNSSEC deployment.
"We've seen no indications from the U.S. government or any other parties that [ITAR] will delay DNSSEC deployment," Davies argues."Signing the root is the only long-term proposition."
He adds that ICANN has"been emphatic on the documentation of ITAR that it is a temporary service. Once the root zone is signed, we intend it to go away."
Multiple repositories emerge
While ICANN's ITAR is aimed at top-level domains that deploy DNSSEC, other Trust Anchor Repositories are being developed for lower levels of the DNS hierarchy.
Internet pioneer Steve Crocker, CEO of Shinkuro, says Trust Anchor Repositories are a"necessary piece of scaffolding to permit DNSSEC to work smoothly during the lengthy transition period until most of the [DNS] tree is signed."
Even if the U.S. government mandates that the DNS root zone is cryptographically signed, the most popular top-level domains for online business--.com and .net – haven't adopted DNSSEC. VeriSign, which operates both of these domains, won't comment on its plans to deploy DNSSEC.
Until .com is signed, if an individual company with a .com address wants to deploy DNSSEC to protect its Web site from hijacking attacks, it needs a Trust Anchor Repository that operates at the .com level.
ISC is operating a trust anchor repository it calls DLV for DNSSEC Look-aside Validation to address this problem. DLV is a free service that any Web site operator who deploys DNSSEC can use to publish its public key and validate against other available public keys.
"ISC is running what I would call a real-time Trust Anchor Repository to distinguish it form the batch-oriented one that ICANN operates," Crocker said."DLV is open for business across everything, including .com and .net."
Crocker said that ISC's DLV is not picking up momentum as quickly as DNSSEC proponents had anticipated.
"The problem with ISC's [repository] is that they have far fewer keys than exist in the world," Crocker says. ‘'People are not registering in the numbers that one would have expected. And the other problem is that there is some concern about real-time look-ups and how well that will scale."
Crocker said DNSSEC experts are working with ISC to address some of their concerns about the DLV repository.
Domain name registry Afilias says it will participate in ICANN's ITAR because it provides back-end services for .org, which will support DNSSEC in the first half of 2009."We're pretty agnostic about it,'' said Ram Mohan, CTO of Afilias and a board member of ICANN."We will share our keys with other Trust Anchor Repositories, too. ISC has been running one for awhile. We intend to share our keys with them also. We actually think a few well-known and well-trusted Trust Anchor Repositories is a good model.''Mohan said he views Trust Anchor Repositories as a temporary measure until the DNS root zone is signed."What I don't want to happen is for a million Trust Anchor Repositories to come up...Then I think you will have real chaos,'' Mohan said.
Most Internet engineers say Trust Anchor Repositories are necessary to ease the transition to DNSSEC. But they warn that it's important that repository operators are organizations such as ICANN that are trustworthy.
"If the owner of a zone is not signing it or creating a Trust Anchor Repository for it, then you have to go to somebody who you trust to publish your public keys and validate against other keys," explains Paul Hoffman, director of the VPN Consortium and an active participant in the DNSSEC community."There's an important policy question about why should I trust this party to tell me about those other parties."
Hoffman said another issue is that the Trust Anchor Repository operators must be able to maintain a secure repository and update it regularly to ensure that users have the latest public key data.
"DNSSEC users will be rolling their public keys every year or two," Hoffman said."The government put in test keys for .gov while they were testing DNSSEC, and then they pulled those keys and put in different ones, the real ones, when they went live. How do you know that a [trust anchor repository] is current? Updates will be vitally important."
Even the biggest proponents of Trust Anchor Repositories would rather see DNSSEC deployed on the DNS root and top-level domains like .com and .net.
"Signing the root has two benefits: from a technical perspective, it means that layer is signed," Crocker said."Politically, as soon as the root is signed, that sends a very powerful signal that DNSSEC is for real and everyone should do it."
Trust anchor repositories"should be unnecessary because the root should be signed by now," Hoffman says."The Internet is much less stable with [trust anchor repositories] than with DNSSEC because DNSSEC is automated and [trust anchor repositories] by their nature are not automated."