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

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 01 Aug 2012 18:51:08 -0400

On 24/07/2012 07:53, Matthijs Mekking wrote:

General comment: this is an improvement.
some comments and suggestions below

The "state" of the key frequently depends on the viewpoint, for example
zone may have key in active state but due to propagation delay some 
validators may think the key is Published state.
During transition there different "participants" are in different
states. (I will ignore the case that a validator may have RRsets from
different versions of a zone and thus for RRset A and RRset B the
key states may be different).

The goal of the document is to document this and tell people how long it 
takes until all "participants" consider the key to be in the same state.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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

Is this "RRSIG" in zone generated by the key  ?

> - - RRSIG DNSKEY

Why is this needed ?
Key has either RRSIG or not there, the role of the KEY dictates what it
signs.

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

(this is
I think we should include paths for Revoked keys (RFC5011)

H --> I --> P --> W --> H
       |     |           ^
       V     V           |
       + --> + --------> R

Or the three different paths:
H --> I --> P --> W --> H
H --> I --> R -->       H
H --> I --> P --> R --> H

>
> (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]
>

An alternative way to present this to include the delay until next state 
can be entered.
Below I have rewritten part of the representation above to include
the precondition for entering the next state
- Delay: how long to wait for the data to propagate
- Action needed be taken to move to the next state.

               DNSKEY   ---  RRSIG   ---- Delay/Action - APPROACH
Published --> Introduced -  Hidden     - DNSKEY TTL  = [Pre-Publish]
           --> Hidden     -  Introduced - MAX TTL     = [Double-RRSIG]

Ready     --> Propagated -  Hidden     - Action X    = [Pre-Publish]
           --> Hidden     -  Propagated - Action Y    = [Double-RRSIG]

Action X = Sign zone with key
Action Y = replace the old key with the new one.

Rather than have a table like this I would prefer to have the
state machine for each approach.

> (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?
>

I like this and think the document should adopt this notation as it is 
much easier to express and understand.

	Olafur

> Best regards,
>    Matthijs
>
>
> On 07/09/2012 07:13 PM, Stephen Morris wrote:
>> 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
>>
>>

---

From: Yuri Schaeffer <[email-masked]>
Date: Tue, 14 Aug 2012 10:54:35 +0200

I reviewed the "DNSSEC Key Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-03.txt" document rather extensively
with emphasis on verifying correctness of the rollover timelines. I
believe these are correct.

A remark:

4. Standby Keys, paragraph 6: "Finally, in the Double-DS method of
rolling a KSK, it is not a standby key that is present, it is a standby
DS record in the parent zone."

Saying this does not count as a 'standby key' is confusing in the
light that the term key is used rather loosely. Also this text
insinuates that it is somehow worse than having a "Double-Signature
standby key" but fails to mention why.

Another remark. I guess this is not up for debate at this point but it
really bothers me:

2.3: Table 1. I don't like the names at all. It is confusing and
inconsistent. KSK Double-Signature would in my opinion be better of
called Double-DNSKEY. ZSK Double-Signature means: "do everything at
once" whilst KSK Double-Signature means "do it staged". Similar to make
it make consistent I would either cal ZSK Pre-Publication Double-DNSKEY
or KSK Double-DS Pre-Publication. Perhaps:

+------------------+------------------+-----------------------------+
| ZSK Method       | KSK Method       | Description                 |
+------------------+------------------+-----------------------------+
| Double-DNSKEY    | -                | Publish the DNSKEY before   |
|                  |                  | the RRSIGs.                 |
| Double-RRSIG     | -                | Publish RRSIGs before the   |
|                  |                  | DNSKEY.                     |
| Double-ZSK       | -                | Publish the DNSKEY and      |
|                  |                  | RRSIGs at same time.        |
| -                | Double-DNSKEY    | Publish the DNSKEY before   |
|                  |                  | The DS.                     |
| -                | Double-DS        | Publish DS before the       |
|                  |                  | DNSKEY.                     |
| -                | Double-KSK       | Publish DNSKEY and DS in    |
|                  |                  | parallel.                   |
+------------------+------------------+-----------------------------+

Regards,
Yuri Schaeffer

---

From: John Dickinson <[email-masked]>
Date: Mon, 20 Aug 2012 12:50:55 +0100

Yuri,

Thanks for the feedback.

> standby key" but fails to mention why.

I am reluctant to make changes to the wording at this stage. However, if the WG feel strongly enough then I suggest that we could either remove the words "it is not a standby key that is present," or change the wording to say "the standby key is not published in the zone, rather it is the DS RR derived from the standby key that is published in the parent zone.".

I do not see how the wording insinuates that it is somehow worse than having a "Double-Signature standby key".

> or KSK Double-DS Pre-Publication. Perhaps:

Yes, I guess this table could be clarified, but again I am reluctant to make changes to the naming at this stage, especially as this would require changing the names throughout the document. We could rearrange the table to tidy up the description of the Double-Signature method but keep the existing names. Would that help?

regards
John

---
[email-masked]

http://sinodun.com

Sinodun Internet Technologies Ltd.
Stables 4, Suite 11,
Howbery Park,
Wallingford,
Oxfordshire,
OX10 8BA,
U.K.

+44 (0)1491 834957

---

From: Peter Koch <[email-masked]>
Date: Mon, 20 Aug 2012 14:46:09 +0200

John, all,

On Mon, Aug 20, 2012 at 12:50:55PM +0100, John Dickinson wrote:

> I am reluctant to make changes to the wording at this stage.

with co-chair and shepherd hat on I must say there is no 'stage' of the document
that would discourage or prevent clarifications if members of the WG feel the need.

Personally (i.e., no hats) I must say I am not sure I understand what message
this paragraph is trying to convey:  if it is that the key cannot be used right away
because it needs to become active first, then maybe that could or should be made more
explicit.

> Yes, I guess this table could be clarified, but again I am reluctant to make changes to the naming at this stage, especially as this would require changing the names throughout the document. We cou…

And again (hat++), the stage is not a reason to refuse change, especially given that
this has not been discussed before as far as I remember.  However, this is a WG
document and apart from editorial changes and obvious errors, (significant) changes
do need WG consensus - and i have seen no support so far.

What we need to keep in mind here, though, is internal document consistency as
well as consistency with other WG documents, nost notably RFC 4641 and 4641bis
as well as established operational convention (as opposed to, just for completeness
sake, sloppy language or marketing blurb).

-Peter

---

From: Yuri Schaeffer <[email-masked]>
Date: Mon, 20 Aug 2012 15:03:41 +0200

On 08/20/2012 01:50 PM, John Dickinson wrote:
> We could rearrange the table to tidy up the description of the 
> Double-Signature method but keep the existing names. Would that 
> help?

Yes, making a clearer distinction between ZSK Double-Signature and KSK
Double-Signature would help a bit.

//yuri