A root zone KSK rollover consultation response
What I've learned in 15+ years of messing with cryptography as applied to DNSSEC is that I still don't know anything at all. The cryptographic elements of the key change are still a mystery, including the answer to the question is whether this is even necessary. But, it's a obligation in a signed contract, and I believe operational processes need to be practiced regardless of the reason for them. So I see this as an operational exercise first and foremost. The "bottleneck" is making sure that the uncountable, non-enumeratable, potentially anonymous DNSSEC validators have the new KSK inserted into them in a timely fashion (as well as removal of the old KSK). Everything else is easy. It's going to come down to the outreach. Probably question 6 is the most crucial. 1 What prerequisites need to be considered prior to a first scheduled KSK rollover? DNSSEC at the root should be operating stably. I.e., avoid a coincident ZSK change, name server address change, planned maintenance of any critical system. (Understanding that "emergencies happen.") Have a rough idea of how many validating caching servers are in deployment and some notion of how to contact the operators of the busiest servers (with busy meaning number of relying stub resolvers) if the need should arise. Accumulating such a list is not an easy and straightforward task, despite the list destined to be incomplete, the longer it is, the better. Have a plan of how the KSK Key Ceremonies are impacted - in activities and participants. New HSMs? Tech refresh? Change in the participant base? Have a plan to coordinate (with) root server operators when actions happen, outside of DNS-based communications. Possibly a subset of the operators "should be in the room." 2 When should the first scheduled KSK rollover take place? As soon as possible, but not in a rush. As more and more validators are deployed, the impact of a potential failure grows. Note I say "impact" as opposed to risk of failure. 3 What should the IANA Functions Operator (ICANN) and the other Root Zone Management Partners do to gauge the technical and end-user impact of a KSK rollover following the first scheduled KSK rollover? Monitor response from as many validating caches as is possible, measuring the presence of the authenticated data flag in the response. Be in touch with widely deployed caching validators to glean at least a sampling of impact. 4 How often should a scheduled KSK rollover take place, following the first one? There could be three triggers. One is the cryptographic need to replace the key, which is pretty much unpredictable and most likely not the limiting factor. Two is the lifetime of equipment, including maintenance contract availability, which should be engineered to not being a limiting factor. Three is the need to practice the process which is arguably limiting factor. There's no track record of DNSSEC history to know what is the "bare minimum" to address the threat nor any measure of incremental benefits. From this it's hard to guess at a specific timeframe. Perhaps the timeframe should be once every few years. 5 How far should the published calendar for scheduled KSK rollovers extend into the future? Hard to say, probably it will take a few KSK key changes to know what time is needed - and this will probably grow as validation is deployed further. As for operators, I don't think a calendar well into the future is any more valuable than knowing what's happening in the next 6 months. 6 What public notification should take place in advance of a scheduled KSK rollover? Operations groups - an informal means. There's no enumeration of all that "need to know" so there's no specific venue. But assuming that anyone adopting the ICANN KSK and becoming a relying party will have to have knowledge of ICANN and that can be used to point to where notices are to be sent. The RIRs are a good place to start, they'll be the closest to the NOG's in their regions. Then there are the TLD trade organizations (CENTR, APTLD, etc.). And rely on ISOC's Deploy360. Come to think of it, the web browser fora might be a place to go too. 7 What other considerations are necessary for the Root Zone Management Partners to take into consideration prior, during, and after a planned key roll over? Once a key change is started, it should come to completion. I.e., having an ever-growing root/IN/DNSKEY RRset is not desirable. PS - Repeating an idea from Jay Daley (.NZ): "have you considered rolling from a key to itself to test the mechanisms?" This might not solve the problem of having to change static configurations, but it'll be a start. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.