-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMuAe6AAoJEA8yVCPsQCW5TC4IANnFEj3rMbYy0J1WcNq8Meho
DXXy/LHNUMBjYO7YxLOusMAAHJORms30EVf9xUvXH6+qXOQUrrCG0rxcBK2ECT4m
FQLMTH13nljuX0sdD5Jx9JTvnDVczwdMbahFmRuQIus9D8r4KZdQ6rTHQep+E+LR
LiwMz4jkB5t4E4GwJI+odojyUNKqPnU+9NIYgyRCw7K41Jcr11QHBfwI0QyfbSm7
cZnSyoQyLzhsatRW1Z5JNwDuc08tI0eMhkJJEY8sF/Ri2sVv5o5d5RY+et3bWUOj
Sk8c2YjY4aB4XkzZeJCTlOjmNvUxX8M2YQ9A3H6wxjJmA9zsDycPrvJhk3gqnzY=
=Hs97
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
