Subject: Re: Notes on DNSSEC key rollover

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

At 6:39 AM -0700 7/27/06, Eric Rescorla wrote:

>Rambling follows....

Amazingly clear and concise rambling at that.

>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.

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.

--
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: 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.

> ROLLOVER
> --------
> [...]
> 
> 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.
> 
> [...]
> 

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]