A root zone KSK rollover consultation response

[Edward Lewis <Ed.Lewis@xxxxxxxxxxx>]

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.