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

[John Bashinski <[e-mail]>]

On 2011-01-28 12:32, Ted Lemon wrote:
> On Jan 28, 2011, at 12:12 PM, Nicholas Weaver wrote:

>> As long as all the historical data is available someplace that the
>> device knows about
>> (eg. http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02
>> .  Or pick whatever...), there is no excuse for not using this style
>> of mechanism.

> There's no way to validate this, so you might was well be trusting
> instructions written on a bathroom wall.

You validate it by tracing the signature chain from whatever key you
start with through the first one. That does mean trusting the whole
chain, but it's definitely validation.

> This suggests another knob to tweak.  Firmware in self-updating
> devices should have a manufacturer-configured key, but the
> manufacturer should use that key in no more than N devices, for some
> TBD value of N.  This reduces the value of the firmware key, more
> substantially the smaller N is, to a limit of N=1.

There are tradeoffs there, and they're not just cost tradeoffs.  A
system for managing a whole bunch of keys is necessarily more complex
than a system for managing just one. It handles higher volumes of
data. It updates things more frequently (which means updates can't be
scrutinized as hard). It has more parts that have to be kept online or
near-line. Those all hurt the security.

>> Anything else MUST either add additional keys to the trusted root,
>> and/or becomes the trusted root instead.  In the former you're
>> weakening the system (you now trust both the . KSK AND some 'random'
>> PKI certificate, as a compromise of EITHER is sufficient to break
>> your security), in the latter you're just replacing one key roll
>> problem with a second (how do you roll the PKI certificate?).

> I think it's important to realize that any device that auto-updates
> already has one of these keys in it, and that key can be used to
> update the root zone key on the device, if the device even has a root
> zone key on it.  So it's not the case that this mechanism makes things
> less secure.

Not all devices auto-update. In Cisco's case, I don't think we have
ANY pro gear that auto-updates, and most of our consumer gear
doesn't auto-update, either. What you're talking about is one
of the reasons for that, and we probably won't have widespread
auto-update until we have better answers.

Of course, it's also true that it's probably pretty easy to trick most
people into manually installing bogus software (or DNSSEC roots) on
their devices, but we'd rather not make that an automated thing...

> We can certainly have a debate about which sort of compromise is more
> or less likely, but I find the idea of a "limited leap of faith" sort
> of like the idea of a "limited leap off a cliff."  Unless the cliff is
> only a few feet high, the absolute height of the cliff is immaterial.

That's a deeply misleading analogy, because the effects aren't
similar at all. Temporal extent of exposure matters.

You can:

1. Not validate at all. This makes you pretty easy to spoof,
   at any time anybody decides to spoof you.

2. Learn the root key by "pure faith" at initial installation. This
   is a very significant improvement; it means that anybody
   who wants to spoof you has to be prepared to do it at
   a specific time (which may be hard to predict). They have
   to plan in advance to target you specifically. And they have to get
   you on the first try.

3. Learn the root key by "limited faith". This is another siginificant
   improvement; it means that somebody has to keep a DoS or something
   running continuously from the moment you're installed up through
   the moment they want to feed you bad data. Which could be
   months. If they slip up at any time, you learn a good key and they
   lose the ability to hurt you. And they're very likely to be
   detected.

4. Learn the root key using a bootstrap key and never rely on "faith".
   Nobody can ever spoof you, although you still have exposures
   from key compromise or people leading the legitimate key holder
   to sign something it shouldn't.

Those aren't remotely equivalent exposures.

						-- jbash

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext