[dns-operations] Root KSK rollover and trust anchors (was Re: .Org DNSSEC key management policy feedback)
roy at dnss.ec
Thu Jun 25 03:47:29 UTC 2009
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
> 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-
> 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
> 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.
More information about the dns-operations