Notes on key rollover in DNSSEC

|
I've taken a look at the various dnsext key rollover
documents and wanted to provide some comments. This
is the first of two messages, the first up-levelling
on the general rollover problem, and the second providing
specific comments on draft-ietf-dnsext-trustupdate-timers.

Rambling follows....

BACKGROUND
----------
DNSSEC, like nearly all public key authentication systems, assumes
that you have some set of trust anchors configured into your system
and that you use them to transitively verify other keys in the system
[0]. Pretty much by definition, the initial set of trust anchors are
either shipped with the verifying software or are manually configured.
There's then a machine verifiable chain of signatures from some trust
anchor to any given verifiable data item (e.g., certificate).

The question then arises about how to replace the keys for
the trust anchors. Roughly speaking, there are two reasons 
to roll over your signing keys:

1. You're trying to stay ahead of the attacker's cost curve
   (Moore's Law, progress in factoring, etc.)
2. Your key(s) have been compromised.

Reason 1 is fairly straightforward. At time 0, You make a key (K0)
with an expected lifespan of X years. At a reasonable time before X
(say X/2) you generate a new key (K1) with an expected lifespan of Y
years and distribute it somehow. The way this is done in browsers is
that you just get the new key placed in the current revision of the
browser and assume that the new revision will percolate out before key
K0 expires.

Reason 2 is more problematic and the browser world has mostly chosen
to punt on it. The theory here is that if a root key is ever known to
be compromised, the browswer manufacturers will just release a
security patch without that key--and maybe with the replacement--and
propagate it via the usual mechanisms. Given that there are lots of
security vulnerabilities worse than a compromised key and we let the
ordinary patch process handle them, this doesn't seem crazy.

In other words, the browser world doesn't have any mechanism
for root rollover separate from the normal software update
process.


ISLANDS
-------
In an ideal DNSSEC world, there would only be one trust anchor: the
root signing key, or a small number of mostly static anchors, like the
100 or so that are in your average browser. As a practical matter,
people seem to be assuming that there will be a bunch of islands--signed
subtrees within a generally unsigned DNS tree. The problem that people
appear to be grappling with is:

     (a) How to provision those island keys.
     (b) How to roll them over if they're compromised.

To that end, we have (at least): 

     draft-ietf-dnsext-rollover-requirements-02
     draft-ietf-dnsext-trustupdate-timers-02
     draft-ietf-dnsext-trustupdate-threshold-01
     draft-laurie-dnssec-key-distribution-02

The matter is somewhat complicated by the fact of multiple certificate
formats. So, for instance, one could imagine that you were operating
the island "example.com". You could get an ordinary SSL/TLS
certificate from VeriSign for "example.com" and distribute your DNSSEC
trust anchor definition over SSL/TLS. From a DNSSEC perspective, this
is automatic provisioning of the island key, but from a security
perspective it's a single root of trust rooted in VeriSign and is
isomorphic to ordinary CA operation. A similar situation would obtain
if, e.g., ISC periodically published a new island key list for BIND
users to download. 


PROBLEMS TO SOLVE
-----------------
It seems to me that there are three problems that need to be solved
here: 
      1. How to initially provision island keys.
      2. How to transition between two keys (assuming you have some
	 way to validate the replacement key).
      3. How to validate the replacement key.

Problem 2 is a straightforward protocol engineering problem. I
get the impression that it's not entirely solved based on
S 3.8 of draft-ietf-dnsext-trustupdate-threshold, but it's
not tricky in any abstract sense. Problems 1 and 3 are tricky,
however.


INITIAL PROVISIONING
--------------------
Roughly speaking, there are four classes of initial provisioning
solutions:

- Manual provisioning  -- you manually enter the keys
- Leap of faith	       -- you trust the first key you get 
			  for a given zone
- Central trust anchor -- you trust signatures from some 
			  central trust anchor. This could
			  either be a conventional CA like I
			  indicated in my example above or
			  just your software vendor who ships
			  you the current trust anchor list
- Web of trust	       -- you trust some set of people and they
			  sign keys for other people and you
			  somehow compute a trust metric over
			  the signatures.

Note that a central trust anchor is basically just a single
root and it makes sense to treat it that way, even if the
signatures are done with some non-DNSSEC mechanism. So,
for the purposes of rollover we'll assume you're provisioning
some other way.


ROLLOVER
--------