[dns-operations] Root KSK rollover and trust anchors (was Re: .Org DNSSEC key management policy feedback)

[Roy Arends]

On Jun 25, 2009, at 9:33 AM, Joe Abley wrote:

> I have been involved in more than a couple of discussions about  
> trust anchor publication for the root over the past while. Setting  
> aside the publication mechanisms themselves, I think the interesting  
> question is how we accommodate KSK rollover without requiring end- 
> user gymnastics.
>
> (Apologies if this looks like thread abduction; if I imagine the  
> root trust anchor to be special in the sense that it conceivably  
> could be the only one installed for many people, then this problem  
> seems related to what you and Andrew were talking about.)
>
> There have been parallels drawn to X.509 CA cache updating through  
> vendor-specific update channels ("Windows Update" and friends).  
> There has been talk of 5011, but concern over how a device which  
> disconnects over the rollover window might recover when it wakes up.
>
> KSK rollover is not optional. At the very least we need an emergency  
> rollover plan which can be tested, which means we need scheduled  
> rollover. This is not just personal opinion.
>
> One approach I have heard which seems operationally satisfying:
>
> 1. Pre-generate a large number of KSKs, for some sensible value of  
> large.
>
> 2. Generate a SHA2 hash of each public key, and store the KSKs  
> securely, off-line. "Securely" would need to be quantified, and  
> confidence would be required that it was sufficient.
>
> 3. Publish the complete set of SHA2 hashes as a set of trust anchors.
>
> 4. Plan a fairly aggressive KSK rollover schedule so that KSK  
> rollover is a regular, common thing that people get used to dealing  
> with. Roll with 5011 semantics, because why not.
>
> 5. Each time the KSK rolls, update the trust anchor set (e.g. remove  
> the rolled key, add the next future key in the schedule)
>
> Operationally, this might give a disconnected device, or one  
> installed from old media, etc enough insight into the future to find  
> a trust anchor that would work. That might provide a window in which  
> automated vendor updates and other such ancilliary mechanisms could  
> patch over the time debt, and provide hands-off continuity for end- 
> users.
>
> Cryptographically, we are not publishing anything other than current  
> DNSKEYs plus SHA2 hashes of DNSKEYs which might be used in the  
> future, so perhaps the concern about factoring future keys is  
> mitigated.
>
> Presumably we would adjust the period of future time over which  
> trust anchors are pre-published to find a compromise between  
> operational comfort and cryptographic nail-biting. We'd still need a  
> plan for a physical compromise of the off-line KSK set, which would  
> presumably be the scorched-earth option and we would try hard not to  
> have to push the big red button, ever.
>
> From the DNS operations perspective, I'd be interested in peoples'  
> reactions to this.

I love it.

Roy