Comments on ICANN Key Roll-over consultation
(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 sizec. 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 landscapeii. 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