About this blog…

I am employed by Netnod as head of engineering, research and development and am among other things chair of the Security and Stability Advisory Committee at ICANN. You can find CV and photos of me at this page.

As I wear so many hats, I find it being necessary to somewhere express my personal view on things. This is the location where that happens. Postings on this blog, or at Facebook, Twitter etc, falls under this policy.

The views expressed on this post are mine and do not necessarily reflect the views of Netnod or any other of the organisations I have connections to.

Confusion about DNSSEC and signatures of the root zone

Milton Müller writes about DNSSEC. He refers to a post by Philip Hallam Baker on the IETF list. Milton mixes up a number of things, and do ignore completely the downside of the proposal he makes.

First of all, the trust on the DNS has nothing to do with DNSSEC. It has to do with trust of the namespace, the hierarchy of names that start with the root. The real power because of this sits within the process that define what tokens (or names) should exist directly under the root. The creation of such names (creation of TLDs) and appointment of registries for those TLDs, that is where the power is, as the DNS is a distributed database with delegated administration (and because of the delegation of power).

DNSSEC is just digital signatures on records in this database.

That people think that signing the root implies that one make decisions on what is in the root zone is wrong, sad, and adds politics to the technical solution DNSSEC is. The politics must stay with the creation of TLDs and appointment of registries.

Of course the one that signs the root can refuse to do so if the content of the zone is not according to what they like. But, this argument is killed by defining the root signing entity as a pure technical process that verifies that the right entity has created the zone file, and that they are (still) doing their job. Like an ISO-9000 (or BS-7799) verification process. It is of course also possible to have that accreditation licensing process split between multiple entities by using a (mathematically) split key management for the root zone.

But that is something completely different from having multiple signing authorities for the same root zone. That just does not make any sense what so ever. If we create such solutions, we will not only end up in a situation that is very similar to the X.509 (used in TLS and SSL for the web) mess where people are in reality forced to buy certificates from CAs that are decided by the browser vendors, a process that is so complicated that many SSL based web sites use self signed certificates, and users just press ok when they get the question whether they should continue although the certificate is not signed.

I have accepted to be on the panel on DNSSEC that Milton Müller et.al. runs at the IGF in Rio de Janeiro later this fall, and this above is exactly what I will point out. All the time we have known each other (we know each other very very well) we have agreed we have different view on these things. Milton being (I think) too naive regarding the ability for market economy to resolve public policy issues. He probably have reverse thoughts about me. :-)

If just people accept that the DNS is a strict hierarchy, and concentrate on deciding what process should be used to create TLDs, and appoint registries, then the rest of the pieces of the puzzle will fall into place. DNSSEC is NOT a piece that is hard to place in its right spot. Too many people (like Milton I think) do think DNSSEC adds a separate power to someone, and too many technical people are naive when they suggest technical ideas that move the working hierarchical system of DNS towards the broken hierarchies of X.509 that we remember from X.400, X.500 and now SSL and TLS.

We must have one and only one root in DNS, and that implies one DNSSEC trust anchor.