Subject: Notes on DNSSEC key rollover

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Jul 2006 06:39:06 -0700

[Resent now that I've fixed my subscription....]

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.

-Ekr

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Jul 2006 10:03:37 -0400

>Rambling follows....

Amazingly clear and concise rambling at that.

>cuts against that theory.

The difference between the use of KSK and ZSK is in what is 
communicated to the parent administration.  The pattern of use seen 
in workshops that gave rise to the distinction was that we wanted to 
be able to change some keys quite often without having to go back to 
the registration process and make changes there.

The distinction is born out of operation patterns and not 
cryptographic considerations.  The KSK appeared as a "populist" 
reaction to having a formal boundary between parent and child.  The 
KSK wasn't intentionally invented, the distinction was initially 
discouraged because we had been burned by trying to define key 
strength semantics in DNSSEC (RFC 2065/56, I forget) and DNSSEC II 
(RFC 2535).

This is whence KSK and ZSK came.  The KSK for some zones can be 
thought of as a high-assurance key, at least in institutional 
operations.  The DNSSEC protocol however does not make the 
distinction between ZSK and KSK, and maybe that is where we are 
slashing against the theory.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 27 Jul 2006 15:01:56 -0400

Eric Rescorla wrote:
> 
> I've taken a look at the various dnsext key rollover [...]
> 

Thanks for sharing this fresh look at this issue.

> [...]
> [...]

Not exactly. The security model for -timers (and perhaps -threshold as 
well) is more or less that K_n, *when or soon after it becomes 
"operational"*, signs K_n+1 which becomes "operational" at the end of 
operating period for K_n. These are all KSKs (to the extent that KSK/ZSK 
separation is present and relevant). The security strength is based on 
the assumption that private key compromise is less likely at the 
beginning than at the end, of the operational period.

(In a previous post, I wrote "The incremental security in moving from 
the Paul Vixie approach to either -threshold or -timers is marginal ..." 
a comment which I consider unjustified now since I understand the 
-timers security model as explained in the previous paragraph.)

The classic approach you describe is not reflected in any DNSEXT proposal.

The TAKREM approach (draft-moreau-dnsext-sdda-rr, 
draft-moreau-dnsext-takrem-dns) is based on pre-announcements of a 
series of fingerprints for future keys.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]