CircleID

DNSSEC may have quite dismal prospects of being deployed in actual practice, but look on the bright side: if DNSSEC were completely and perfectly deployed right now, it would not be addressing the latest and greatest DNS-related attack, which involves compromise at the leaves of the network (resolvers), rather than the core. If DNSSEC had been in place, people who don't understand cryptography might have asked silly questions as to why all this "security" wasn't protecting us from attack. Such people do not understand that cryptography addresses a clean and elegant abstraction of the security issue, and does not mire itself in the vulgar practicalities of "real world" security, with its inherent imperfections, trade-offs, and pragmatic inelegance. DNSSEC aims for theoretical security against a theoretical attack (and would succeed in that task if only people would stop being so political). Of course the DNS will continue to have vulnerabilities outside this theoretical strength: there's only so much theoretical security that cryptographic mechanisms can provide, and we can't help it if attackers choose to target the system where it is weak.

(Caveat lector: this comment may contain irony.)

Do we still need intermediate DNS resolvers? What would be the network load of all clients going to a (signed) root server and cacheing the result locally? The client software is available now on Windows to cache resolved IP addresses; memory is not a limitation; recursive, slow or badly configured servers are not a problem.

How many new addresses would I still be resolving after a few days of use?
Does someone have the numbers - has the number of dns packets resolved at some DNS servers been measured ? How many were repeat requests from the same client?

If the network load *is* an issue, add more signed DNS servers. A new version of BIND would bypass all unsigned DNS servers.  There's no need to force users to reconfigure their system. Promote the security, make the software available, (or distribute it with OS updates :-)

Colin

In spite of the claim in the article, there is a technical issue here, DNSSEC doesn't support multiple roots; if it did that, then there would be no political issue, because everyone would get to win. The fact that the DNSSEC implementation and protocol *permits* political issues is a technical issue.

But I agree that DNSSEC only deals with one issue, but still, dealing with that issue is valuable anyway; for a secure system, you need to design and implement it well. A well designed, secure system has *no* issues, even political ones.

Lots of useful stuff here.  One thing I would take issue with is the extraordinary statement that "the DNS is already relatively fragile".  Nothing could be further from the truth. 

DNS can survive messages being lost, servers being down, inconsistencies in the database, rubbish queries and a plethora of other issues.  It has successfully scaled to several orders of magnitude larger than originally envisioned.

I would argue that DNS is one of the most durable and resilient technologies out there and embodies several design principles that other protocols could learn a lot from.

@Ian:

DNSSEC does support multiple roots in the same way that DNS does.  That is the whole point of DNSSEC - it secures the DNS tree from the root of that tree.  If you create another tree then you get another root and you use a different set of keys.  Simple.

What you appear to want is for DNSSEC to represent a different structure to the tree it secures and thereby allow for multiple roots.  Which is of course what DLV does. 

If we did have multiple DNSSEC roots then rather than everyone winning, nobody would win. How would a resolver find all those roots?  What happens if one domain appears in two roots and they disagree on the keys, which one should the resolver trust?

But then that isn't really DNS.

Jay Daley said:

@Ian:

DNSSEC does support multiple roots in the same way that DNS does.  That is the whole point of DNSSEC - it secures the DNS tree from the root of that tree.  If you create another tree then you get another root and you use a different set of keys.  Simple.

...except for the network effects associated with the current DNS, which make the likelihood of setting up an alternate tree (that actually gets used) highly improbable.

Adding a DNSSEC root key controlled by a single party raises those setup costs dramatically, and basically makes it impossible for alternative roots if the root key holder so chooses.

