Re: Notes on DNSSEC key rollover

Thierry Moreau <thierry.moreau@connotech.com> Thu, 27 July 2006 19:01 UTC

From: Thierry Moreau <thierry.moreau@connotech.com>
Subject: Re: Notes on DNSSEC key rollover
Date: Thu, 27 Jul 2006 15:01:56 -0400
Lines: 78
References: <20060727134709.BFCB8222425@laser.networkresonance.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: namedroppers@ops.ietf.org
X-From: owner-namedroppers@ops.ietf.org Thu Jul 27 21:04:36 2006
Return-path: <owner-namedroppers@ops.ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Eric Rescorla <ekr@networkresonance.com>
In-Reply-To: <20060727134709.BFCB8222425@laser.networkresonance.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
X-Message-ID:
Message-ID: <20140418072223.2560.37075.ARCHIVE@ietfa.amsl.com>


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

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: thierry.moreau@connotech.com


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