Comments on ICANN Key Roll-over consultation

[Ron Aitchison <ron@xxxxxxxxxx>]

(this email was originally sent on Friday 12th April)
Some comments and observations on your questions.
I apologize in advance for the lack of time to do the necessary 
background research, any figures are from memory - an increasingly 
unreliable source it must be noted - or assumed as a scale order of 
magnitude and would need to some validation. I further acknowledge that 
my views on this issue have significantly changed from 'early and often' 
to 'as late and as infrequently as sensible' for the reasons I try to 
outline below.
Preamble:
1. Thanks to the good work of ICANN and those folks who helped design 
the initial implementation we have a stable signed root base on which to 
promote and develop DNSSEC awareness and implementations. We should be 
wary about placing this at risk either technically or even more 
importantly (since we all know that even given the best planning in the 
world a roll-over will lead to at least one high profile domain going 
dark - best laid plans of mice...) in terms of public visibility and 
confidence.
2. We are all geeks and love messing around with this stuff. However, 
just because we have various protocols and procedural elements in place 
does not mean to say we have to use them. I think it's a fair 
characterization of the current state of DNSSEC to say that we are still 
in a learning phase - our understanding is improving (rapidly?) and will 
improve over time given both operational exposure and focused 
development/experimentation (which is happening).
3. Our understanding of the complete DNSSEC picture is currently 
incomplete especially when we consider end to end security (validating 
stub resolvers). Whatever short-term gains we make by testing, say, the 
ability of current validating area resolvers (the dominant current 
architecture) to handle roll-overs will, I submit, not be terribly 
useful in the longer run if faced with a 1 billion stub resolvers. We 
are thus faced with an ongoing risk situation. No single event in time 
and space will eliminate it.
4. If we look at the experience of the CA (SSL/X.509 certificate) 
business then we see stability (lack of change) being the order of the 
day. While no fan of the SSL business, their experience here has at 
least some relevance. Root certificates with validity periods in the 
2022 to 2027 were dominant as I recall. I know of no reputable CA which 
has had a compromised root certificate key. Others closer to this 
industry may have greater insight.
So for me the real question is: When do we need to roll the root KSK?
I would submit that the answer to this question is:
a. assuming the current ICANN 2048-bit key
b. assuming we believe NIST's recommendations on key size
c. assuming ICANN can recreate the current key in a new HSM (at the end 
of its operational life)
d. assuming we 'trust' ICANN's open process and physical security as 
much as we trust a commercial CA
then the answer must be somewhere in the period 2027 to 2029 allowing 
for a slow'ish planned roll-over before the current NIST change of key 
length recommendation date of 1st January 2030. Any decision to change 
before this date is a deliberate choice and arguably unnecessary.
Note: The question over whether we will need to change the hash 
algorithm prior to this point due to discovered weaknesses is, frankly, 
much more interesting and a darned sight more difficult to accomplish 
since it will likely require synchronized software functionality upgrades.
Two further questions follow:
1. How does ICANN handle its contractual obligations to roll the KSK?
I submit that it would not be responsible to place at risk the 
operational signed root simply to fulfill a contractual obligation. I 
would further submit that, depending how the root is defined, and, as 
others have suggested, running a parallel root may enable greater risk 
reduction. In short, rolling the root on a one-time basis will not 
de-risk the future which I assume to be the (laudable) objective of the 
contractual obligation.
How could the risk be minimized?
These are not fully developed ideas but are offered in the hope they may 
trigger thoughts in worthier brains than mine.
a. create a 'parallel' or 'alternate' root under the .arpa domain. This 
root would only contain KSK/ZSK RRs.
b. It would not be used operationally but could be rolled at will as a 
permanent test bed.
c. Certain locations/DNS software types selected by ICANN  could be used 
to sample results of rolling operations (KSK/ZSK/hash/encryption changes).
d. such an alternate root could (depending on its provable separation 
from the operational root) even be used in the event of a catastrophic 
key compromise (currently a manual recovery under 5011).
Frankly, given:
i. the evolving nature of the DNSSEC landscape
ii. the increasing requirement on knowledge of the operational 
capabilities of the installed base so that ICANN can take informed 
minimal-risk decisions
I would far rather ICANN continue with its proactive efforts to develop 
a planned DNSSEC environment (along with its contractors and advisers) 
rather that expend effort in a single KSK roll that, with the best will 
in the world, buys us very little.
Regards

--
Ron Aitchison                      www.zytrax.com
ZYTRAX                             ron@xxxxxxxxxx
                                   tel: 514-315-4296
                                   Suite 22
                                   6201 Chemin Cote St. Luc
                                   Hampstead QC H3X 2H2 Canada
Author: Pro DNS and BIND (Apress) ISBN 1-59059-494-0