(For detailed info, see the "The keys to the Internet kingdom" comments of an IGP technical expert panel held last May - http://blog.internetgovernance.org/blog/_archives/2007/6/28/3053616.html)

Obviously, this a not such a problem to those who benefit most from the current DNS root regime. But it certainly does limit competition and innovation possibilities at the root.

Brenden,

...except for the network effects associated with the current DNS, which make the likelihood of setting up an alternate tree (that actually gets used) highly improbable.

Adding a DNSSEC root key controlled by a single party raises those setup costs dramatically, and basically makes it impossible for alternative roots if the root key holder so chooses.

I'm a bit confused. "Network effects" are generated by everyone using the same substrate, in this case the same namespace.  DNSSEC merely allows people to validate the data in that namespace hasn't been modified in transit.  How does this validation have any influence on network effects?  An alternate root would be a different name space.  Whether or not the contents of that namespace can be verified is irrelevant to whether or not a "network effect" would exist.  This can be empirically seen by the success (or lack thereof) of alternate roots in the DNSSEC-less world of today…

Regards,
-drc

@Brendan:
If you want to pursue the political objective of multiple roots or one root under distributed control then that's your prerogative.  But it is disingenuous to drag poor old DNSSEC into it as a pawn in that game.

DNSSEC does not dramatically raise the setup costs of an alternate root at all.  Nor does it in any way make it impossible for alternate roots to function.  If you want an alternate root then you can do it in an afternoon, root keys included.

DNS works a particular way and DNSSEC mirrors that.  That's all there is to it.

Alternate roots or distributed roots and all the politics associated with them are entirely orthogonal to DNSSEC.

Jay Daley said:

Lots of useful stuff here.  One thing I would take issue with is the extraordinary statement that "the DNS is already relatively fragile".  Nothing could be further from the truth.

DNS as a whole is quite resilient.  The components of the DNS, however, are quite fragile.  As was recently noted when a human error 3 months ago caused ris.ripe.net to be unresolvable a couple of days ago for folks who had DNSSEC turned on, DNSSEC, like many security mechanisms, adds fragility to the individual components that make up DNS in the sense that what without DNSSEC would be ignored turns into a hard error when DNSSEC is turned on. 

It has successfully scaled to several orders of magnitude larger than originally envisioned.

Actually, if you talk to Paul Mockapetris, I suspect he'd tell you that the DNS still hasn't scaled to what he envisioned (particularly in terms of content).

Regards,
-drc

Jay:
The point of discussing multiple or competing roots in the context of DNSSEC is not necessarily to advocate splitting the DNS root. It is to demonstrate that there are economic, operational and political consequences inherent in the nature of the root signing process. Your own argument makes this clear.

You say

"What happens if one domain appears in two roots and they disagree on the keys, which one should the resolver trust?"

So thanks for making the point for us. Clearly, DNSSEC makes it more difficult to maintain compatibility among multiple roots. Under current, non-signed DNS, maintaining compatibility among different roots is easier; you simply incorporate the information in the legacy root zone into the alternate root zone. And the point of the network externality argument is that any new root will have to maintain compatibility with the legacy root to survive. So DNSSEC would appear to intensify the lock-in associated with DNS root.

That is not the only possible way in which DNSSEC has the potential for political consequences. There are others, such as liability issues, the processes for key rollover and security, and so on.

For technical people like Huston to insist that this transition has no governance consequences is simply irresponsible.

Jay Daley said:

"If you want to pursue the political objective of multiple roots or one root under distributed control then that's your prerogative.  But it is disingenuous to drag poor old DNSSEC into it as a pawn in that game."

Poor old Jay, I used to think you were being disingenuous, but I now believe you are truly innocent when it comes to governance institutions and the relationship between technical systems and the distribution of political power.

We have already established that DNSSEC increases the costs of maintaining compatibility between roots. Even if you ignore the implications of your own technical analysis and refuse to accept that, we also know that new procedures will have to be created to generate and secure and roll over the keys. Those procedures are not just technical, they involve organizational and liability issues. So lawyers are going to be involved and the US Commerce dept is going to be involved.

Goeff Huston's "brilliant" solution to this conundrum is to say, "let IANA do it." Wow, I am really impressed. This to my mind is sort of like saying, when confronted with the problem of new TLDs in 1996, "let IANA do it." Sounds nice. Worked for 15 years when the Internet was a closed club of techies. But it's completely out of touch with reality today.

Let's look a little deeper into what it means to "let IANA do it." Who is IANA? Do you mean ICANN's Board? ICANN's "bottom up policy process?" SSAC? The US Department of Commerce? David Conrad?

Do you realize that if the current status quo is maintained, the signer of the root would be VeriSign, not IANA? So right there, you are talking about the need for an institutional change, and about politics and interest groups. "Letting IANA do it" means a relative shift of operational power from VeriSign to ICANN.

If letting IANA do it means letting David Conrad do it, do you think David will feel a little nervous about the liability issues associated with that responsibility? Don't you think he wants a well-vetted process in place? And in designing these new processes and institutions, yes, I think it would be a good idea to seize any opportunities for making the power over the root a bit more distributed or accountable than it is now.

I repeat, whatever happens lawyers are going to be involved and the US Commerce dept is going to be involved and therefore politics—global politics—are involved. Let's just be adults and accept that fact.

Perhaps I was a little indirect in the reason why I wrote this article about the number and quality of the Bad Ideas surrounding the use of DNSSEC in the root, and what I saw as the inane level of speculation on who should be included in the cast of thousands to have possession of a fraction of a bit of the root zone private key. What prompted me to writethis article was a paper by Milton that was published on his web site earlier this year. This paper argued along the lines of his comment here, namely advocating a cast of thousands as holders of bits of the private key on the basis that this is all about control of the root of the DNS, and that an approach to DNSSEC signing the root zone that simply places the zone signing capability in the hands of the zone administrator immediately triggers some home brewed conspiracy theory about the evil empire taking over this part of the universe or something similar. From my perspective this paranoid line of argument represents a good example of flawed reasoning of the worst order. It attempts to over-inflate the role of DNSSEC into some overarching change control mechanism that it's just not. From my perspective I feel that advancing such arguments about why it is imperative that everyone gets a power of veto when signing the root of the DNS is indistinguishable from opportunistic political grandstanding, and it does the prospects of DNSSEC deployment no good whatsoever.

Who does, who should, and who should not have the ability to authorize changes to the root zone and the process of consultation and signoff for such changes may well be a fascintating topic, but to suppose that every administrative process of this form can and should be embodied into one form of security technology, no matter how inappropriate the match of the technology capabilites to the process in question, strikes me as an attitude that is hopelessly naive, and far removed from any form of rational and mature consideration of the topic that Milton is calling for in his comment.

Milton:

It is fairly apparent that you are confused about DNSSEC but it appears that you might be a tad confused about DNS as well.  Let me explain:

When I said the following (which you took out of context):

If we did have multiple DNSSEC roots then rather than everyone winning, nobody would win. How would a resolver find all those roots?  What happens if one domain appears in two roots and they disagree on the keys, which one should the resolver trust?

then anyone who understands DNS would know immediately that I could have written:

If we did have multiple DNS roots then rather than everyone winning, nobody would win. How would a resolver find all those roots?  What happens if one domain appears in two roots and they disagree on the delegation, which one should the resolver trust?

and it still would have made perfect sense because DNSSEC mirrors the way DNS works.

Milton Mueller said:

I repeat, whatever happens lawyers are going to be involved and the US Commerce dept is going to be involved and therefore politics—global politics—are involved. Let's just be adults and accept that fact.

This is the heart of the matter.  Even before DNSSEC became a live issue, the management of the root already involved lawyers and the US Commerce dept and it was already global politics.  DNSSEC has not changed that.

I make a heartfelt plea for you to leave DNSSEC alone.  Leave it to those of who want a secure Internet to get on and implement it.  DNSSEC will gradually fade into the background and be another of those things that just works.

If you have any point to make about root politics or those involved then you can make it just fine without invoking DNSSEC.  In fact, it would probably make more sense.

>[The IGP] paper argued along the lines of his comment here, namely advocating a cast
> of thousands as holders of bits of the private key

The paper proposed distributing the key signing among three parties. Why would a reputable technical expert equate the number "3" as somehow close to "a cast of thousands"? Just exactly who is being "paranoid" and "overinflated" here?

>triggers some home brewed conspiracy theory about the evil empire
>taking over this part of the universe or something similar.
>From my perspective this paranoid line of argument represents a
>good example of flawed reasoning of the worst order.

Lots of rhetoric, not much substance here.

Let me ground the debate once again:
1) It was other governments and ccTLD mangers who first expressed concerns about DHS control of the root signing key. (If you don't believe those concerns are real, then hey, let's let Russia or China control the root signing key. Just a technical process, right? No political concerns whatsoever, right?)
2) Those concerns were supported by Paul Vixie and VeriSign's chief scientist, not just by IGP
3) It is technically possible to distribute the root signing process in some way, and those methods were discussed early on in DNSSEC development; IGP simply revived those ideas.
4) We can have an intelligent debate about the costs and benefits of distributing the signing authority
5) We cannot have an intelligent debate if your response to the problem is to
i) deny that it is an issue at all
ii) hurl epithets at anyone who attempts to discuss it
iii) deliberately exaggerate or distort the nature of the proposals being made

