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

[Ted Lemon <[e-mail]>]

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

I think the reason I disagree with you on this is that your threat model is narrower than mine.   I agree that for this threat model, and the others you describe, "limited faith" is an improvement.   But what I'm concerned about are situations where the network is "owned," as Nicholas likes to put it.   In these situations, a compromise that allows the attacker to present a consistent DNS using an old compromised root is a lot harder to detect than one that requires the attacker to know the specific key for your device that must be compromised.

I am not arguing that consistency checks are a bad idea.   If you can catch your attacker in a lie, that's good.   If your attacker can't reliably lie to you, that's also good.

But the particular leap of faith involved in tracing back history using an unauthenticated history list is useless in the face of a key compromise, because once you have that key, you can create a fake history that looks just as legitimate as the real history would; the fact that it validates does not mean that the later key is legitimate.

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

This isn't strictly true.   DNSSEC is an example of a system that allows for the management of a large set of keys in a secure manner, with the sensitive secrets maintained offline, and yet with full validation possible online.

I don't mean to say that there would be no cost associated with a system like the one I'm talking about, but I think the per-unit cost would be reasonable for useful values of N.

I won't get into the question of auto-update; suffice it to say that no consensus exists that auto-update, done well, is *less* secure than manual-only updates.