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

[Paul Hoffman <[e-mail]>]

On 1/28/11 9:28 AM, John Bashinski wrote:
> 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.

A moving part that is "off to the side" but becomes "quite central when 
something goes wrong" is not really "off to the side". It goes from 
unimportant to completely critical just like very other moving part does.

> 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.

We fully disagree. Trust anchor loading (whether initial or while the 
system is running) is *always* unique to every vendor and, quite 
frankly, to every customer who actually cares about their trust anchors. 
You may not think this because 99.99% of users of trust anchor stores do 
this blindly, but many of Cisco's router customers (and folks like them 
that the DNSSEC community care about) do care about this.

Having each vendor "do this" with DNS security is exactly the same as 
having each vendor "do this" with software security. The fact that Cisco 
has a PKIX signing key that verifies software loads differentiates it 
from some of its competitors who don't do any software validation, and 
makes it similar to some of its competitors that do it in similar ways. 
Trust anchors are the same.

>> 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.

Those have identical security properties to the users. If their vendor 
made it hard or impossible to get the latter when needed, the users will 
(rightly, IMHO) blame the vendor for the users' reduction in security.

> 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.

Yep.

>  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.

It could be / should be a person who is trusted within Cisco to the same 
level as the person who generated the software loads. She doesn't have 
to be the same person.

> 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.

If you trusted Employee A to fetch the DNS root key at time X and 
include it in the initial firmware loads, you can trust Employee A at 
time Y to do it again for updates, or you can trust Employee B at time Y 
if you would have trusted Employee B to do the firmware loads.

> The complexity still exists; it's just been made
> less visible from a certain point of view.

Fully agree.

> 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.

That's one way to phrase it. Another would be "whether it's better to 
have a single, publicly visible process that may be able to break a very 
large number of devices and is more complicated than the 
already-complicated process we have now, or a large number of hidden 
processes that have the same local security properties we have now where 
those hidden processes already can (and do!) break a smaller number of 
devices".

> I tend to prefer the former.

Understood. From a security and deployment standpoint, the latter is 
what we already have today, and it might be better to continue to do it 
(and maybe even document it) than to make the current DNSSEC 
infrastructure more fragile.