>It attempts to over-inflate the role of DNSSEC into some
>overarching change control mechanism that it's just not.

To be precise, we have never argued that DNSSEC is the lever by which Internet governance as a whole could be transformed. We simply said that, if possible, implementation choices for DNSSEC should and could avoid the kind of concentration of power that has already caused so much trouble.

The kind of overreaction we are getting from people like you only increases the paranoia level, and makes thoughtful people have second thoughts about what agenda is really being pursued here.

>indistinguishable from opportunistic political grandstanding, and it does the
> prospects of DNSSEC deployment no good whatsoever.

The most polite way to interpret your perorations on this topic is that you are concerned that the issues we are raising act as an obstacle to the deployment of DNSSEC. I have two responses to that.

First, if that is your argument, just say so, and don't try to sell the public on false dichotomies between "political" and "technical" issues; don't misrepresent distributing authority among three trusted nongovernmental entities as a "cast of thousands," etc. Make an intelligent case that DNSSEC needs to be implemented NOW. Then we can have an debate about the costs and benefits of various DNSSEC implementation scenarios. Which leads to the second response.

What's the rush to implement DNSSEC? If this controversy delays DNSSEC deployment, why is that a crime if the questions are real? I am not convinced, and a lot of others are not convinced, that the addition to security that DNSSEC yields is worth the costs and the political risks. Those unconvinced people include a lot of folks inside ICANN and IETF who won't say so publicly but don't buy the party line about its necessity and view it as an overly complex "propeller head" solution that will cause more trouble than it's worth. Numerous parties have commented that it does not address the main security risks facing the internet. Registries with large zone files, notably VeriSign and DENIC, seem less than enthusiastic about it, although some, like Nominet, are. If you add to this shaky economic/technical case the governance implications of further hardening the centralization of control over the root, and you have at best a mixed case. Anything we implement now will get hardened into practice and won't be changed for decades. So what's the rush? That's something that needs to be discussed, not driven off the table by the kind of fulminations you offered in your circle ID post.

