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

[John Bashinski <[e-mail]>]

On 2011-01-28 11:57, Paul Hoffman wrote:

> Is there a reason that we are only focusing on one of the multiple
> proposals that this person proposed? Path II was:
>
>  II. Provide our own key update service. This might be DNS-based or
>      HTTP-based. It would provide either:
> 
>      a. The entire historical chain of DNS root KSKs, with older keys
>     signing newer ones, so that the device could pick up from
>     whatever key it had, OR
> 
>      b. Just the current root key, signed with a key validated by
>     Cisco's private X.509 PKI (the same PKI we use to sign
>         software), OR
> 
>      c. The chain of (a) further signed with a key from (b).
> 
>      We are obviously capable of this. We also obviously think it's
>      inferior to (I).

> It is not clear that it is inferior to (I) if doing (I) makes the
> entire system more fragile by adding another moving part.

I'm not sure I see how it does that. The new "moving part" isn't in
the main trust path. It's off to the side, and it doesn't affect
the basic system. It only affects devices that choose to validate
by default and choose to bootstrap from old keys.

If you do want to think of that as a new moving part, then if you have
every vendor do it separately,what you've really done is to add N
new moving parts instead of one.

> I think (II)(b) looks quite sane, easy to do right now, and if this
> community ever agrees to a safe way to do (I) *and* implements it,
> doing a firmware update to switch over to it would not be hard. I
> would not hold my breath, though.

> We're talking pre-loaded trust anchors here. They have the same power
> as pre-loaded software. If (II)(b) works for your software, it should
> work just fine for your trust anchors.

Actually, it's not quite the preloaded trust anchors we're talking
about. It's the updated keys that get validated using those preloaded
anchors.

It's a given that you're going to start with some key to bootstrap your
trust in DNSSEC, and that key is going to be preloaded. Then you're
going to download some updated DNSSEC trust root, and validate it
against your preloaded key.

The question is how the downloaded key got signed.

From my point of view, some person or persons, inside or outside of
Cisco, is going to have the ability to cause a new DNSSEC root key to
get signed using that preloaded key.

That person or persons is NOT going to be the same person or persons
who generates the software loads. I'm adding a new trusted entity
to the system.

I think you're saying "well, let Cisco be trusted; it's trusted already
anyway". That's true if you look at Cisco as a monolith, but I don't
have that luxury. Something has to be set up inside Cisco to deal with
handling these keys. The complexity still exists; it's just been made
less visible from a certain point of view.

So, the question is whether it's better to have a single, publicly
visible process that may be able to break a very large number
of devices, or a large number of hidden processes each of which
can break a smaller number of devices.

I tend to prefer the former.

						-- jbash