Subject: [DNSOP] key states in dnssec-key-timing

From: Matthijs Mekking <[email-masked]>
Date: Fri, 15 Oct 2010 09:50:19 +0200

Hi dnsop,

I have read draft-ietf-dnsop-dnssec-key-timing-00. I get the feeling
that the defined key states are used inconsistently when covering the
different rollover methods. For example, in the current text of
Pre-Publication ZSK rollover, the key state Published means that the key
is in the zone, but it is not used for signing yet. While with the
Double-RRSIG method for ZSKs, a Published key is used for signing, but
it is not in zone yet. Just the other way around. And with the
Double-Signature method for KSKs, Published means the key is used for
signing *and* it is in the zone. The meanings of other states (Active,
Retired) vary in the different rollover descriptions as well.

Perhaps a better way to express my concerns is that the key state
definitions are semantically overloaded (with the assumption of what
rollover is in use). I would like to see key states be defined in such a
way that the behavior of the key is clear, independently of what
rollover method is in place. In order to do so, I would like to propose
to replace key states with key tuples of multiple states.

First of all, key states hold semantics about:
- - the existence of the public key information (as part of the DNSKEY
  RRset);
- - the existence of the signatures created with the private key (as
  RRSIG RRs).

I think a good start for unraveling the semantics is to make separate
states for the public part and the private part of the key. For example,
the states Published and Removed typically say something about the
public key information in the zone.

For the private part, I would propose to maintain the states Generated,
Ready, Active, Retired and Dead:

Generated: The private key part has been created, but has not yet been
           used.
Ready:     The key is ready to be used for signing RRsets
Active:    The key actually has started to be used to sign RRsets
Retired:   The key has stopped to be used to sign RRsets. Previously
           created signatures may still be in the zone.
Dead:      There exist no signature information of this key anymore in
           the zone or in resolver caches.

For the public part, I would propose Generated, Ready, Published, Removed.

Generated: The public key part has been created, but has not yet been
           published.
Ready:     The key is ready to be published (as part of the DNSKEY
           RRset)
Published: The key has actually been published.
Removed:   The public key information has been removed from the zone.

Below, I show how the timelines in three different methods would change
(I would be more than happy to do the other rollovers as well).

3.2 Zone Signing Key Timelines

A ZSK is ready to authenticate RRsets if the key tuple is (Active,
Published).

3.3 Key Signing Key Timelines

For KSK rollovers, I would like to introduce a third state to the key
tuple that tracks the synchronization with the parent. The states for
that would be DS Generated, DS Ready (to submit), DS Submitted, DS
Published, DS Withdrawn, DS Removed.

A KSK is ready to authenticate the DNSKEY RRset if the key tuple is
(Active, Published, DS Published).

The difference with the ZSK Rollover is that some additional work has to
be done when the key is (Active, Published). This is in a clear way
identified by splitting up the key states into a tuple of multiple
states: The third state in the tuple distinguishes a KSK rollover from a
ZSK rollover.

What do we gain with these changes?
- - A key tuple defines more clearly what the behavior of the key should
be than the current key states.
- - No assumptions of the rollover method are needed to determine the
behavior of a key.
- - The difference between rollover a ZSK and KSK becomes more visible
because the additional work is tracked with a separate state within the
key tuple.

Any thoughts?

Best regards,

Matthijs Mekking
NLnet Labs

PS: The proposed key state changes in three different rollover methods:

3.2.1. Pre-Publication Method

        [1]  [2]      [3]  [4]    [5]      [6]  [7]      [8]  [9]
Key N    |    |<-Ipub->|    |<--------Lt-------->|<-Iret->|    |
         |    |        |    |      |        |    |        |    |
Key N+1  |    |        |    |      |<-Ipub->|    |<---------Lt--------
         |    |        |    |      |        |    |        |    |
Time N   Tgen Tpub     Trdy Tact                 Tret     Tdea Trem
Time N+1                           Tpub     Trdy Tact

[1] Key N is generated.
    State N = (Generated, Generated)

[2] Key N is published.
    State N = (Generated, Published)

[3] Key N is ready.
    State N = (Ready, Published)

