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

[Brian Dickson <[e-mail]>]

On Thu, Jan 27, 2011 at 1:18 PM, Florian Weimer <[e-mail]> wrote:
> * Paul Wouters:
>
>> Remember this has to work on a product that has just been factory
>> defaulted to a config from 10 years ago, and the device is EOL with
>> no firmware upgrades.
>
> Why?  Where does this requirement come from?

Operational reality...

There are two resource issues.

One is network engineers who are DNSSEC-knowledgeable.
(In numbers, routers >> managed customers >> noc staff >> network
engineers >> DNS network engineers >> DNSSEC network engineers.)

The other is the life of a "factory default config".

It goes from $vendor, to $flash-vendor, to $mfg, to $shipping, to
$customs, to $distributor, to $customer.
In some cases, $customer has a large inventory, to supply their $end-customers.
And in some cases, $end-customer has both a live router, and cold
spare (in a box), purchased at the same time. Think MTBF...

So, there are cases where both large numbers of $customer get a new
box, which has a slightly-outdated trust anchor (because roll-over
happened during the supply chain process), and where moderate numbers
of $customer eventually have a "new" box which is quite old.

Solving for one solves for both, ideally.

Regardless of oversimplification, having $vendor ship all routers with
DNSSEC not only supported, but enabled by default, should be
commended.

We complain about adoption delays. This, we should be falling over
ourselves to assist on, or never, ever complain again about adoption.
Seriously.

Brian