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