Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-key-timing-03.txt

From: [email-masked]
Date: Mon, 09 Jul 2012 09:29:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title           : DNSSEC Key Timing Considerations
	Author(s)       : Stephen Morris
                          Johan Ihren
                          John Dickinson
	Filename        : draft-ietf-dnsop-dnssec-key-timing-03.txt
	Pages           : 33
	Date            : 2012-07-09

Abstract:
   This document describes the issues surrounding the timing of events
   in the rolling of a key in a DNSSEC-secured zone.  It presents
   timelines for the key rollover and explicitly identifies the
   relationships between the various parameters affecting the process.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-key-timing-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Morris <[email-masked]>
Date: Mon, 9 Jul 2012 18:13:09 +0100

After much delay, the -03 version of the key timing draft has been
submitted.  It incorporates a number of comments made on-list and
privately: many thanks to Mark Lampo, Matthijs Mekking and Alfred
Hoenes.

Perhaps the most significant change concerns the timing considerations
related to the introduction of a new KSK (section 3.3.4.1).

Stephen

On 9 Jul 2012, at 17:29, [email-masked] wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 24 Jul 2012 13:53:16 +0200

Hi,

Stephen asked me to send this suggestion we had (surfaced from
discussions) to the list. We would like to have input before the
upcoming IETF meeting.

Modification to the key states
==============================

As you might know, I had this idea of unraveling key states. Instead
of having states that describe the overall state of the key, we would
have states for components of the key. How to divide the key into
components is based on the parts that can be published:

- - DNSKEY
- - DS
- - RRSIG
- - RRSIG DNSKEY

We can call this the representation of the key (which components are
visible in the zone and/or caches). The RRSIG for zone contents and
for the DNSKEY RRset need specifically be split to support a Single
Type Singing Key in a later stadium.

Each component follows a certain publication path. Initially it is
Hidden, it will be Introduced into the zone, it is long enough in the
zone to be Propagated to all caches, it will be Withdrawn from the
zone and it will become Hidden again (as it has expired from caches):

    Hidden --> Introduced --> Propagated --> Withdrawn --> Hidden.

(Note: a component could be removed from the zone before it was
propagated, so a transition between Introduced and Withdrawn. The
other way around is also true: A record can be reintroduced before it
had expired from all the caches. The idea is to consider full
rollovers only, so these transitions will be out of scope.)

The overall key states from draft-ietf-dnsop-dnssec-key-timing-03.txt
map (but not one-to-one) to the unraveled key states:

For example, for ZSK Rollovers:

Generated -> (DNSKEY Hidden, RRSIG Hidden)
Published -> (DNSKEY Published, RRSIG Hidden) [Pre-publish]
          -> (DNSKEY Hidden, RRSIG Published)  [Double-RRSIG]
Ready     -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish]
          -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG]
Active    -> (DNSKEY Propagated, RRSIG Introduced) [Pre-publish]
          -> (DNSKEY Introduced, RRSIG Propagated) [Double-RRSIG]
          -> (DNSKEY Introduced, RRSIG Introduced) [Double-Signature]
Retired   -> (DNSKEY Propagated, RRSIG Withdrawn) [Pre-publish]
          -> (DNSKEY Withdrawn, RRSIG Propagated)  [Double-RRSIG]
          -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature]
Dead      -> (DNSKEY Propagated, RRSIG Hidden) [Pre-publish]
          -> (DNSKEY Hidden, RRSIG Propagated) [Double-RRSIG]
          -> (DNSKEY Propagated, RRSIG Propagated) [Double-Signature]
Removed   -> (DNSKEY Withdrawn, RRSIG Hidden) [Pre-Publish]
          -> (DNSKEY Hidden, RRSIG Withdrawn) [Double-RRSIG]
          -> (DNSKEY Withdrawn, RRSIG Withdrawn) [Double-Signature]

(I leave the KSK rollovers as an exercise to the reader ;-) )

So you see, the key states as they are now do not map uniquely to how
the key is presented in the zone. I want to propose that either the
document uses the unraveled key states, or otherwise defines a unique
mapping between the overall key states and the representation of the key.

Also, we should not limit to one key state at a time. For example, a
key can be Published and Active at the same time in my opinion.

- From -03:

Published      The DNSKEY record - or information associated with it -
               is published in the zone, but predecessors of the key (or
               associated information) may be held in caches.

Active         The key has started to be used to sign RRsets.  Note that
               when this state is entered, it may not be possible for
               validating resolvers to use the key for validation in all
               cases: the zone signing may not have finished, or the
               data might not have reached the resolver because of
               propagation delays and/or caching issues.  If this is the
               case, the resolver will have to rely on the key's
               predecessor instead.

But both descriptions may be valid at the same point in time. So I
would like to say the key can be Published and Active at the same time.

Finally, I would like to drop "associated information". To keep a
clear definition, a key state should only say something about one key
component. So, the definition for Published would become:

Published      The DNSKEY record is published in the zone, but
               predecessors of the key (or associated information) may
               be held in caches.

or even more simpler:

Published      The DNSKEY record is published in the zone.

So, you would get more states, but with simpler descriptions.

To summarize:

1. Use unraveled key states or define a unique mapping between the
overall key states and the representation of the key.

2. A key can have more than one state at a time.

3. Drop "associated information", a key state only says something
about one key component.

Thoughts?

Best regards,
  Matthijs

On 07/09/2012 07:13 PM, Stephen Morris wrote:
> Perhaps the most significant change concerns the timing
> considerations related to the introduction of a new KSK (section
> 3.3.4.1).
> 
> Stephen
> 
> 
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories. This draft is a work item of the
>> Domain Name System Operations Working Group of the IETF.
>> 
>> Title           : DNSSEC Key Timing Considerations Author(s)
>> : Stephen Morris Johan Ihren John Dickinson Filename        :
>> draft-ietf-dnsop-dnssec-key-timing-03.txt Pages           : 33 
>> Date            : 2012-07-09
>> 
>> Abstract: This document describes the issues surrounding the
>> timing of events in the rolling of a key in a DNSSEC-secured
>> zone.  It presents timelines for the key rollover and explicitly
>> identifies the relationships between the various parameters
>> affecting the process.
>> 
>> 
Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________ DNSOP mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Jul 2012 09:59:36 -0400 (EDT)

> 2. A key can have more than one state at a time.

I would not be in favour or using "states" where there is no clear
distinction between the key states. Looking at implementors of key
management software using state machines, we really should help them by
using solid state definitions that do not overlap.

So "Published" would need to include "not used for signing" so it
can never overlap with "Active".

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 24 Jul 2012 11:11:46 -0400

> components is based on the parts that can be published:

I am a big fan of this line of thinking.

I saw you (in Vienna, I think) reduce this logic to a small set of equations which, if all are satisfied, indicates that a particular change for one component is safe (from the perspective of validators), and I think this would be a vast improvement for implementers and operators over the sometimes complicated reasoning that is otherwise involved in planning a rollover event. This model makes arbitrary key rollovers trivial to plan with confidence.

While dnsop-dnssec-key-timing provides a fairly thorough background which promotes understanding of the underlying issues, it's still a thorny document to apply to an actual operational event.

I think it would be great if we could present your model (or something similarly robust and simple) in such a way that it becomes the normal way of thinking about rollover events, both for implementers of DNSSEC signing platforms and for operators of DNSSEC-signed zones. The world would be a better place.

Joe

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 Jul 2012 09:45:23 +0200

On 07/24/2012 03:59 PM, Paul Wouters wrote:
>> But both descriptions may be valid at the same point in time. So
>> I would like to say the key can be Published and Active at the
>> same time.
> 
> management software using state machines, we really should help
> them by using solid state definitions that do not overlap.

The whole idea of the proposed suggestion is to make the distinction
in key states more clear.

The reason for the overlap to occur is that key *components* have a
state and these states use a solid definition. Published says
something about the DNSKEY record. Active says something about the
RRSIG records.

> can never overlap with "Active".

But there are (obvious) situations that a Published key is used for
signing, e.g. the key is Active. That doesn't matter, as long as the
states for one key component do not overlap.

Matthijs

> 
> Paul _______________________________________________ DNSOP mailing

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 25 Jul 2012 09:53:01 +0200

On 07/24/2012 05:11 PM, Joe Abley wrote:
>> As you might know, I had this idea of unraveling key states. 
>> Instead of having states that describe the overall state of the 
>> key, we would have states for components of the key. How to
>> divide the key into components is based on the parts that can be 
>> published:
> 
> I saw you (in Vienna, I think) reduce this logic to a small set of 
> equations which, if all are satisfied, indicates that a particular 
> change for one component is safe (from the perspective of 
> validators), and I think this would be a vast improvement for 
> implementers and operators over the sometimes complicated
> reasoning that is otherwise involved in planning a rollover event.
> This model makes arbitrary key rollovers trivial to plan with
> confidence.

You are confusing me for my colleague Yuri, but we think alike. Yuri
build the logic on top of the idea of unraveled key states. The logic
is based on the timings described in
draft-ietf-dnsop-dnssec-key-timing and
draft-mekking-dnsop-dnssec-key-timing-bis-02.txt.

For more information on the logic, see our paper:

http://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf

> 
> While dnsop-dnssec-key-timing provides a fairly thorough
> background which promotes understanding of the underlying issues,
> it's still a thorny document to apply to an actual operational
> event.
> 
> I think it would be great if we could present your model (or 
> something similarly robust and simple) in such a way that it
> becomes the normal way of thinking about rollover events, both for 
> implementers of DNSSEC signing platforms and for operators of 
> DNSSEC-signed zones. The world would be a better place.

Thanks.

Matthijs

---

From: Miek Gieben <[email-masked]>
Date: Wed, 25 Jul 2012 09:55:11 +0200

[ Quoting <[email-masked]> in "Re: [DNSOP] I-D Action: draft-ietf-..." ]
> > DNSSEC-signed zones. The world would be a better place.

I like this idea too. But does this mean 4641bis is overly complex wrt
to key rollovers?

grtz Miek