Re: [dnsext] historal root keys for upgrade path?

[Joe Abley <[e-mail]>]

On 2011-01-31, at 21:23, Phillip Hallam-Baker wrote:

> Regularly rolling the root does not improve security. All that is achieved is that one point of vulnerability becomes two points until such time as the original root is no longer trusted for ANY purpose.

The draft I submitted doesn't address scheduled key rolls. Rather, it addresses the problem of how a validator establishes an initial trust anchor to be used for continuing operation.

I appreciate the distinction is muddied by the fact that a validator that fails to catch a key roll with 5011 semantics is effectively left in a state where it needs to bootstrap itself again.

> If you change the management rules to require a permanent chain of roots to be kept you have precisely the same exposure to the legacy root plus the additional exposure incurred through establishing a second root and the distribution mechanism.

Indeed. The proposal I posted doesn't establish a second root; it uses established ones.

> Without wanting to put too fine a point on the matter, the only way you are going to be able to rely on an ICANN issued root key in twenty years time is if ICANN decides that this is something that they are going to support. And if they did decide to offer such support there are much simpler ways to do so than the draft proposed.

ICANN has committed to support the current publication mechanisms for as long as they retain the role of KSK manager; it's in the IANA functions contract with NTIA (by reference). I think we can assume that the same requirement would be imposed on any new NTIA contractor in the event that some other organisation took over the role.

What support could ICANN provide that would facilitate a simpler bootstrapping method?

(The proposal Dave and I posted seemed pretty simple to me: you pull an XML document using HTTP, then the certificates referred to by that XML doc and use one of the X.509 CA keys you already have to verify any one of them. Until you find a suitable cert, you operate without DNSSEC.)


Joe