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

[Joe Abley]

On 25-Jun-2009, at 02:33, Paul Vixie wrote:

> practical security -- that is, security that can be and will be  
> practiced
> -- 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  
> at
> the point where nameserver operators can succeed with dnssec in  
> ignorance.

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.


Joe