[ksk-change] planned vs. emergency (was Re: [ksk-rollover] root zone KSK ...)

[Michael StJohns]

On 9/21/2014 4:03 PM, David Conrad wrote:
> Mike,
>
> On Sep 21, 2014, at 12:01 PM, Michael StJohns <msj at nthpermutation.com> wrote:
>> You say "5011 can't help with that scenario" ... but the truth is, NOTHING can help you with that scenario due to the one-way nature of DNS data.
> Actually, nothing _in-band to the DNS_ can help.
>
> However, IIUC, we must be able to cope with scenarios in which we can’t trust any of the keys. I believe there are two scenarios in which this occurs: bootstrapping and catastrophic compromise of all keys.  As far as I am aware, 5011 cannot help either of these cases, so we have to have some mechanism that will allow for key {rollover,change} without the benefit of 5011.
>
> Given this, I’m still struggling to see the benefit that 5011 brings. This is not intended as criticism of 5011, rather it is a question related to pragmatics.
>
> Regards,
> -drc
>

What I think you're saying above is basically, "I don't want a system 
that can deal with the most likely single compromise scenarios, but that 
I want to do a full scale trust reboot every so often and require 100 of 
1000s (millions?) of manual updates of trust anchors." You seem to be 
saying that you want the trust reboot system to be the same as the 
normal key supercession process.  Or am I missing what you're trying to 
do here?

5011 is for the normal update and supercession of keys short of a 
complete trust reboot.  It provides mechanisms for revoking keys, and 
for updating trust anchor sets in a secure and automated fashion.  It 
explicitly was not designed for a trust reboot as no trust reboot with 
total compromise can be done in a secure and automated fashion.  See 
discussion below.


Axiom:  If you lose your last trust anchor, you're screwed.  You 
basically have to reboot trust from scratch.
Discussion:  At some point along the path, the person configuring a 
resolver (or trust validator in non DNS terms) has to make a leap of 
faith; to believe (hopefully with sufficient evidence) that the trust 
anchor(s) he's been handed are really *the* trust anchors for the 
system  (this is what happened when the root was signed for the first 
time - or more probably when you turned on DNSSEC in your resolvers and 
used the vendor provided set).  Within that system, all downstream trust 
(e.g. key rollovers validated by that root of trust or a chain back to 
that root of trust), is derived from that original leap of faith, and 
given an unbroken chain and sufficient process, you can continue to 
update your trust anchors with new trust anchors based on that original 
trust relationship.  Consider what happens if at a single point in time, 
all of the key material related to current trust anchors becomes 
compromised:  you're now at a clean slate.  You can no longer trace your 
trust back to the original trust relationship.  To start again, you need 
to repeat the original leap of faith and make a conscious (not 
programmatic) decision to trust a newly minted trust anchor - either 
using the same process as before, or come up with a new one.  Regardless 
of process, there's a need to make the leap of faith in the process of 
populating the replacement trust anchors.   This applies whether the 
trust anchors are DNSSEC KSK for the root trust anchors, or a CA signed 
X.509 cert signing a blob containing trust anchors.  At some point along 
the way, you have to manually make a decision to renew trust.

Axiom: If at any time, you have at least one valid trust anchor, you can 
establish more trust anchors.
Discussion:  In DNSSEC 5011 its actually, as long as you have at least 
one uncompromised trust anchor private key which remains uncompromised 
for the Add hold-down time, you can add new trust anchors.

Corollary:  If you haven't lost your last trust anchor, you are not screwed.
Discussion:  As long as you can keep ahead of compromise of trust 
anchors, you don't have to do a reboot of trust.

Corollary:  Having only one root of trust is bad.  Regardless of whether 
its PKI or DNSSEC or something else.
Discussion:  The problem is scalable; in a small local system where one 
entity controls both the thing to be trusted and those who have to 
trust, a single root is probably manageable.  That, however is not DNS.  
In the current case, one root of trust (one root KSK in the trust anchor 
set) plus a single compromise equals a need for a trust reboot on a 
global scale.  We should avoid that.

I understand why you're looking at the "oh my god it's all broken" 
scenario.  But you'd be better off looking at how to prevent it to a 
statistical certainty.  There is NO model existing that allows you to 
recover automatically from a complete compromise of root of trust key 
material; not in PKI, not in DNSSEC.

 From the above, you're looking for the "how do I reboot trust" 
solution, not "how do I deal with compromise" solution.  That may be 
useful for appendix F of how to run the root in the event of 
catastrophic failure, but not so useful day to day.  Instead look for 
"How do I deal with compromise" and "How do I prevent to a high 
probability the need to reboot trust"?  The simplest way to do the 
second is to increase the number of trust anchors in the root, and 
sequester the key material needed to sign with those trust anchors in a 
manner that a) prevents fate sharing (e.g. one compromise does not 
result in another), and b) limits the probability of loss of the key 
material (i.e. a trust anchor without a useable private key can't be 
counted as a useable trust anchor).


Later, Mike