« Gah! To much salt! | Main | If Isaac Asimov designed your computer... »
July 26, 2006
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
--------
If rollover is very rare, then you can handle it via whatever
mechanism you use for provisioning. For instance, if your
SSH client detects a key change, you call the admin and
check the new fingerprint. A similar approach could be used
for manual keying here. However, if rollover is frequent
then this clearly becomes impractical.
The natural way to handle automatic rollover for non-compromised
keys is simply to have each key have an expiry date and for
K_n to sign K_n+1 well before it expires. This has an obvious
problem when what you're worried about is compromise of key
K_n, since any signature from K_n is inherently untrustworthy.
The classic approach to dealing with this problem is to have
two keys:
1. An operational key which is used to sign data.
2. A high-assurance key which is only used to sign operational
keys.
The operational key has a modest security level and is signed by the
high assurance key. If an operational key is ever compromised the high
assurance key is used to sign a new operational key (and depending on
the system, a revocation).
The high-assurance key has a very high security level (keylength) and
is generally maintained in some sort of trusted computing environment
(i.e., hardware). It has a very long expiry and is assumed never to be
compromised. If it is compromised, it's an emergency and you handle it
in some out-of-band manual way (e.g., publish a CERT advisory). You
can roll over the high assurance key in non-compromise cases as
indicated above. [1]
This is sort of similar to the ZSK/KSK split in DNSSEC but it's not
entirely clear to me if people intend the KSKs to have very long
lifespans and to be used very infrequently, which is what's required by
this security model. In particular, it appears from the various documents
that people intend to be able to rollover compromised KSKs, which
cuts against that theory.
Posted by ekr at July 26, 2006 8:34 PM | Filed under: