Subject: [DNSOP] draft-morris-dnsop-dnssec-key-timing-00

From: [email-masked]
Date: Tue, 17 Feb 2009 16:20:53 +0000

John Dickinson and Johan Ihren and I have just submitted 
http://www.ietf.org/internet-drafts/draft-morris-dnsop-dnssec-key-timing-00.txt

The draft gives a rigorous description of timing considerations in DNSSEC 
key rollovers.

Stephen

> A new version of I-D, draft-morris-dnsop-dnssec-key-timing-00.txt 
> has been successfuly submitted by Stephen Morris and posted to the 
> IETF repository.
> 
> Filename:    draft-morris-dnsop-dnssec-key-timing
> Revision:    00
> Title:       DNSSEC Key Timing Considerations
> Creation_date:    2009-02-17
> WG ID:       Independent Submission
> Number_of_pages: 22
> 
> Abstract:
> RFC 4641 gives a detailed overview of the operational considerations
> involved in running a DNSSEC-secured zone, including key rollovers.
> This document expands on the previous work, and discusses timing
> considerations in greater depth.  It explicitly identifies the
> relationships between the various time parameters, and gives a
> suggested algorithm for key rollover in a DNSSEC-secured zone.
>  
> 
> 
> The IETF Secretariat.
> 
>

---

From: Chris Thompson <[email-masked]>
Date: 17 Feb 2009 19:50:44 +0000

>The draft gives a rigorous description of timing considerations in DNSSEC 

The document seems to assume that switching from one ZSK to another for
actually signing all RRsets in a zone is an atomic operation, e.g.

|  Event 4: at some later time, the key is used to sign the zone.  This
|  point is the activation time (Ta) and after this, the key is said to
|  be in the active state.

Ought not some consideration be given to "lazy re-signing", where 
RRsets are re-signed with the now-preferred ZSK only as their previous
RRSIGs approach expiry? 

More generally, perhaps signature rollover and key rollover ought to
be covered in an integrated fashion.

-- 
Chris Thompson
Email: [email-masked]

---

From: [email-masked]
Date: Fri, 20 Feb 2009 09:34:19 +0000

> RRsets are re-signed with the now-preferred ZSK only as their previous

The idea is that it doesn't matter how the zone is signed.  At some point 
the current ZSK is rolled; prior to this time, all signatures are created 
with it.  After that time, all signatures are created with its successor. 
However, you are right in that there has been an implicit assumption of an 
atomic operation.  For the text you cite, how about:

|  Event 4: at some later time, the key starts being used for the signing 
of
|  RRsets.  This point is the activation time (Ta) and after this, the key 
is
|  said to be in the active state.

... and adjusting event 8 in the same section to read:

|  Event 8: the retired key needs to be retained in the zone whilst any 
|  RRSIG records created using this key are still published in the zone
|  or held in resolver caches.  (It is possible that a resolver could have
|  an unexpired RRSIG record and an expired DNSKEY RRset in the cache when
|  it is asked to provide both to a client.  In this case the DNSKEY
|  RRset would need to be looked up again.)  This means that once the
|  key is no longer used to sign records, it should be retained in the
|  zone for at least the retire interval (It) given by:
|
|  It = TTLsig + Dp + De
|
|  TTLsig is the TTL of the RRSIG records, Dp the propagation delay
|  (being included in the equation for the same reason as given in the
|  description of event 3) and De is the delay needed for the signer to
|  ensure that all existing RRsets have been re-signed with the new key.

> be covered in an integrated fashion.

The focus in on key timings, but if the consensus was that the draft would 
benefit from adding text on zone signing, we could extend it to cover that 
subject.

Stephen