[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