[dns-operations] Root KSK rollover and trust anchors (was Re: .Org DNSSEC key management policy feedback)
jabley at hopcount.ca
Wed Jun 24 23:33:50 UTC 2009
On 25-Jun-2009, at 02:33, Paul Vixie wrote:
> practical security -- that is, security that can be and will be
> -- must support some level of ignorance by consumers. early dnssec
> implementations (up to and including current BIND9) don't offer nearly
> enough "ignorance support" for my taste. some dnssec implementations
> (secure32, sparta, BIND9 9.7)
Secure64 lite? :-)
> improve this situation. RFC 5011 will also
> improve it. and we should all expect continuous improvement, ending
> the point where nameserver operators can succeed with dnssec in
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-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.
More information about the dns-operations