Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

[David Conrad <[e-mail]>]

John,

Very useful note, thanks!

On Jan 27, 2011, at 12:21 PM, John Bashinski wrote:
> At the moment, the following are under consideration:
> 
> I. Get IANA and the root zone to provide some kind of service for
>    getting up to date starting from old trust roots.

If you only want to use DNS/DNSSEC, the implication of this is that the old trust roots would need to be forever (or at least the longest lifetime of all products) secure.  This would also sort of defeat the purpose of scheduled key rolls and would fail in the face of a key roll caused by known or suspected key compromise (you won't want to chain up through a known-compromised key).

> II. Provide our own key update service.

How would this be (conceptually) different than providing a (secure) software update service?

(Somewhat as an aside, in a world in which you can't trust admins, I'd argue that (by default) requiring user approval to install updates is demonstrably more risky to the Internet at large than otherwise.)

> III. Try to ship devices with up-to-date keys, and rely on admins to
>    update them when that fails. I think this would blow up on us, and
>    I got some indignant pushback for even suggesting it.

I'd agree relying on admins is unlikely to work.

> IV. Weaken the scheme in one of the following ways:
> 
>    a. Just query for the key record for the root zone at installation
> 	time, and believe whatever comes back. At least you're only exposed
> 	at one time instead of forever afterwards.
> 
>    b. Try a wired-in key, then fall back to (a) if it doesn't
> 	work. Which isn't every different from (a).

This doesn't seem that much different from III.  You'd have to rely on the admin to do something (in this case, ensure the initial connection used to fetch the root key is safe).

> Using the current public X.509 PKI is NOT under consideration.

Understandable.  However, this doesn't necessarily preclude the use of a private (not necessarily X.509, e.g., PGP/GPG) PKI.

Fundamentally, I don't see how this can be solved securely via DNS/DNSSEC. 

Regards,
-drc