[4] Key N is made active.
    State N = (Active, Published)

[5] Key N+1 must be published in time.
    State N+1 = (Generated, Published)

[6] Key N+1 becomes ready.
    State N+1 = (Ready, Published)

[7] Lifetime of Key N expired. Key N+1 is made active.
    State N = (Retired, Published)
    State N+1 = (Active, Published)

[8] Key N needs to be retained until all its RRSIGs have expire from
    caches.
    State N = (Dead, Published)

[9] Key N is removed from the zone.
    State N = (Dead, Removed)

3.2.2. Double-Signature Method

        [1]  [2]      [3]  [4]      [5]  [6]
Key N    |    |<---------Lt--------->|    |
         |    |        |    |<-Iret->|    |
Key N+1  |    |        |    |<--------Lt--------
         |    |        |    |        |    |
Time N   Tgen Tact                   Tret Trem
Time N+1                    Tact

[1] Key N is generated.
    State N = (Generated, Non-Published)

[2] Key N is made active.
    State N = (Active, Published)

[3] Key N-1 is withdrawn from the zone.
    State N-1 = (Dead, Removed)

[4] Key N+1 is made active.
    State N+1 = (Active, Published)

[5] Key N+1 has been long enough in the zone, Key N is done for.*
    State N = (Retired, Published)

    * Note that Key N does not reach the Retired state in Event 4, since
    signatures made by this key are still required in the zone.

[6] At some later time, Key N and its signatures are removed from the
    zone.
    State N = (Dead, Removed)

3.3.1. Double-Signature Method

Note that This is actually Double-Signature Rollover (like in ZSK) with
additional parent synchronization.

        [1]  [2]      [3]    [4]      [5]        [6]    [7]      [8]
DS N     |    |<-Ipub->|      |<-Dreg->|<-Idspub->|<-----------------
         |    |        |      |        |          |      |        |
DS N+1   |    |        |      |        |          |      |<-Ipub->|
         |    |        |      |        |          |      |        |
Key N    |    |<----------------------------Lt-----------------------
         |    |        |      |        |          |      |<----------
Key N+1  |    |        |      |        |          |      |<----------
         |    |        |      |        |          |      |        |
Time N   Tgen Tact     Tdsrdy Tdssub   Tdspub     Tdsact
Time N+1                                                 Tact     Tdsrdy

    ... [9]      [10]       [11]     [12]
DS N     -------->|          |        |
         |        |          |        |
DS N+1   |<-Dreg->|<-Idspub->|<--------------------------------------
         |        |          |        |
Key N    ------------------->|        |
         ------------------->|        |
Key N+1  --------------Lt--------------------------------------------
         |        |          |        |
Time N   Tdswdr   Tdsrem     Tret     Trem
Time N+1 Tdssub   Tdspub     Tdsact

 [1] Key N is generated. At the same time, we can already generate the
     DS.
     State N = (Generated, Non-Published, DS Generated)

 [2] Key N is made active.
     State N = (Active, Published, DS Generated)

 [3] DS N ready to submit.
     State N = (Active, Published, DS Ready)

 [4] DS N is submitted. DS N-1 is withdrawn.
     State N-1 = (Active, Published, DS Withdrawn)
     State N = (Active, Published, DS Submitted)
 [5] DS N is published. DS N-1 is removed.
     State N = (Active, Published, DS Published)
     State N-1 = (Active, Published, DS Removed)

 [6] DS N-1 has expired from caches. Key N-1 can be removed.
     State N-1 = (Dead, Removed, DS Removed)

 [7] Key N+1 made active.
     State N+1 = (Active, Published, DS Generated)

 [8] DS N+1 ready to submit.
     State N+1= (Active, Published, DS Ready)

 [9] DS N+1 is submitted. DS N is withdrawn.
     State N = (Active, Published, DS Withdrawn)
     State N+1 = (Active, Published, DS Submitted)

[10] DS N+1 is published. DS N is removed.
     State N = (Active, Published, DS Removed)
     State N+1 = (Active, Published, DS Published)

[13] Key N and corresponding singatures are removed.
     State N = (Dead, Removed, DS Removed)