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

[Alex Bligh <[e-mail]>]

--On 27 January 2011 15:21:54 -0500 John Bashinski <[e-mail]> wrote:

>  II. Provide our own key update service. This might be DNS-based or
>      HTTP-based. It would provide either:
...
>      We are obviously capable of this. We also obviously think it's
>      inferior to (I).

I wonder if we're not overcomplicating this, or more accurately
looking at this as a problem unique to DNSSEC.

With plain old DNS, or DNSSEC, or SSL cert validation, or whatever,
there is a set of bootstrap data that need to be distributed with
any image. Under certain circumstances (all root servers move IP
address, lots of key rollover whilst disconnected from the internet,
new CAs, whatever), that data can become out of date in a manner
where the protocols themselves can't make things right.

There's also a pile of other bootstrap stuff distributed with
Large Router Vendor (for any value of LRV) devices, which is the
firmware it's designed to run on.

One presumes LRV's devices have at least some permanent storage
in even if their firmware is non-upgradable, else this problem
is near insoluble.

So, how about
 1. When 'things go wrong', 'periodically', or 'on UI interaction'
    (obviously the latter to be avoided), device makes a simple
    http request to a known URL at LRV.
 2. Device downloads new bootstrap data. At this stage, it could
    be bogus. No need to use anything more fancy than http.
 3. Device verifies it is genuine, e.g. by checking it is signed
    with a private key (held securely by the LRV), the public key-pair
    being in the firmware. If it is, genuine, it replaces the
    current bootstrap data.

DoS attacks, etc. could prevent this upgrade from happening, but
that would have to be for an entire key rollover period.

-- 
Alex Bligh