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

Michael StJohns msj at nthpermutation.com
Sun Sep 21 19:01:05 UTC 2014


On 9/21/2014 2:37 PM, David Conrad wrote:
> On Sep 21, 2014, at 10:49 AM, Michael StJohns <msj at nthpermutation.com> wrote:
>> Worst case is compromise of all trust anchor keys.  5011 allows you to recover from an N-1 compromise (where you have at least one private key associated with the root trust anchor set that hasn't been compromised).
> This has always been my problem with 5011-based rollovers.
>
> Given the protections specified in the DPS, all the scenarios in which we have to do an emergency key roll seem ridiculously unlikely.  However, I assume we have to be prepared for the worst case scenario. Since 5011 can’t help us with that scenario and emergency key rollovers is a superset of planned rollovers, I’ve been unclear as to the advantage 5011 provides.
>
> And then there is the issue of (likely permanent) lack of universal implementation of 5011...
>
> Am I missing something?

I think someone once said that "Democracy is the worst form of 
government, except for all others".   5011 is pretty much the same with 
respect to DNSSEC.  If you go back to the original requirements document 
(which was hard fought), you'll see the assumptions we made about what 
might be possible.  5011 has the advantage of being in-band, is designed 
to work without dependence on non-DNS (e.g. x.509 PKI) infrastructure, 
and understands the difference between the DNS transport protocol and 
the DNS data protocol limitations. It was also designed to work with 
existing DNSSEC implementations through the addition of a simple program 
that could do 5011 DNS queries and update the local DNSKEY trust anchor 
stores.

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.  The goal of 5011 was to provide a set of mechanisms that could be 
used to minimize the chance of a complete root trust anchor compromise 
and recover from anything but that complete compromise. I think it met 
that goal.  The problem I have now is that whoever set up the current 
root of trust either didn't actually read the "protection only applies 
if you have more than a single root of trust" or avoided placing a 
second root of trust for some reason that seemed to make sense at the 
time.  What should have happened when this got started was for 2-3 roots 
of trust key sets to be created and distributed as part of the initial 
bring up.  Neither 5011 nor DNSSEC require that more than one of those 
roots of trust be present in the published RRSet if the argument was 
about space in the replies, but the current model means that - absent 
5011 or a year to two (five?) year publicity campaign to add new trust 
anchors - we've got a problem with superseding the existing KSK key, 
emergency *or* planned.

I designed a pretty good protocol.  I was somewhat dismayed when the 
deployment at the root didn't match 5011 requirements, even though the 
DPS cited 5011 as the operational model.

But that's past.  What do you want to do next?

WRT to 5011, one way to do a rollover exercise without screwing over the 
non-5011 resolvers is to do the following:


Current KSK is A - it stays.
Add B key.  (plus 30 day hold down)
Add C key. (plus 30 day hold down)
Revoke B key.


The TA set goes from {A} to {A, B} to {A,B,C} to {A,C}.  The servers 
that only know A continue to work.  Other servers update their TA store 
and we do some post twiddling analysis to see whether or not the updates 
made it through.

Later, Mike






>
> Regards,
> -drc
>



More information about the ksk-rollover mailing list