IGP has attempted to foster intelligent and balanced discussion of this topic. Look at the composition of our IGF Workshop, which included IANA, Nominet, someone from the RIPE community, as well as DENIC, IGP, and someone from CGI.BR. Look at the composition of our May 2007 conference, which also brought together people from all sides, including NIST of the US government and VeriSign.

Geoff Huston said:

Who does, who should, and who should not have the ability to authorize changes to the root zone and the process of consultation and signoff for such changes may well be a fascintating topic, but to suppose that every administrative process of this form can and should be embodied into one form of security technology, no matter how inappropriate the match of the technology capabilites to the process in question, strikes me as an attitude that is hopelessly naive, and far removed from any form of rational and mature consideration of the topic that Milton is calling for in his comment.

DNSSEC is supposed to deliver "security" of some sort as a product. To suppose that any security product can be fully described and evaluated on the basis of the technology that it employs strikes me as hopelessly naive, and far removed from any real understanding of what "security", as such, entails. Yet, when you and others beg that political issues be set aside in the name of enabling this "security" technology, you project this kind of naivety in sharp relief.

The question of who should have the ability to authorise changes is not a technical question, it's true. Such a question is posed as part of determining the requirements of the system, which should always come prior to the prescription of any particular technology as a solution. However, we have a situation where the system requirements have been framed on the basis of a de facto administrative structure, and the application of the solution will serve to ossify that administrative structure. It should, therefore, come as no surprise that those who are not satisfied with the current administrative structure are presenting this kind of opposition to the technology, despite whatever merits it may have.

DNS is a key part of the operation of the Internet, and its centrally controlled design makes it a political football. It's naive to think that a high-level technology like DNSSEC can be discussed—let alone deployed—without reigniting the same old root-level differences of opinion. If you want to avoid the political issues, you'll have to be satisfied with a solution on paper, like so many anti-spam "solutions" which take the form, "if only everyone did this, there wouldn't be a problem." It's one thing to build a technology which serves a purpose; it's quite another thing to build a technology which serves the people is supposed to serve in such a way that a critical mass will actually want it. The former is a technical matter; the latter political. It takes considerable cross-disciplinary skill to meet both these goals.

In short, my position on DNSSEC is that its time has not yet come. Maybe I'm wrong, but experience so far validates that position. If you can solve the governance issue so that enough people will want a cryptographically signed version of the system, then DNSSEC will be easy to design and deploy. Until then, it's a case of premature optimisation. To add signatures to the DNS before people are happy with its administrative structure is to put the cart well in front of the horse. Simply telling people to stop whining about the administrative issues so that we can secure the system isn't going to work.

There's no guarantee that the governance issue can be solved, but there's no point pushing DNSSEC until it is—unless you can somehow make it completely independent of governance.

Larry Seltzer has written a follow up story on eWeek:

DNSSEC Is Dead, Stick a Fork in It