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

[S Moonesamy]

Hi Mike,
At 10:48 23-09-2014, Michael StJohns wrote:
>To clarify this:  I believe you need to retain the capability to do 
>a "full trust reboot" for the life of DNSSEC.  I also believe that 
>if you ever have to do it, the results will be catastrophic.  My 
>third belief, is that the process for doing the FTR (new acronym as 
>of now), will need to be maintained and updated and probably won't 
>adequately be.

I'll read "full trust reboot" as having a state similar to start 
(2010).  In my opinion, it is not possible.  I agree that the process 
still needs to be maintained.

>I understand your lack of agreement.  However, there is risk to 
>everything.  As I said above, having to do an FTR will be 
>catastrophic.  That could change over time if you socialize it and 
>keep socializing it so that the every 5-7 years you do it people 
>understand why its necessary and "nothing bad" (tm) happens.  The 
>risk you have with the status quo is that a completely unlikely set 
>of events happens (e.g. root compromise) and you're midway through 
>your cycle.  No one knows where the knobs are to replace their root 
>trust anchor configuration, everyone yells, and the root gets taken 
>away from ICANN because it hasn't been a good caretaker.
>
>The major risk for putting together a key replacement cycle will be 
>when you revoke the current existing sole root of trust key.  That's 
>when things have the most potential to break because it will be the 
>first time we've done it.  That applies both to 5011 and FTR.  Get 
>past that and a 1-2 year replacement cycle that's handled on an 
>automated basis near universally is pretty much risk negative.

Yes.

>This is where the *sigh* creeps back in.  ICANN has specified in the 
>DPS that 5011 is the method for doing key replacements.  If they 
>don't want to do 5011, you've pointed them to where the root key 
>files are and they're responsible for tracking them 
>manually.  That's doesn't require that everyone has 5011, it does 
>require that everyone be responsible for their own deployments.
>
>If you now change the DPS and say "we were only kidding, we're not 
>going to use 5011", then you run into the whole problem of systems 
>that were "relying" (legal term) on your assertions and not 
>realizing they need to do something different when you update the root sets.

I'll list two items:

   (a) When the key roll-over is scheduled

   (b) How it will be done.

I read item (a) as the five-year mark (2015).  Item (b) is RFC 
5011.  Another person might interpret item (a) as ten years; it 
postpones doing item (b).  If an improbable event [1] occurs within 
the next five years the Security Director might have to provide an explanation.

Regards,
S. Moonesamy

1. 
http://www.onderzoeksraad.nl/uploads/investigations/Press_release_DigiNotar_280612_EN_opgemaakt.pdf