draft-ietf-dnsop-dnssec-key-timing-02.txt   draft-ietf-dnsop-dnssec-key-timing-03.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force S. Morris
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational J. Ihren Intended status: Informational J. Ihren
Expires: September 11, 2011 Netnod Expires: January 10, 2013 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
March 10, 2011 July 9, 2012
DNSSEC Key Timing Considerations DNSSEC Key Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-02.txt draft-ietf-dnsop-dnssec-key-timing-03.txt
Abstract Abstract
This document describes the issues surrounding the timing of events This document describes the issues surrounding the timing of events
in the rolling of a key in a DNSSEC-secured zone. It presents in the rolling of a key in a DNSSEC-secured zone. It presents
timelines for the key rollover and explicitly identifies the timelines for the key rollover and explicitly identifies the
relationships between the various parameters affecting the process. relationships between the various parameters affecting the process.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2011. This Internet-Draft will expire on January 10, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3
1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8
3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9
3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12
3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15
3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 15 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 16
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21
3.3.4. Interaction with Configured Trust Anchors . . . . . . 23 3.3.4. Interaction with Configured Trust Anchors . . . . . . 23
3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 23 3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 24
3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 24 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 24 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 26
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 25
6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. Change History (To be removed on publication) . . . . . . . . 27 11. Normative References . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 Appendix B. Change History (To be removed on publication) . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
1.1. Key Rolling Considerations 1.1. Key Rolling Considerations
When a zone is secured with DNSSEC, the zone manager must be prepared When a zone is secured with DNSSEC, the zone manager must be prepared
to replace ("roll") the keys used in the signing process. The to replace ("roll") the keys used in the signing process. The
rolling of keys may be caused by compromise of one or more of the rolling of keys may be caused by compromise of one or more of the
existing keys, or it may be due to a management policy that demands existing keys, or it may be due to a management policy that demands
periodic key replacement for security or operational reasons. In periodic key replacement for security or operational reasons. In
order to implement a key rollover, the keys need to be introduced order to implement a key rollover, the keys need to be introduced
into and removed from the zone at the appropriate times. into and removed from the zone at the appropriate times.
Considerations that must be taken into account are: Considerations that must be taken into account are:
o DNSKEY records and associated information (such as the associated o DNSKEY records and associated information (such as the associated
DS records or RRSIG records created with the key) are not only DS records or RRSIG records created with the key) are not only
held at the authoritative nameserver, they are also cached by held at the authoritative nameserver, they are also cached by
resolvers. The data on these systems can be interlinked, e.g. a resolvers. The data on these systems can be interlinked, e.g., a
validating resolver may try to validate a signature retrieved from validating resolver may try to validate a signature retrieved from
a cache with a key obtained separately. a cache with a key obtained separately.
o Zone "boot-strapping" events, where a zone is signed for the first o Zone "boot-strapping" events, where a zone is signed for the first
time, can be common in configurations where a large number of time, can be common in configurations where a large number of
zones are being served. Procedures should be able to cope with zones are being served. Procedures should be able to cope with
the introduction of keys into the zone for the first time as well the introduction of keys into the zone for the first time as well
as "steady-state", where the records are being replaced as part of as "steady-state", where the records are being replaced as part of
normal zone maintenance. normal zone maintenance.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
(additional keys over and above those used to sign the zone) need (additional keys over and above those used to sign the zone) need
to be present. to be present.
o A query for the DNSKEY RRset returns all DNSKEY records in the o A query for the DNSKEY RRset returns all DNSKEY records in the
zone. As there is limited space in the UDP packet (even with zone. As there is limited space in the UDP packet (even with
EDNS0 support), key records no longer needed must be periodically EDNS0 support), key records no longer needed must be periodically
removed. (For the same reason, the number of standby keys in the removed. (For the same reason, the number of standby keys in the
zone should be restricted to the minimum required to support the zone should be restricted to the minimum required to support the
key management policy.) key management policy.)
Management policy, e.g. how long a key is used for, also needs to be Management policy, e.g., how long a key is used for, also needs to be
considered. However, the point of key management logic is not to considered. However, the point of key management logic is not to
ensure that a rollover is completed at a certain time but rather to ensure that a rollover is completed at a certain time but rather to
ensure that no changes are made to the state of keys published in the ensure that no changes are made to the state of keys published in the
zone until it is "safe" to do so ("safe" in this context meaning that zone until it is "safe" to do so ("safe" in this context meaning that
at no time during the rollover process does any part of the zone ever at no time during the rollover process does any part of the zone ever
go bogus). In other words, although key management logic enforces go bogus). In other words, although key management logic enforces
policy, it may not enforce it strictly. policy, it may not enforce it strictly.
A high-level overview of key rollover can be found in
[I-D.ietf-dnsop-rfc4641bis]. In contrast, this document focuses on
the low-level timing detail of two classes of operations described
there, the rollover of key-signing keys, and the rollover of zone
signing keys.
1.2. Types of Keys 1.2. Types of Keys
Although DNSSEC validation treats all keys equally, [RFC4033] Although DNSSEC validation treats all keys equally, [RFC4033]
recognises the broad classification of zone-signing keys (ZSK) and recognises the broad classification of zone-signing keys (ZSK) and
key-signing keys (KSK). A ZSK is used to authenticate information key-signing keys (KSK). A ZSK is used to authenticate information
within the zone; a KSK is used to authenticate the zone's DNSKEY within the zone; a KSK is used to authenticate the zone's DNSKEY
RRset. The main implication for this distinction concerns the RRset. The main implication for this distinction concerns the
consistency of information during a rollover. consistency of information during a rollover.
During operation, a validating resolver must use separate pieces of During operation, a validating resolver must use separate pieces of
skipping to change at page 5, line 5 skipping to change at page 5, line 11
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Rollover Methods 2. Rollover Methods
2.1. ZSK Rollovers 2.1. ZSK Rollovers
A ZSK can be rolled in one of three ways: A ZSK can be rolled in one of three ways:
o Pre-Publication: described in [RFC4641], the new key is introduced o Pre-Publication: described in [I-D.ietf-dnsop-rfc4641bis], the new
into the DNSKEY RRset which is then re-signed. This state of key is introduced into the DNSKEY RRset which is then re-signed.
affairs remains in place for long enough to ensure that any cached This state of affairs remains in place for long enough to ensure
DNSKEY RRsets contain both keys. At that point signatures created that any cached DNSKEY RRsets contain both keys. At that point
with the old key can be replaced by those created with the new signatures created with the old key can be replaced by those
key, and the old signatures removed. During the re-signing created with the new key, and the old signatures removed. During
process (which may or may not be atomic depending on how the zone the re-signing process (which may or may not be atomic depending
is managed), it doesn't matter which key an RRSIG record retrieved on how the zone is managed), it doesn't matter which key an RRSIG
by a resolver was created with; cached copies of the DNSKEY RRset record retrieved by a resolver was created with; cached copies of
will contain both the old and new keys. the DNSKEY RRset will contain both the old and new keys.
Once the zone contains only signatures created with the new key, Once the zone contains only signatures created with the new key,
there is an interval during which RRSIG records created with the there is an interval during which RRSIG records created with the
old key expire from caches. After this, there will be no old key expire from caches. After this, there will be no
signatures anywhere that were created using the old key, and it signatures anywhere that were created using the old key, and it
can can be removed from the DNSKEY RRset. can can be removed from the DNSKEY RRset.
o Double-Signature: also mentioned in [RFC4641], this involves o Double-Signature: also mentioned in [I-D.ietf-dnsop-rfc4641bis],
introducing the new key into the zone and using it to create this involves introducing the new key into the zone and using it
additional RRSIG records; the old key and existing RRSIG records to create additional RRSIG records; the old key and existing RRSIG
are retained. During the period in which the zone is being signed records are retained. During the period in which the zone is
(again, the signing process may not be atomic), validating being signed (again, the signing process may not be atomic),
resolvers are always able to validate RRSIGs: any combination of validating resolvers are always able to validate RRSIGs: any
old and new DNSKEY RRset and RRSIG allows at least one signature combination of old and new DNSKEY RRset and RRSIG allows at least
to be validated. one signature to be validated.
Once the signing process is complete and enough time has elapsed Once the signing process is complete and enough time has elapsed
to allow all old information to expire from caches, the old key to allow all old information to expire from caches, the old key
and signatures can be removed from the zone. As before, during and signatures can be removed from the zone. As before, during
this period any combination of DNSKEY RRset and RRSIG will allow this period any combination of DNSKEY RRset and RRSIG will allow
validation of at least one signature. validation of at least one signature.
o Double-RRSIG: strictly speaking, the use of the term "Double- o Double-RRSIG: strictly speaking, the use of the term "Double-
Signature" above is a misnomer as the method is not only double Signature" above is a misnomer as the method is not only double
signature, it is also double key as well. A true Double-Signature signature, it is also double key as well. A true Double-Signature
skipping to change at page 6, line 14 skipping to change at page 6, line 20
complex - introduce the new key, approximately one TTL later sign the complex - introduce the new key, approximately one TTL later sign the
records, and approximately one TTL after that remove the old key. records, and approximately one TTL after that remove the old key.
Double-RRSIG is essentially the reverse of Pre-Publication - Double-RRSIG is essentially the reverse of Pre-Publication -
introduce the new signatures, approximately one TTL later change the introduce the new signatures, approximately one TTL later change the
key, and approximately one TTL after that remove the old signatures. key, and approximately one TTL after that remove the old signatures.
2.2. KSK Rollovers 2.2. KSK Rollovers
For ZSKs, the issue for the validating resolver is to ensure that it For ZSKs, the issue for the validating resolver is to ensure that it
has access to the ZSK that corresponds to a particular signature. In has access to the ZSK that corresponds to a particular signature. In
the KSK case this can never be a problem as the KSK is only used for the KSK case, this can never be a problem as the KSK is only used for
one signature (that over the DNSKEY RRset) and both the key the one signature (that over the DNSKEY RRset) and both the key and the
signature travel together. Instead, the issue is to ensure that the signature travel together. Instead, the issue is to ensure that the
KSK is trusted. KSK is trusted.
Trust in the KSK is either due to the existence of a DS record in the Trust in the KSK is either due to the existence of a signed and
parent zone (which is itself trusted) or an explicitly configured validated DS record in the parent zone or an explicitly configured
trust anchor. If the former, the rollover algorithm will need to trust anchor. If the former, the rollover algorithm will need to
involve the parent zone in the addition and removal of DS records, so involve the parent zone in the addition and removal of DS records, so
timings are not wholly under the control of the zone manager. If the timings are not wholly under the control of the zone manager. If the
latter, [RFC5011] timings will be needed to roll the keys. (Even in latter, [RFC5011] timings will be needed to roll the keys. (Even in
the case where authentication is via a DS record, the zone manager the case where authentication is via a DS record, the zone manager
may elect to include [RFC5011] timings in the key rolling process so may elect to include [RFC5011] timings in the key rolling process so
as to cope with the possibility that the key has also been explicitly as to cope with the possibility that the key has also been explicitly
configured as a trust anchor.) configured as a trust anchor.)
It is important to note that this does not preclude the development It is important to note that this does not preclude the development
skipping to change at page 7, line 30 skipping to change at page 7, line 35
parallel. parallel.
2.3. Summary 2.3. Summary
The methods can be summarised as follows: The methods can be summarised as follows:
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
| ZSK Method | KSK Method | Description | | ZSK Method | KSK Method | Description |
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
| Pre-Publication | (not applicable) | Publish the DNSKEY before | | Pre-Publication | (not applicable) | Publish the DNSKEY before |
| | | the RRSIG. | | | | the RRSIGs. |
| Double-Signature | Double-Signature | Publish the DNSKEY and | | Double-Signature | Double-Signature | Publish the DNSKEY and |
| | | RRSIG at same time. (For a | | | | RRSIGs at same time. For a |
| | | KSK, this happens before | | | | KSK, this happens before |
| | | the DS is published.) | | | | the DS is published. |
| Double-RRSIG | (not applicable) | Publish RRSIG before the | | Double-RRSIG | (not applicable) | Publish RRSIGs before the |
| | | DNSKEY. | | | | DNSKEY. |
| (not applicable) | Double-DS | Publish DS before the | | (not applicable) | Double-DS | Publish DS before the |
| | | DNSKEY. | | | | DNSKEY. |
| (not applicable) | Double-RRset | Publish DNSKEY and DS in | | (not applicable) | Double-RRset | Publish DNSKEY and DS in |
| | | parallel. | | | | parallel. |
+------------------+------------------+-----------------------------+ +------------------+------------------+-----------------------------+
Table 1 Table 1
3. Key Rollover Timelines 3. Key Rollover Timelines
skipping to change at page 8, line 21 skipping to change at page 8, line 28
The idea of "associated information" is used in rollover The idea of "associated information" is used in rollover
methods where RRSIG or DS records are published first and methods where RRSIG or DS records are published first and
the DNSKEY is changed in an atomic operation. It allows the DNSKEY is changed in an atomic operation. It allows
the rollover still to be thought of as moving through a the rollover still to be thought of as moving through a
set of states. In the rest of this section, the term set of states. In the rest of this section, the term
"key data" should be taken to mean "key or associated "key data" should be taken to mean "key or associated
information". information".
Ready The new key data has been published for long enough to Ready The new key data has been published for long enough to
guarantee that any previous versions of it have expired guarantee that any previous versions of the DNSKEY RRset
from caches. have expired from caches.
Active The key has started to be used to sign RRsets. Note that Active The key has started to be used to sign RRsets. Note that
when this state is entered, it may not be possible for when this state is entered, it may not be possible for
validating resolvers to use the key for validation in all validating resolvers to use the key for validation in all
cases: the zone signing may not have finished, or the cases: the zone signing may not have finished, or the
data might not have reached the resolver because of data might not have reached the resolver because of
propagation delays and/or caching issues. If this is the propagation delays and/or caching issues. If this is the
case, the resolver will have to rely on the key's case, the resolver will have to rely on the key's
predecessor instead. predecessor instead.
Retired The key is in the zone but a successor key has become Retired A successor key has become active and this key is no
active. As there may still be information in caches that longer being used to generate RRSIGs. However, as there
that require use of the key, it is being retained until may still be RRSIGs in caches that were generated using
this information expires. this key, it is being retained in the zone until they
have expired.
Dead The key is published in the zone but there is no longer Dead The key is published in the zone but there is no longer
information anywhere that requires its presence. Hence information anywhere that requires its presence. Hence
the key can be removed from the zone at any time. the key can be removed from the zone at any time.
Removed The key has been removed from the zone. Removed The key has been removed from the zone.
There is one additional state, used where [RFC5011] considerations There is one additional state, used where [RFC5011] considerations
are in effect (see Section 3.3.4): are in effect (see Section 3.3.4):
skipping to change at page 9, line 30 skipping to change at page 9, line 40
Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->| Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
| | | | | | | | | | | | | | | | | |
Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - - Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - -
| | | | | | | | | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS Tret Tdea Trem Tgen Tpub Trdy Tact TpubS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK rollover. Figure 1: Timeline for a Pre-Publication ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: key N's DNSKEY record is put into the zone, i.e. it is added Event 2: Key N's DNSKEY record is put into the zone, i.e., it is
to the DNSKEY RRset which is then re-signed with the current key- added to the DNSKEY RRset which is then re-signed with the current
signing key. The time at which this occurs is the key's publication key-signing key. The time at which this occurs is the key's
time (Tpub), and the key is now said to be published. Note that the publication time (Tpub), and the key is now said to be published.
key is not yet used to sign records. Note that the key is not yet used to sign records.
Event 3: before it can be used, the key must be published for long Event 3: Before it can be used, the key must be published for long
enough to guarantee that any cached version of the zone's DNSKEY enough to guarantee that any cached version of the zone's DNSKEY
RRset includes this key. RRset includes this key.
This interval is the publication interval (Ipub) and, for the second This interval is the publication interval (Ipub) and, for the second
or subsequent keys in the zone, is given by: or subsequent keys in the zone, is given by:
Ipub = Dprp + TTLkey Ipub = Dprp + TTLkey
Here, Dprp is the propagation delay - the time taken in the worst- Here, Dprp is the propagation delay - the time taken in the worst-
case situation for a change introduced at the master to replicate to case situation for a change introduced at the master to replicate to
skipping to change at page 10, line 24 skipping to change at page 10, line 33
(The case of introducing the first ZSK into the zone is discussed in (The case of introducing the first ZSK into the zone is discussed in
Section 3.3.5.) Section 3.3.5.)
After a delay of Ipub, the key is said to be ready and could be used After a delay of Ipub, the key is said to be ready and could be used
to sign records. The time at which this event occurs is the key's to sign records. The time at which this event occurs is the key's
ready time (Trdy), which is given by: ready time (Trdy), which is given by:
Trdy = Tpub + Ipub Trdy = Tpub + Ipub
Event 4: at some later time, the key starts being used to sign Event 4: At some later time, the key starts being used to sign
RRsets. This point is the activation time (Tact) and after this, the RRsets. This point is the activation time (Tact) and after this, the
key is said to be active. key is said to be active.
Event 5: at some point thought must be given to its successor (key Event 5: At some point thought must be given to its successor (key
N+1). As with the introduction of the currently active key into the N+1). As with the introduction of the currently active key into the
zone, the successor key will need to be published at least Ipub zone, the successor key will need to be published at least Ipub
before it is activated. Denoting the publication time of the before it is activated. Denoting the publication time of the
successor key by TpubS, then: successor key by TpubS, then:
TpubS <= Tact + Lzsk - Ipub TpubS <= Tact + Lzsk - Ipub
Here, Lzsk is the length of time for which a ZSK will be used (the Here, Lzsk is the length of time for which a ZSK will be used (the
ZSK lifetime). It should be noted that unlike the publication ZSK lifetime). It should be noted that unlike the publication
interval, Lzsk is not determined by timing logic, but by key interval, Lzsk is not determined by timing logic, but by key
management policy. Lzsk will be set by the operator according to management policy. Lzsk will be set by the operator according to
their assessment of the risks posed by continuing to use a key and their assessment of the risks posed by continuing to use a key and
the risks associated with key rollover. However, operational the risks associated with key rollover. However, operational
considerations may mean a key is active for slightly more or less considerations may mean a key is active for slightly more or less
than Lzsk. than Lzsk.
Event 6: while key N is still active, its successor becomes ready. Event 6: While key N is still active, its successor becomes ready.
From this time onwards, key N+1 could be used to sign the zone. From this time onwards, key N+1 could be used to sign the zone.
Event 7: When key N has been in use for an interval equal to the the Event 7: When key N has been in use for an interval equal to the ZSK
ZSK lifetime, it is retired (i.e. it will never again be used to lifetime, it is retired (i.e., it will never again be used to
generate new signatures) and key N+1 activated and used to sign the generate new signatures) and key N+1 activated and used to sign the
zone. This is the retire time of key N (Tret) and is given by: zone. This is the retire time of key N (Tret) and is given by:
Tret = Tact + Lzsk Tret = Tact + Lzsk
It is also the activation time of the successor key (TactS). Note It is also the activation time of the successor key (TactS). Note
that operational considerations may cause key N to remain in use for that operational considerations may cause key N to remain in use for
longer than Lzsk; if so, the retirement actually occurs when the longer than Lzsk; if so, the retirement actually occurs when the
successor key is made active. successor key is made active.
Event 8: the retired key needs to be retained in the zone whilst any 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 RRSIG records created using this key are still published in the zone
or held in caches. (It is possible that a validating resolver could or held in caches. (It is possible that a validating resolver could
have an unexpired RRSIG record and an expired DNSKEY RRset in the 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 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 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 key is no longer used to sign records, it should be retained in
the zone for at least the retire interval (Iret) given by: the zone for at least the retire interval (Iret) given by:
Iret = Dsgn + Dprp + TTLsig Iret = Dsgn + Dprp + TTLsig
Dsgn is the delay needed to ensure that all existing RRsets have been Dsgn is the delay needed to ensure that all existing RRsets have been
re-signed with the new key. Dprp is (as described above) the re-signed with the new key. Dprp is (as described above) the
propagation delay, required to guarantee that the updated zone propagation delay, required to guarantee that the updated zone
information has reached all slave servers, and TTLsig is the maximum information has reached all slave servers, and TTLsig is the maximum
TTL of all the RRSIG records in the zone. TTL of all the RRSIG records in the zone created with the ZSK.
The time at which all RRSIG records created with this key have The time at which all RRSIG records created with this key have
expired from resolver caches is the dead time (Tdea), given by: expired from resolver caches is the dead time (Tdea), given by:
Tdea = Tret + Iret Tdea = Tret + Iret
...at which point the key is said to be dead. ... at which point the key is said to be dead.
Event 9: at any time after the key becomes dead, it can be removed Event 9: At any time after the key becomes dead, it can be removed
from the zone and the DNSKEY RRset re-signed with the current key- from the zone's DNSKEY RRset, which must then be re-signed with the
signing key. This time is the removal time (Trem), given by: current key-signing key. This time is the removal time (Trem), given
by:
Trem >= Tdea Trem >= Tdea
...at which time the key is said to be removed. ... at which time the key is said to be removed.
3.2.2. Double-Signature Method 3.2.2. Double-Signature Method
The timeline for a double-signature rollover is shown below. The The timeline for a double-signature rollover is shown below. The
diagram follows the convention described in Section 3.2.1 diagram follows the convention described in Section 3.2.1
|1| |2| |3| |4| |5| |1| |2| |3| |4| |5|
| | | | | | | | | |
Key N | |<----Lzsk--->|<---Iret--->| | Key N | |<----Lzsk--->|<---Iret--->| |
| | | | | | | | | |
Key N+1 | | |<-----Lzsk------- - - Key N+1 | | |<-----Lzsk------- - -
| | | | | | | | | |
Tgen Tact Tret Tdea Trem Tgen Tact Tret Tdea Trem
---- Time ----> ---- Time ---->
skipping to change at page 12, line 16 skipping to change at page 12, line 26
Key N | |<----Lzsk--->|<---Iret--->| | Key N | |<----Lzsk--->|<---Iret--->| |
| | | | | | | | | |
Key N+1 | | |<-----Lzsk------- - - Key N+1 | | |<-----Lzsk------- - -
| | | | | | | | | |
Tgen Tact Tret Tdea Trem Tgen Tact Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 2: Timeline for a Double-Signature ZSK rollover. Figure 2: Timeline for a Double-Signature ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: key N is added to the DNSKEY RRset and is then used to sign Event 2: Key N is added to the DNSKEY RRset and is then used to sign
the zone; existing signatures in the zone are not removed. This is the zone; existing signatures in the zone are not removed. This is
the activation time (Tact), after which the key is said to be active. the activation time (Tact), after which the key is said to be active.
Event 3: after the current key (key N) has been in use for its Event 3: After the current key (key N) has been in use for its
intended lifetime (Lzsk), the successor key (key N+1) is introduced intended lifetime (Lzsk), the successor key (key N+1) is introduced
into the zone and starts being used to sign RRsets: neither the into the zone and starts being used to sign RRsets: neither the
current key nor the signatures created with it are removed. The current key nor the signatures created with it are removed. The
successor is key is now active and the current key is said to be successor is key is now active and the current key is said to be
retired. This time is the retire time of the key (Tret); it is also retired. This time is the retire time of the key (Tret); it is also
the activation time of the successor key (TactS). the activation time of the successor key (TactS).
Tret = Tact + Lzsk Tret = Tact + Lzsk
Event 4: before key N can be withdrawn from the zone, all RRsets that Event 4: Before key N can be withdrawn from the zone, all RRsets that
need to be signed must have been signed by the successor key (key need to be signed must have been signed by the successor key (key
N+1) and any old RRsets that do not include the new key or new RRSIGs N+1) and any old RRsets that do not include the new key or new RRSIGs
must have expired from caches. Note that the signatures are not must have expired from caches. Note that the signatures are not
replaced - each RRset is signed by both the old and new key. replaced - each RRset is signed by both the old and new key.
This takes Iret, the retire interval, given by the expression: This takes Iret, the retire interval, given by the expression:
Iret = Dsgn + Dprp + max(TTLkey, TTLsig) Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
As before, Dsgn is the delay needed to ensure that all existing As before, Dsgn is the delay needed to ensure that all existing
RRsets have been signed with the new key, Dprp is the propagation RRsets have been signed with the new key and Dprp is the propagation
delay. The final term (the maximum of TTLkey and TTLsig) is the delay. The final term (the maximum of TTLkey and TTLsig) is the
period to wait for key and signature data associated with key N to period to wait for key and signature data associated with key N to
expire from caches. (TTLkey is the TTL of the DNSKEY RRset and expire from caches. (TTLkey is the TTL of the DNSKEY RRset and
TTLsig is the maximum TTL of all the RRSIG records in the zone TTLsig is the maximum TTL of all the RRSIG records in the zone
created with the ZSK. The two may be different as although the TTL created with the ZSK. The two may be different: although the TTL of
of an RRSIG is equal to the TTL of the RRs in the associated RRset an RRSIG is equal to the TTL of the RRs in the associated RRset
[RFC4034], the DNSKEY RRset only needs to be signed with the KSK.) [RFC4034], the DNSKEY RRset only needs to be signed with the KSK.)
At the end of this interval, key N is said to be dead. This occurs At the end of this interval, key N is said to be dead. This occurs
at the dead time (Tdea) so: at the dead time (Tdea) so:
Tdea = Tret + Iret Tdea = Tret + Iret
Event 5: at some later time key N and its signatures can be removed Event 5: At some later time key N and the signatures generated with
from the zone. This is the removal time Trem, given by: it can be removed from the zone. This is the removal time Trem,
given by:
Trem >= Tdea Trem >= Tdea
3.2.3. Double-RRSIG Method 3.2.3. Double-RRSIG Method
The timeline for a double-signature rollover is shown below. The The timeline for a double-signature rollover is shown below. The
diagram follows the convention described in Section 3.2.1 diagram follows the convention described in Section 3.2.1
|1||2| |3| |4||5| |6| |7||8| |9| |10| |1||2| |3| |4||5| |6| |7||8| |9| |10|
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 13, line 39 skipping to change at page 14, line 5
| |<---IpubG-->| | | | | | | | |<---IpubG-->| | | | | | |
| | | | | | | | | | | | | | | | | | | |
Key N+1 | | | | | |<-IpubG->| | | | Key N+1 | | | | | |<-IpubG->| | | |
| | | | | | | | | | | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 3: Timeline for a Double-Signature ZSK rollover. Figure 3: Timeline for a Double-Signature ZSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: key N is used to sign the zone but existing signatures are Event 2: Key N is used to sign the zone but existing signatures are
retained. Although the new ZSK is not published in the zone at this retained. Although the new ZSK is not published in the zone at this
point, for analogy with the other ZSK rollover methods and because point, for analogy with the other ZSK rollover methods and because
this is the first time that key information is visible (albeit this is the first time that key information is visible (albeit
indirectly through the created signatures) this time is called the indirectly through the created signatures) this time is called the
publication time (Tpub). publication time (Tpub).
Event 3: after the signing interval, Dsgn, all RRsets that need to be Event 3: After the signing interval, Dsgn, all RRsets that need to be
signed have been signed by the new key. (As a result, all these signed have been signed by the new key. (As a result, all these
RRsets are now signed twice, once by the (still-absent) key N and RRsets are now signed twice, once by the (still-absent) key N and
once by its predecessor. once by its predecessor.
Event 4: there is now a delay while the old signature information Event 4: There is now a delay while the old signature information
expires from caches. This interval is given by the expression: expires from caches. This interval is given by the expression:
Dprp + TTLsig Dprp + TTLsig
As before, Dprp is the propagation delay and TTLsig is the maximum As before, Dprp is the propagation delay and TTLsig is the maximum
TTL of all the RRSIG records in the zone. TTL of all the RRSIG records in the zone created with the ZSK.
Again in analogy with other key rollover methods, this is defined as Again in analogy with other key rollover methods, this is defined as
key N's ready time (Trdy) and the key is said to be in the ready key N's ready time (Trdy) and the key is said to be in the ready
state. (Although the key is not in the zone, it is ready to be state. (Although the key is not in the zone, it is ready to be
used.) The interval between the publication and ready times is the used.) The interval between the publication and ready times is the
publication interval of the signature, IpubG, i.e. publication interval of the signature, IpubG, i.e.,
Trdy = Tpub + IpubG Trdy = Tpub + IpubG
where where
IpubG = Dsgn + Dprp + TTLsig IpubG = Dsgn + Dprp + TTLsig
Event 5: at some later time the predecessor key is removed and the Event 5: At some later time the predecessor key is removed and the
key N added to the DNSKEY RRset. As all the signed RRs have key N added to the DNSKEY RRset. As all the signed RRs have
signatures created by the old and new keys, the records can still be signatures created by the old and new keys, the records can still be
authenticated. This time is the activation time (Tact) and the key authenticated. This time is the activation time (Tact) and the key
is now said to be active. is now said to be active.
Event 6: at some point thought must be given to rolling the key. The Event 6: At some point thought must be given to rolling the key. The
first step is to publish signatures created by the successor key (key first step is to publish signatures created by the successor key (key
N+1) early enough for key N to be replaced after it has been active N+1) early enough for key N to be replaced after it has been active
for its scheduled lifetime. This occurs at TpubS (the publication for its scheduled lifetime. This occurs at TpubS (the publication
time of the successor), given by: time of the successor), given by:
TpubS <= Tact + Lzsk - IpubG TpubS <= Tact + Lzsk - IpubG
Event 7: the signatures have propagated and the new key could be Event 7: The signatures have propagated and the new key could be
added to the zone. This time is the ready time of the successor key added to the zone. This time is the ready time of the successor key
(TrdyS). (TrdyS).
TrdyS = TpubS + IpubG TrdyS = TpubS + IpubG
... where IpubG is as defined above. ... where IpubG is as defined above.
Event 8: at some later time key N is removed from the zone and the Event 8: At some later time key N is removed from the zone's DNSKEY
successor key (key N+1) added. This is the retire time of the key RRset and the successor key (key N+1) is added to it. This is the
(Tret). retire time of the key (Tret).
Event 9: the signatures must remain in the zone for long enough that Event 9: The signatures must remain in the zone for long enough that
the new DNSKEY RRset has had enough time to propagate to all caches. the new DNSKEY RRset has had enough time to propagate to all caches.
Once caches contain the new DNSKEY, the old signatures are no longer Once caches contain the new DNSKEY, the old signatures are no longer
of use and can be considered to be dead. The time at which this as of use and can be considered to be dead as they cannot be validated
they can not be validated by any key. In analogy with other rollover by any key. In analogy with other rollover methods, the time at
methods, the time at which this occurs is the dead time (Tdea), given which this occurs is the dead time (Tdea), given by:
by:
Tdea = Tret + Iret Tdea = Tret + Iret
... where Iret is the retire interval, given by: ... where Iret is the retire interval, given by:
Iret = Dprp + TTLkey Iret = Dprp + TTLkey
Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset. Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset.
Event 10: at some later time the signatures can be removed from the Event 10: At some later time the signatures can be removed from the
zone. In analogy with other rollover methods this time is called the zone. In analogy with other rollover methods, this time is called
remove time (Trem) and is given by: the remove time (Trem) and is given by:
Trem >= Tdea Trem >= Tdea
3.3. Key-Signing Key Rollover Timelines 3.3. Key-Signing Key Rollover Timelines
The following sections describe the rolling of a KSK. They show the The following sections describe the rolling of a KSK. They show the
events in the lifetime of a key (referred to as "key N") and cover it events in the lifetime of a key (referred to as "key N") and cover it
replacement by its successor (key N+1). replacement by its successor (key N+1).
3.3.1. Double-Signature Method 3.3.1. Double-Signature Method
skipping to change at page 16, line 14 skipping to change at page 16, line 20
|1| |2| |3| |4| |5| |1| |2| |3| |4| |5|
| | | | | | | | | |
Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - - Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - -
| | | | | | | | | |
Key N+1 | | | | | Key N+1 | | | | |
| | | | | | | | | |
Tgen Tpub Trdy Tsub Tact Tgen Tpub Trdy Tsub Tact
---- Time ----> ---- Time ---->
(continued...) (continued ...)
|6| |7| |8| |9| |10| |11| |6| |7| |8| |9| |10| |11|
| | | | | | | | | | | |
Key N - - -------------Lksk------->|<-Iret->| | Key N - - -------------Lksk------->|<-Iret->| |
| | | | | | | | | | | |
Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | | | | | | | |
TpubS TrdyS TsubS Tret Tdea Trem TpubS TrdyS TsubS Tret Tdea Trem
---- Time (cont) ----> ---- Time (cont) ---->
Figure 4: Timeline for a Double-Signature KSK rollover. Figure 4: Timeline for a Double-Signature KSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: key N is introduced into the zone; it is added to the DNSKEY Event 2: Key N is introduced into the zone; it is added to the DNSKEY
RRset, which is then signed by key N and all currently active KSKs. RRset, which is then signed by key N and all currently active KSKs.
(So at this point, the DNSKEY RRset is signed by both key N and its (So at this point, the DNSKEY RRset is signed by both key N and its
predecessor KSK. If other KSKs were active, it is signed by these as predecessor KSK. If other KSKs were active, it is signed by these as
well.) This is the publication time (Tpub); after this the key is well.) This is the publication time (Tpub); after this the key is
said to be published. said to be published.
Event 3: before it can be used, the key must be published for long Event 3: Before it can be used, the key must be published for long
enough to guarantee that any validating resolver that has a copy of enough to guarantee that any validating resolver that has a copy of
the DNSKEY RRset in its cache will have a copy of the RRset that the DNSKEY RRset in its cache will have a copy of the RRset that
includes this key: in other words, that any prior cached information includes this key: in other words, that any prior cached information
about the DNSKEY RRset has expired. about the DNSKEY RRset has expired.
The interval is the publication interval (Ipub) and, for the second The interval is the publication interval (Ipub) and, for the second
or subsequent KSKs in the zone, is given by: or subsequent KSKs in the zone, is given by:
Ipub = DprpC + TTLkey Ipub = DprpC + TTLkey
... where DprpC is the propagation delay for the child zone (the zone ... where DprpC is the propagation delay for the child zone (the zone
containing the KSK being rolled) and TTLkey the TTL for the DNSKEY containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
RRset. The time at which this occurs is the key's ready time, Trdy, RRset. The time at which this occurs is the key's ready time, Trdy,
given by: given by:
Trdy = Tpub + Ipub Trdy = Tpub + Ipub
(The case of introducing the first KSK into the zone is discussed in (The case of introducing the first KSK into the zone is discussed in
Section 3.3.5.) Section 3.3.5.)
Event 4: at some later time, the DS record corresponding to the new Event 4: At some later time, the DS record corresponding to the new
KSK is submitted to the parent zone for publication. This time is KSK is submitted to the parent zone for publication. This time is
the submission time, Tsub. the submission time, Tsub.
Event 5: the DS record is published in the parent zone. As this is Event 5: The DS record is published in the parent zone. As this is
the point at which all information for authentication - both DNSKEY the point at which all information for authentication - both DNSKEY
and DS record - is available in the two zones, in analogy with other and DS record - is available in the two zones, in analogy with other
rollover methods, this is called the activation time of the key rollover methods, this is called the activation time of the key
(Tact): (Tact):
Tact = Tsub + Dreg Tact = Tsub + Dreg
... where Dreg is the registration delay, the time taken after the DS ... where Dreg is the registration delay, the time taken after the DS
record has been received by the parent zone manager for it to be record has been received by the parent zone manager for it to be
placed in the zone. (Parent zones are often managed by different placed in the zone. (Parent zones are often managed by different
entities, and this term accounts for the organisational overhead of entities, and this term accounts for the organisational overhead of
transferring a record.) transferring a record.)
Event 6: while key N is active, thought needs to be given to its Event 6: While key N is active, thought needs to be given to its
successor (key N+1). At some time before the scheduled end of the successor (key N+1). At some time before the scheduled end of the
KSK lifetime, the successor KSK is published in the zone. (As KSK lifetime, the successor KSK is published in the zone. (As
before, this means that the DNSKEY RRset is signed by both the before, this means that the DNSKEY RRset is signed by both the
current and successor KSK.) This time is the publication time of the current and successor KSK.) This time is the publication time of the
successor key, TpubS, given by: successor key, TpubS, given by:
TpubS <= Tact + Lksk - Dreg - Ipub TpubS <= Tact + Lksk - Dreg - Ipub
... where Lksk is the scheduled lifetime of the KSK. ... where Lksk is the scheduled lifetime of the KSK.
Event 7: after an interval Ipub, key N+1 becomes ready (in that all Event 7: After an interval Ipub, key N+1 becomes ready (in that all
caches that have a copy of the DNSKEY RRset have a copy of this key). caches that have a copy of the DNSKEY RRset have a copy of this key).
This time is the ready time of the successor (TrdyS). This time is the ready time of the successor (TrdyS).
Event 8: at the submission time of the successor (TsubS), the DS Event 8: At the submission time of the successor (TsubS), the DS
record corresponding to key N+1 is submitted to the parent zone. record corresponding to key N+1 is submitted to the parent zone.
Event 9: the successor DS record is published in the parent zone and Event 9: The successor DS record is published in the parent zone and
the current DS record withdrawn. The current key is said to be the current DS record withdrawn. The current key is said to be
retired and the time at which this occurs is Tret, given by: retired and the time at which this occurs is Tret, given by:
Tret = Tact + Lksk Tret = Tact + Lksk
Event 10: key N must remain in the zone until any caches that contain Event 10: Key N must remain in the zone until any caches that contain
a copy of the DS RRset have a copy containing the new DS record. a copy of the DS RRset have a copy containing the new DS record.
This interval is the retire interval, given by: This interval is the retire interval, given by:
Iret = DprpP + TTLds Iret = DprpP + TTLds
... where DprpP is the propagation delay in the parent zone and TTLds ... where DprpP is the propagation delay in the parent zone and TTLds
the TTL of a DS record in the parent zone. the TTL of a DS record in the parent zone.
As the key is no longer used for anything, is said to be dead. This As the key is no longer used for anything, is said to be dead. This
point is the dead time (Tdea), given by: point is the dead time (Tdea), given by:
Tdea = Tret + Iret Tdea = Tret + Iret
Event 11: at some later time, key N is removed from the zone (at the Event 11: At some later time, key N is removed from the zone's DNSKEY
remove time Trem); the key is now said to be removed. RRset (at the remove time Trem); the key is now said to be removed.
Trem >= Tdea Trem >= Tdea
3.3.2. Double-DS Method 3.3.2. Double-DS Method
The timeline for a double-DS rollover is shown below. The diagram The timeline for a double-DS rollover is shown below. The diagram
follows the convention described in Section 3.2.1 follows the convention described in Section 3.2.1
|1| |2| |3| |4| |5| |6| |1| |2| |3| |4| |5| |6|
| | | | | | | | | | | |
Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - -
| | | | | | | | | | | |
Key N+1 | | | | |<---->|<--Dreg+IpubP- - - Key N+1 | | | | |<---->|<--Dreg+IpubP- - -
| | | | | | | | | | | |
Tgen Tsub Tpub Trdy Tact TsubS Tgen Tsub Tpub Trdy Tact TsubS
---- Time ----> ---- Time ---->
(continued...) (continued ...)
|7| |8| |9| |10| |7| |8| |9| |10|
| | | | | | | |
Key N - - -----Lksk---------->|<-Iret->| | Key N - - -----Lksk---------->|<-Iret->| |
| | | | | | | |
Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - - Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - -
| | | | | | | |
TrdyS Tret Tdea Trem TrdyS Tret Tdea Trem
---- Time ----> ---- Time ---->
Figure 5: Timeline for a Double-DS KSK rollover. Figure 5: Timeline for a Double-DS KSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: the DS RR is submitted to the parent zone for publication. Event 2: The DS RR is submitted to the parent zone for publication.
This time is the submission time, Tsub. This time is the submission time, Tsub.
Event 3: after the registration delay, Dreg, the DS record is Event 3: After the registration delay, Dreg, the DS record is
published in the parent zone. This is the publication time Tpub, published in the parent zone. This is the publication time Tpub,
given by: given by:
Tpub = Tsub + Dreg Tpub = Tsub + Dreg
Event 4: at some later time, any cache that has a copy of the DS Event 4: At some later time, any cache that has a copy of the DS
RRset will have a copy of the DS record for key N. At this point, key RRset will have a copy of the DS record for key N. At this point, key
N, if introduced into the DNSKEY RRset, could be used to validate the N, if introduced into the DNSKEY RRset, could be used to validate the
zone. For this reason, this time is known as the key's ready time, zone. For this reason, this time is known as the key's ready time,
Trdy, and is given by: Trdy, and is given by:
Trdy = Tpub + IpubP Trdy = Tpub + IpubP
IpubP is the parent publication interval and is given by the IpubP is the parent publication interval and is given by the
expression: expression:
IpubP = DprpP + TTLds IpubP = DprpP + TTLds
... where DprpP is the propagation delay for the parent zone and ... where DprpP is the propagation delay for the parent zone and
TTLds the TTL assigned to DS records in that zone. TTLds the TTL assigned to DS records in that zone.
Event 5: at some later time, the key rollover takes place and the new Event 5: At some later time, the key rollover takes place and the new
key (key N) introduced and used to sign the RRset. key (key N) is introduced into the DNSKEY RRset and used to sign
that.
As both the old and new DS records have been in the parent zone long As both the old and new DS records have been in the parent zone long
enough to ensure that they are in caches that contain the DS RRset, enough to ensure that they are in caches that contain the DS RRset,
the zone can be authenticated throughout the rollover - either the the zone can be authenticated throughout the rollover - the
resolver has a copy of the DNSKEY RRset authenticated by the validating resolver either has a copy of the DNSKEY RRset
predecessor key, or it has a copy of the updated RRset authenticated authenticated by the predecessor key, or it has a copy of the updated
with the new key. RRset authenticated with the new key.
This time is key N's activation time (Tact) and at this point the key This time is key N's activation time (Tact) and at this point the key
is said to be active. is said to be active.
Event 6: at some point thought must be given to key replacement. The Event 6: At some point thought must be given to key replacement. The
DS record for the successor key must be submitted to the parent zone DS record for the successor key must be submitted to the parent zone
at a time such that when the current key is withdrawn, any cache that at a time such that when the current key is withdrawn, any cache that
contains the zone's DS records have data about the DS record of the contains the zone's DS records has data about the DS record of the
successor key. The time at which this occurs is the submission time successor key. The time at which this occurs is the submission time
of the successor, given by: of the successor, given by:
TsubS <= Tact + Lksk - IpubP - Dreg TsubS <= Tact + Lksk - IpubP - Dreg
... where Lksk is the lifetime of key N according to policy. ... where Lksk is the lifetime of key N according to policy.
Event 7: the successor key (key N+1) enters the ready state i.e. its Event 7: The successor key (key N+1) enters the ready state, i.e.,
DS record is now in caches that contain the parent DS RRset. This is its DS record is now in caches that contain the parent DS RRset.
the ready time of the successor key, TrdyS. This is the ready time of the successor key, TrdyS.
(The interval between events 6 and 7 for the key N+1 correspond to (The interval between events 6 and 7 for the key N+1 correspond to
the the interval between events 2 and 4 for key N) the interval between events 2 and 4 for key N)
Event 8: when key N has been active for its lifetime (Lksk), it is Event 8: When key N has been active for its lifetime (Lksk), it is
removed from the DNSKEY RRset and key N+1 added; the RRset is then replaced in the DNSKEY RRset by key N+1; the RRset is then signed
signed with the new key. This is the retire time of the key, Tret, with the new key. This is the retire time (Tret) of key N, given by:
given by:
Tret = Tact + Lksk Tret = Tact + Lksk
Event 9: at some later time, all copies of the old DNSKEY RRset have Event 9: At some later time, all copies of the old DNSKEY RRset have
expired from caches and the old DS record is no longer needed. In expired from caches and the old DS record is no longer needed. In
analogy with other rollover methods, this is called the dead time, analogy with other rollover methods, this is called the dead time,
Tdea, and is given by: Tdea, and is given by:
Tdea = Tret + Iret Tdea = Tret + Iret
... where Iret is the retire interval, given by: ... where Iret is the retire interval, given by:
Iret = DprpC + TTLkey Iret = DprpC + TTLkey
As before, this term includes DprpC, the time taken to propagate the As before, this term includes DprpC, the time taken to propagate the
RRset change through the master-slave hierarchy of the child zone and RRset change through the master-slave hierarchy of the child zone and
TTLkey, the time taken for the DNSKEY RRset to expire from caches. TTLkey, the time taken for the DNSKEY RRset to expire from caches.
Event 10: at some later time, the DS record is removed from the Event 10: At some later time, the DS record is removed from the
parent zone. In analogy with other rollover methods, this is the parent zone. In analogy with other rollover methods, this is the
removal time (Trem), given by: removal time (Trem), given by:
Trem >= Tdea Trem >= Tdea
3.3.3. Double-RRset Method 3.3.3. Double-RRset Method
The timeline for a double-RRset rollover is shown below. The diagram The timeline for a double-RRset rollover is shown below. The diagram
follows the convention described in Section 3.2.1 follows the convention described in Section 3.2.1
skipping to change at page 21, line 45 skipping to change at page 21, line 45
Key N | |<-Ipub->|<-----Lksk----->| | Key N | |<-Ipub->|<-----Lksk----->| |
| | | | | | | | | | | |
Key N+1 | | | |<-Ipub->| | Key N+1 | | | |<-Ipub->| |
| | | | | | | | | | | |
Tgen Tpub Tact TpubS Tret Trem Tgen Tpub Tact TpubS Tret Trem
---- Time ----> ---- Time ---->
Figure 6: Timeline for a Double-RRset KSK rollover. Figure 6: Timeline for a Double-RRset KSK rollover.
Event 1: key N is generated at the generate time (Tgen). Although Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published separate event. Keys that are available for use but not published
are said to be generated. are said to be generated.
Event 2: the key is added to and used for signing the DNSKEY RRset Event 2: The key is added to and used for signing the DNSKEY RRset
and is thereby published in the zone. At the same time the and is thereby published in the zone. At the same time the
corresponding DS record is submitted to the parent zone for corresponding DS record is submitted to the parent zone for
publication. This time is the publish time (Tpub) and the key is now publication. This time is the publish time (Tpub) and the key is now
said to be published. said to be published.
Event 3: at some later time, the DS record is published in the parent Event 3: At some later time, the DS record is published in the parent
zone and at some time after that, the updated information has reached zone and at some time after that, the updated information has reached
all caches: any cache that holds a DNSKEY RRset from the child zone all caches: any cache that holds a DNSKEY RRset from the child zone
will have a copy that includes the new KSK, and any cache that has a will have a copy that includes the new KSK, and any cache that has a
copy of the parent DS RRset will have a copy that includes the new DS copy of the parent DS RRset will have a copy that includes the new DS
record. record.
The time at which this occurs is called the activation time of the The time at which this occurs is called the activation time of the
new KSK (Tact), given by: new KSK (Tact), given by:
Tact = Tpub + Ipub Tact = Tpub + Ipub
skipping to change at page 22, line 47 skipping to change at page 22, line 46
zone's propagation delay and TTLds is the TTL of the DS record in zone's propagation delay and TTLds is the TTL of the DS record in
that zone. that zone.
The child's publication interval is given by a similar equation: The child's publication interval is given by a similar equation:
IpubC = DprpC + TTLkey IpubC = DprpC + TTLkey
... where DprpC is the propagation delay in the child zone and TTLkey ... where DprpC is the propagation delay in the child zone and TTLkey
the TTL of a DNSKEY record. the TTL of a DNSKEY record.
Event 4: at some point we need to give thought to key replacement. Event 4: At some point we need to give thought to key replacement.
The successor key (key N+1) must be introduced into the zone (and its The successor key (key N+1) must be introduced into the zone (and its
DS record submitted to the parent) at a time such that it becomes DS record submitted to the parent) at a time such that it becomes
active when the current key has been active for its lifetime, Lksk. active when the current key has been active for its lifetime, Lksk.
This time is TpubS, the publication time of the successor key, and is This time is TpubS, the publication time of the successor key, and is
given by: given by:
TpubS <= Tact + Lksk - Ipub TpubS <= Tact + Lksk - Ipub
... where Lksk is the lifetime of the KSK. ... where Lksk is the lifetime of the KSK.
Event 5: key N+1's DNSKEY and DS records are in any caches that Event 5: Key N+1's DNSKEY and DS records are in any caches that
contain the child zone DNSKEY and/or the parent zone DS RR, and so contain the child zone DNSKEY and/or the parent zone DS RR, and so
the zone can be validated with the new key. This is the activation the zone can be validated with the new key. This is the activation
time of the successor key (TactS) and by analogy with other rollover time of the successor key (TactS) and by analogy with other rollover
methods, it is also the retire time of the current key. Since at methods, it is also the retire time of the current key. Since at
this time the zone can be validated by the successor key, there is no this time the zone can be validated by the successor key, there is no
reason to keep the current key in the zone and the time can also be reason to keep the current key in the zone and the time can also be
regarded as the current key's dead time. Thus: regarded as the current key's dead time. Thus:
Tret = Tdea = TactS = Tact + Lksk Tret = Tdea = TactS = Tact + Lksk
Event 6: at some later time, the key N's DS and DNSKEY records can be Event 6: At some later time, the key N's DS and DNSKEY records are
removed from their respective zones. In analogy with other rollover removed from their respective zones. In analogy with other rollover
methods, this is the removal time (Trem), given by: methods, this is the removal time (Trem), given by:
Trem >= Tdea Trem >= Tdea
3.3.4. Interaction with Configured Trust Anchors 3.3.4. Interaction with Configured Trust Anchors
Although the preceding sections have been concerned with rolling KSKs Although the preceding sections have been concerned with rolling KSKs
where the trust anchor is a DS record in the parent zone, zone where the trust anchor is a DS record in the parent zone, zone
managers may want to take account of the possibility that some managers may want to take account of the possibility that some
skipping to change at page 23, line 45 skipping to change at page 23, line 44
requires introducing the KSK to be used as the trust anchor into the requires introducing the KSK to be used as the trust anchor into the
zone for a period of time before use, and retaining it (with the zone for a period of time before use, and retaining it (with the
"revoke" bit set) for some time after use. "revoke" bit set) for some time after use.
3.3.4.1. Addition of KSK 3.3.4.1. Addition of KSK
When the new key is introduced, the publication interval (Ipub) in When the new key is introduced, the publication interval (Ipub) in
the Double-Signature and Double-RRset methods should also be subject the Double-Signature and Double-RRset methods should also be subject
to the condition: to the condition:
Ipub >= Dprp + max(30 days, TTLkey) Ipub >= Dprp + max(Itrp, TTLkey)
... where the right hand side of the expression is the time taken for ... where the right hand side of the expression is the time taken for
the change to propagate to all nameservers for the zone plus the add the change to propagate to all nameservers for the zone plus the
hold-down time defined in section 2.4.1 of [RFC5011]. "trust point" interval. This latter term is the interval required to
guarantee that a resolver configured for the automatic update of keys
from a particular trust point will see at least two validated DNSKEY
RRsets containing the new key (a requirement from [RFC5011], section
2.4.1). It is defined by the expression:
In the Double-DS method, instead of the changing of the KSK RR being Itrp >= (2 * queryInterval) + (n * retryTime)
instantaneous, there must now be a period of overlap. In other
words, the new KSK must be introduced into the zone at least:
DprpC + max(30 days, TTLkey) ... where queryInterval and retryTime are as defined in section 2.3
of [RFC5011]. "n" is the total number of retries needed by the
resolver during the two attempts to get the DNSKEY RRset.
The first term of the expression (2 * queryInterval) represents the
time to obtain two validated DNSKEY RRsets. The second term (n *
retryTime) is a safety margin, with the value of "n" reflecting the
degree of confidence in the communication between a resolver and the
trust point.
In the Double-DS method, instead of swapping the KSK RRs in a single
step, there must now be a period of overlap. In other words, the new
KSK must be introduced into the zone at least:
DprpC + max(Itrp, TTLkey)
... before the switch is made. ... before the switch is made.
3.3.4.2. Removal of KSK 3.3.4.2. Removal of KSK
The timeline for the removal of the key in all methods is modified by The timeline for the removal of the key in all methods is modified by
introducing a new state, "revoked". When the key reaches its dead introducing a new state, "revoked". When the key reaches its dead
time, instead of being declared "dead", it is revoked; the "revoke" time, instead of being declared "dead", it is revoked; the "revoke"
bit is set on the DNSKEY RR and is published in (and used to sign) bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed
the DNSKEY RRset. The key is maintained in this state for the with the current and revoked keys. The key is maintained in this
"revoke" interval, Irev, given by: state for the "revoke" interval, Irev, given by:
Irev >= 30 days Irev >= 30 days
... 30 days being the [RFC5011] remove hold-down time. After this ... 30 days being the [RFC5011] remove hold-down time. After this
time, the key is dead and can be removed from the zone. time, the key is dead and can be removed from the zone.
3.3.5. Introduction of First KSK 3.3.5. Introduction of First Keys
There is an additional consideration when introducing a KSK into a There are no timing considerations associated with the introduction
zone for the first time, and that is that no validating resolver of the first keys into a zone other that they must be introduced and
should be in a position where it can access the trust anchor before the zone validly signed before a chain of trust to the zone is
the KSK appears in the zone. To do so will cause it to declare the created.
zone to be bogus.
This is important: in the case of a secure parent, it means ensuring This is important: in the case of a secure parent, it means ensuring
that the DS record is not published in the parent zone until there is that the DS record is not published in the parent zone until there is
no possibility that a validating resolver can obtain the record yet no possibility that a validating resolver can obtain the record yet
not be able to obtain the corresponding DNSKEY. In the case of an is not able to obtain the corresponding DNSKEY. In the case of an
insecure parent, i.e. the initial creation of a new security apex, it insecure parent, i.e., the initial creation of a new security apex,
is not possible to guarantee this. It is up to the operator of the it is not possible to guarantee this. It is up to the operator of
validating resolver to wait for the new KSK to appear at all servers the validating resolver to wait for the new KSK to appear at all
for the zone before configuring the trust anchor. servers for the zone before configuring the trust anchor.
4. Standby Keys 4. Standby Keys
Although keys will usually be rolled according to some regular Although keys will usually be rolled according to some regular
schedule, there may be occasions when an emergency rollover is schedule, there may be occasions when an emergency rollover is
required, e.g. if the active key is suspected of being compromised. required, e.g., if the active key is suspected of being compromised.
The aim of the emergency rollover is to allow the zone to be re- The aim of the emergency rollover is to allow the zone to be re-
signed with a new key as soon as possible. As a key must be in the signed with a new key as soon as possible. As a key must be in the
ready state to sign the zone, having at least one additional key (a ready state to sign the zone, having at least one additional key (a
standby key) in this state at all times will minimise delay. standby key) in this state at all times will minimise delay.
In the case of a ZSK, a standby key only really makes sense with the In the case of a ZSK, a standby key only really makes sense with the
Pre-Publication method. A permanent standby DNSKEY RR should be Pre-Publication method. A permanent standby DNSKEY RR should be
included in zone or successor keys could be introduced as soon as included in the zone or successor keys could be introduced as soon as
possible after a key becomes active. Either way results in one or possible after a key becomes active. Either way results in one or
more additional ZSKs in the DNSKEY RRset that can immediately be used more additional ZSKs in the DNSKEY RRset that can immediately be used
to sign the zone if the current key is compromised. to sign the zone if the current key is compromised.
(Although in theory the mechanism could be used with both the Double- (Although in theory the mechanism could be used with both the Double-
Signature and Double-RRSIG methods, it would require pre-publication Signature and Double-RRSIG methods, it would require pre-publication
of the signatures. Essentially, the standby key would be permanently of the signatures. Essentially, the standby key would be permanently
active, as it would have to be periodically used to renew signatures. active, as it would have to be periodically used to renew signatures.
Zones would also permanently require two sets of signatures.) Zones would also permanently require two sets of signatures.)
skipping to change at page 26, line 16 skipping to change at page 26, line 28
words, the key rollover logic described above should be run words, the key rollover logic described above should be run
separately for each algorithm; the union of the results is included separately for each algorithm; the union of the results is included
in the zone, which is signed using the active key for each algorithm. in the zone, which is signed using the active key for each algorithm.
6. Limitation of Scope 6. Limitation of Scope
This document represents current thinking at the time of publication. This document represents current thinking at the time of publication.
However, the subject matter is evolving and it is more than likely However, the subject matter is evolving and it is more than likely
that this document will need to be revised in the future. that this document will need to be revised in the future.
Some of the techniques and ideas that DNSSEC operators considering Some of the techniques and ideas that DNSSEC operators are
differ from this those described in this document. Of note are considering differ from this those described in this document. Of
alternatives to the strict split into KSK and ZSK key roles and the particular interest are alternatives to the strict split into KSK and
consequences for rollover logic from partial signing (i.e. when the ZSK key roles and the consequences for rollover logic from partial
new key initially only signs a fraction of the zone while leaving signing (i.e., when the new key initially only signs a fraction of
other signatures generated by the old key in place). the zone while leaving other signatures generated by the old key in
place).
Furthermore, as noted in section 5, this document covers only rolling Furthermore, as noted in section 5, this document covers only rolling
keys of the same algorithm, it does not cover transition to/from/ keys of the same algorithm: it does not cover transitions between
addition/deletion of different algorithms. Algorithm rollovers will algorithms. The timing issues associated with algorithm rollovers
require a separate document. will require a separate document.
The reader is therefore reminded that DNSSEC is as of publication in The reader is therefore reminded that DNSSEC is, as of date of
early stages of deployment, and best practices may further develop publication, in the early stages of deployment, and best practices
over time. may further develop over time.
7. Summary 7. Summary
For ZSKs, "Pre-Publication" is generally considered to be the For ZSKs, "Pre-Publication" is generally considered to be the
preferred way of rolling keys. As shown in this document, the time preferred way of rolling keys. As shown in this document, the time
taken to roll is wholly dependent on parameters under the control of taken to roll is wholly dependent on parameters under the control of
the zone manager. the zone manager.
In contrast, "Double-RRset" is the most efficient method for KSK In contrast, "Double-RRset" is the most efficient method for KSK
rollover due to the ability to have new DS records and DNSKEY RRsets rollover due to the ability to have new DS records and DNSKEY RRsets
skipping to change at page 27, line 23 skipping to change at page 27, line 36
9. Security Considerations 9. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
10. Acknowledgements 10. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy The authors gratefully acknowledge help and contributions from Roy
Arends, Matthijs Mekking and Wouter Wijngaards. Arends, Matthijs Mekking and Wouter Wijngaards.
11. Change History (To be removed on publication) 11. Normative References
o draft-ietf-dnsop-dnssec-key-timing-02
* Significant re-wording of some sections.
* Removal of events noting change of state of predecessor key from
ZSK Double-RRSIG and Double-Signature methods.
* Change order of bullet points (and some wording) in section 1.1.
* Remove discussion of advantages and disadvantages of key roll
methods from section 2: draft is informative and does not give
recommendations.
* Removal of discussion of upper limit to retire time relationship
to signature lifetime.
* Remove timing details of first key in the zone and move
discussion of first signing of a zone to later in the document).
(Matthijs Mekking)
* Removal of redundant symbols from Appendix A.
o draft-ietf-dnsop-dnssec-key-timing-01
* Added section on limitation of scope.
o draft-ietf-dnsop-dnssec-key-timing-00
* Change to author contact details.
o draft-morris-dnsop-dnssec-key-timing-02
* General restructuring.
* Added descriptions of more rollovers (IETF-76 meeting).
* Improved description of key states and removed diagram.
* Provided simpler description of standby keys.
* Added section concerning first key in a zone.
* Moved [RFC5011] to a separate section.
* Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
Lloyd, Tony Finch).
o draft-morris-dnsop-dnssec-key-timing-01
* Use latest boilerplate for IPR text.
* List different ways to roll a KSK (acknowledgements to Mark
Andrews).
* Restructure to concentrate on key timing, not management
procedures.
* Change symbol notation (Diane Davidowicz and others).
* Added key state transition diagram (Diane Davidowicz).
* Corrected spelling, formatting, grammatical and style errors
(Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
* Added note that in the case of multiple algorithms, the
signatures and rollovers for each algorithm can be considered as
more or less independent (Alfred Hoenes).
* Take account of the fact that signing a zone is not atomic
(Chris Thompson).
* Add section contrasting pre-publication rollover with double
signature rollover (Matthijs Mekking).
* Retained distinction between first and subsequent keys in
definition of initial publication interval (Matthijs Mekking).
o draft-morris-dnsop-dnssec-key-timing-00
Initial draft.
12. References
12.1. Normative References [I-D.ietf-dnsop-rfc4641bis]
Kolkman, O. and M. Mekking, "DNSSEC Operational Practices,
Version 2", draft-ietf-dnsop-rfc4641bis-11 (work in
progress), April 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007. Trust Anchors", RFC 5011, September 2007.
12.2. Informative References
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006.
Appendix A. List of Symbols Appendix A. List of Symbols
The document defines a number of symbols, all of which are listed The document defines a number of symbols, all of which are listed
here. All are of the form: here. All are of the form:
All symbols used in the text are of the form: All symbols used in the text are of the form:
<TYPE><id><INST> <TYPE><id><INST>
where: where:
skipping to change at page 29, line 38 skipping to change at page 28, line 41
D delay: interval that is a feature of the process D delay: interval that is a feature of the process
I interval between two events I interval between two events
L lifetime: interval set by the zone manager L lifetime: interval set by the zone manager
T a point in time T a point in time
TTL TTL of a record TTL TTL of a record
I and T and TTL are self-explanatory. Like I, D, and L are time I and T and TTL are self-explanatory. Like I, both D and L are time
periods, but whereas I values are intervals between two events (even periods, but whereas I values are intervals between two events (even
if the events are defined in terms of the interval, e.g. the dead if the events are defined in terms of the interval, e.g., the dead
time occurs "retire interval" after the retire time), D, and L are time occurs "retire interval" after the retire time), D and L are
fixed intervals: a "D" interval (delay) is a feature of the process, fixed intervals: a "D" interval (delay) is a feature of the process,
probably outside control of the zone manager, whereas an "L" interval probably outside control of the zone manager, whereas an "L" interval
(lifetime) is chosen by the zone manager and is a feature of policy. (lifetime) is chosen by the zone manager and is a feature of policy.
<id> is lower-case and defines what object or event the variable is <id> is lower-case and defines what object or event the variable is
related to, e.g. related to, e.g.,
act activation act activation
pub publication pub publication
ret retire ret retire
Finally, <INST> is a capital letter that distinguishes between the Finally, <INST> is a capital letter that distinguishes between the
same variable applying to different instances of an object and is one same variable applying to different instances of an object and is one
of: of:
C child C child
G signature G signature
K key
P parent P parent
S successor S successor
The list of variables used in the text is: The list of variables used in the text is:
Dprp Propagation delay. The amount of time for a change made at Dprp Propagation delay. The amount of time for a change made at
a master nameserver to propagate to all the slave a master nameserver to propagate to all the slave
nameservers. nameservers.
skipping to change at page 31, line 23 skipping to change at page 30, line 21
IpubP Publication interval in the parent zone. IpubP Publication interval in the parent zone.
Iret Retire interval. The amount of time that must elapse after Iret Retire interval. The amount of time that must elapse after
a key enters the retire state for any signatures created a key enters the retire state for any signatures created
with it to be purged from validating resolver caches. with it to be purged from validating resolver caches.
Irev Revoke interval. The amount of time that a KSK must remain Irev Revoke interval. The amount of time that a KSK must remain
published with the revoke bit set to satisfy [RFC5011] published with the revoke bit set to satisfy [RFC5011]
considerations. considerations.
Itrp Trust-point interval. The amount of time that a trust
anchor must be published for to guarantee that a resolver
configured for an automatic update of keys will see the new
key at least twice.
Lksk Lifetime of a key-signing key. This is the intended amount Lksk Lifetime of a key-signing key. This is the intended amount
of time for which this particular KSK is regarded as the of time for which this particular KSK is regarded as the
active KSK. Depending on when the key is rolled-over, the active KSK. Depending on when the key is rolled-over, the
actual lifetime may be longer or shorter than this. actual lifetime may be longer or shorter than this.
Lzsk Lifetime of a zone-signing key. This is the intended Lzsk Lifetime of a zone-signing key. This is the intended
amount of time for which the ZSK is used to sign the zone. amount of time for which the ZSK is used to sign the zone.
Depending on when the key is rolled-over, the actual Depending on when the key is rolled-over, the actual
lifetime may be longer or shorter than this. lifetime may be longer or shorter than this.
skipping to change at page 32, line 28 skipping to change at page 31, line 30
TrdyS Ready time of a successor key. TrdyS Ready time of a successor key.
Tsub Submission time - the time at which the DS record of a KSK Tsub Submission time - the time at which the DS record of a KSK
is submitted to the parent. is submitted to the parent.
TsubS Submission time of the successor key. TsubS Submission time of the successor key.
TTLds Time to live of a DS record (in the parent zone). TTLds Time to live of a DS record (in the parent zone).
TTLkey Time to live of a DNSKEY record. TTLkey Time to live of a DNSKEY record. (By implication, this is
also the time to live of the signatures on the DNSKEY
RRset.)
TTLsig The maximum time to live of all the RRSIG records in the TTLsig The maximum time to live of all the RRSIG records in the
zone that were created with the ZSK. zone that were created with the ZSK.
Appendix B. Change History (To be removed on publication)
o draft-ietf-dnsop-dnssec-key-timing-03
* Clarifications of and corrections to wording (Marc Lampo, Alfred
Hoenes).
* Updated timings related to trust anchor interaction (Matthijs
Mekking).
* Updated RFC 4641 reference to 4641bis (Alfred Hoenes).
* Moved change history to end of document (Alfred Hoenes).
o draft-ietf-dnsop-dnssec-key-timing-02
* Significant re-wording of some sections.
* Removal of events noting change of state of predecessor key from
ZSK Double-RRSIG and Double-Signature methods.
* Change order of bullet points (and some wording) in section 1.1.
* Remove discussion of advantages and disadvantages of key roll
methods from section 2: draft is informative and does not give
recommendations.
* Removal of discussion of upper limit to retire time relationship
to signature lifetime.
* Remove timing details of first key in the zone and move
discussion of first signing of a zone to later in the document).
(Matthijs Mekking)
* Removal of redundant symbols from Appendix A.
o draft-ietf-dnsop-dnssec-key-timing-01
* Added section on limitation of scope.
o draft-ietf-dnsop-dnssec-key-timing-00
* Change to author contact details.
o draft-morris-dnsop-dnssec-key-timing-02
* General restructuring.
* Added descriptions of more rollovers (IETF-76 meeting).
* Improved description of key states and removed diagram.
* Provided simpler description of standby keys.
* Added section concerning first key in a zone.
* Moved [RFC5011] to a separate section.
* Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
Lloyd, Tony Finch).
o draft-morris-dnsop-dnssec-key-timing-01
* Use latest boilerplate for IPR text.
* List different ways to roll a KSK (acknowledgements to Mark
Andrews).
* Restructure to concentrate on key timing, not management
procedures.
* Change symbol notation (Diane Davidowicz and others).
* Added key state transition diagram (Diane Davidowicz).
* Corrected spelling, formatting, grammatical and style errors
(Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
* Added note that in the case of multiple algorithms, the
signatures and rollovers for each algorithm can be considered as
more or less independent (Alfred Hoenes).
* Take account of the fact that signing a zone is not atomic
(Chris Thompson).
* Add section contrasting pre-publication rollover with double
signature rollover (Matthijs Mekking).
* Retained distinction between first and subsequent keys in
definition of initial publication interval (Matthijs Mekking).
o draft-morris-dnsop-dnssec-key-timing-00
Initial draft.
Authors' Addresses Authors' Addresses
Stephen Morris Stephen Morris
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 423 1300 Phone: +1 650 423 1300
Email: stephen@isc.org Email: stephen@isc.org
 End of changes. 111 change blocks. 
253 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/