draft-ietf-dnsop-dnssec-key-timing-06.txt   rfc7583.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force (IETF) S. Morris
Internet-Draft ISC Request for Comments: 7583 ISC
Intended status: Informational J. Ihren Category: Informational J. Ihren
Expires: April 16, 2015 Netnod ISSN: 2070-1721 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
W. Mekking W. Mekking
NLnet Labs Dyn
October 13, 2014 October 2015
DNSSEC Key Rollover Timing Considerations DNSSEC Key Rollover Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-06.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
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 16, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7583.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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. Limitation of Scope . . . . . . . . . . . . . . . . . . . 4 1.4. Limitation of Scope ........................................5
2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5 2. Rollover Methods ................................................5
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ZSK Rollovers ..............................................5
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 2.2. KSK Rollovers ..............................................7
3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 3. Key Rollover Timelines ..........................................8
3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Key States .................................................8
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 3.2. ZSK Rollover Timelines ....................................10
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 3.2.1. Pre-Publication Method .............................10
3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12 3.2.2. Double-Signature Method ............................12
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 14 3.3. KSK Rollover Timelines ....................................14
3.3.1. Double-KSK Method . . . . . . . . . . . . . . . . . . 14 3.3.1. Double-KSK Method ..................................14
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 16 3.3.2. Double-DS Method ...................................17
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 19 3.3.3. Double-RRset Method ................................20
3.3.4. Interaction with Configured Trust Anchors . . . . . . 21 3.3.4. Interaction with Configured Trust Anchors ..........22
3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 22 3.3.5. Introduction of First Keys .........................24
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 23 4. Standby Keys ...................................................24
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 24 5. Algorithm Considerations .......................................25
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Summary ........................................................26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations ........................................26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Normative References ...........................................26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. List of Symbols ......................................28
10. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgements ..................................................31
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses ................................................31
Appendix B. Change History (To be removed on publication) . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 3, line 25 skipping to change at page 3, line 25
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 DS records o DNSKEY records and associated information (such as the DS records
or RRSIG records created with the key) are not only held at the or RRSIG records created with the key) are not only held at the
authoritative nameserver, they are also cached by resolvers. The authoritative nameserver, they are also cached by resolvers. The
data on these systems can be interlinked, e.g., a validating data on these systems can be interlinked, e.g., a validating
resolver may try to validate a signature retrieved from a cache resolver may try to validate a signature retrieved from a cache
with a key obtained separately. with a key obtained separately.
o Zone "boot-strapping" events, where a zone is signed for the first o Zone "bootstrapping" 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.
o To allow for an emergency re-signing of the zone as soon as o To allow for an emergency re-signing of the zone as soon as
possible after a key compromise has been detected, standby keys possible after a key compromise has been detected, standby keys
(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.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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 [RFC6781]. In A high-level overview of key rollover can be found in [RFC6781]. In
contrast, this document focuses on the low-level timing detail of two contrast, this document focuses on the low-level timing detail of two
classes of operations described there, the rollover of zone-signing classes of operations described there, the rollover of Zone Signing
keys (ZSKs), and the rollover of key-signing keys (KSKs). Keys (ZSKs), and the rollover of Key Signing Keys (KSKs).
Note that the process for the introduction of keys into a zone is Note that the process for the introduction of keys into a zone is
different to that of rolling a key; see Section 3.3.5 for more different from that of rolling a key; see Section 3.3.5 for more
information about that topic. information.
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 ZSKs and KSKs. A ZSK is used recognizes the broad classification of ZSKs and KSKs. A ZSK is used
to authenticate information within the zone; a KSK is used to to authenticate information within the zone; a KSK is used to
authenticate the zone's DNSKEY RRset. The main implication for this authenticate the zone's DNSKEY RRset. The main implication for this
distinction concerns the consistency of information during a distinction concerns the consistency of information during a
rollover. rollover.
During operation, a validating resolver must use separate pieces of During operation, a validating resolver must use separate pieces of
information to perform an authentication. At the time of information to perform an authentication. At the time of
authentication, each piece of information may be in its cache or may authentication, each piece of information may be in its cache or may
need to be retrieved from an authoritative server. The rollover need to be retrieved from an authoritative server. The rollover
process needs to happen in such a way that at all times during the process needs to happen in such a way that the information is
rollover the information is consistent. With a ZSK, the information consistent at all times during the rollover. With a ZSK, the
is the RRSIG (plus associated RRset) and the DNSKEY. These are both information is the RRSIG (plus associated RRset) and the DNSKEY.
obtained from the same zone. In the case of the KSK, the information These are both obtained from the same zone. In the case of the KSK,
is the DNSKEY and DS RRset with the latter being obtained from a the information is the DNSKEY and DS RRset with the latter being
different zone. obtained from a different zone.
Although there are similarities in the algorithms to roll ZSKs and Although there are similarities in the algorithms to roll ZSKs and
KSKs, there are a number of differences. For this reason, the two KSKs, there are a number of differences. For this reason, the two
types of rollovers are described separately. types of rollovers are described separately.
1.3. Terminology 1.3. Terminology
The terminology used in this document is as defined in [RFC4033] and The terminology used in this document is as defined in [RFC4033] and
[RFC5011]. [RFC5011].
skipping to change at page 5, line 8 skipping to change at page 5, line 14
1.4. Limitation of Scope 1.4. 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 not possible for However, the subject matter is evolving and it is not possible for
the document to be comprehensive. In particular, it does not cover: the document to be comprehensive. In particular, it does not cover:
o Rolling a key that is used as both a ZSK and KSK. o Rolling a key that is used as both a ZSK and KSK.
o Algorithm rollovers. Only the rolling of keys of the same o Algorithm rollovers. Only the rolling of keys of the same
algorithm are described here, not transitions between algorithms. algorithm is described here: not transitions between algorithms.
The reader is therefore reminded that DNSSEC is, as of date of o Changing TTLs.
publication, in the early stages of deployment, and best practices
may further develop over time. Algorithm rollover is excluded from the document owing to the need
for there to be an RRSIG for at least one DNSKEY of each algorithm in
the DNSKEY RRset [RFC4035]. This introduces additional constraints
on rollovers that are not considered here. Such considerations do
not apply where other properties of the key, such as key length, are
changed during the rollover: the DNSSEC protocol does not impose any
restrictions in these cases.
Also excluded from consideration is the effect of changing the Time
to Live (TTL) of records in a zone. TTLs can be changed at any time,
but doing so around the time of a key rollover may have an impact on
event timings. In the timelines below, it is assumed that TTLs are
constant.
2. Rollover Methods 2. Rollover Methods
2.1. ZSK Rollovers 2.1. ZSK Rollovers
For ZSKs, the issue for the zone operator/signer is to ensure that For ZSKs, the issue for the zone operator/signer is to ensure that
any caching validator which has access to a particular signature also any caching validator that has access to a particular signature also
has access to the corresponding valid ZSK. has access to the corresponding valid ZSK.
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 [RFC6781], the new key is introduced o Pre-Publication: described in [RFC6781], the new key is introduced
into the DNSKEY RRset which is then re-signed. This state of into the DNSKEY RRset, which is then re-signed. This state of
affairs remains in place for long enough to ensure that any cached affairs remains in place for long enough to ensure that any cached
DNSKEY RRsets contain both keys. At that point signatures created DNSKEY RRsets contain both keys. At that point, signatures
with the old key can be replaced by those created with the new created with the old key can be replaced by those created with the
key, and the old signatures removed. During the re-signing new key. During the re-signing process (which may or may not be
process (which may or may not be atomic depending on how the zone atomic depending on how the zone is managed), it doesn't matter
is managed), it doesn't matter which key an RRSIG record retrieved with which key an RRSIG record retrieved by a resolver was
by a resolver was created with; cached copies of the DNSKEY RRset created; cached copies of the DNSKEY RRset will contain both the
will contain both the old and new keys. 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 be removed from the DNSKEY RRset. can be removed from the DNSKEY RRset.
o Double-Signature: also mentioned in [RFC6781], this involves o Double-Signature: also mentioned in [RFC6781], this involves
introducing the new key into the zone and using it to create introducing the new key into the zone and using it to create
additional RRSIG records; the old key and existing RRSIG records additional RRSIG records; the old key and existing RRSIG records
skipping to change at page 6, line 22 skipping to change at page 6, line 40
method (here called the Double-RRSIG method) involves introducing method (here called the Double-RRSIG method) involves introducing
new signatures in the zone (while still retaining the old ones) new signatures in the zone (while still retaining the old ones)
but not introducing the new key. but not introducing the new key.
Once the signing process is complete and enough time has elapsed Once the signing process is complete and enough time has elapsed
to ensure that all caches that may contain an RR and associated to ensure that all caches that may contain an RR and associated
RRSIG have a copy of both signatures, the key is changed. After a RRSIG have a copy of both signatures, the key is changed. After a
further interval during which the old DNSKEY RRset expires from further interval during which the old DNSKEY RRset expires from
caches, the old signatures are removed from the zone. caches, the old signatures are removed from the zone.
Of the three methods, Double-Signature is conceptually the simplest - Of the three methods, Double-Signature is conceptually the simplest:
introduce the new key and new signatures, then approximately one TTL introduce the new key and new signatures, then approximately one TTL
later remove the old key and old signatures. It is also the fastest, later remove the old key and old signatures. It is also the fastest,
but suffers from increasing the size of the zone and the size of but suffers from increasing the size of the zone and the size of
responses. responses.
Pre-Publication is more complex - introduce the new key, Pre-Publication is more complex: introduce the new key, approximately
approximately one TTL later sign the records, and approximately one one TTL later sign the records, and approximately one TTL after that
TTL after that remove the old key. It does however keep the zone and remove the old key. It does however keep the zone and response sizes
response sizes to a minimum. to a minimum.
Double-RRSIG is essentially the reverse of Pre-Publication - Double-RRSIG is essentially the reverse of Pre-Publication: introduce
introduce the new signatures, approximately one TTL later change the the new signatures, approximately one TTL later change the key, and
key, and approximately one TTL after that remove the old signatures. approximately one TTL after that remove the old signatures. However,
However, it has the disadvantage of the Pre-Publication method in it has the disadvantage of the Pre-Publication method in terms of
terms of time taken to perform the rollover, the disadvantage of the time taken to perform the rollover, the disadvantage of the Double-
Double-Signature rollover in terms of zone and response sizes, and Signature rollover in terms of zone and response sizes, and none of
none of the advantages of either. For these reasons, it is unlikely the advantages of either. For these reasons, it is unlikely to be
to be used in any real-world situations and so will not be considered used in any real-world situations and so will not be considered
further in this document. further in this document.
2.2. KSK Rollovers 2.2. KSK Rollovers
In the KSK case, there should not be a problem that a caching In the KSK case, there should be no problem with a caching validator
validator does not have access to a particular signature that not having access to a signature created with a valid KSK. The KSK
corresponds to a valid KSK. The KSK is only used for one signature is only used for one signature (that over the DNSKEY RRset) and both
(that over the DNSKEY RRset) and both the key and the signature the key and the signature travel together. Instead, the issue is to
travel together. Instead, the issue is to ensure that the KSK is ensure that the KSK is trusted.
trusted.
Trust in the KSK is either due to the existence of a signed and Trust in the KSK is due to either the existence of a signed and
validated DS record in the parent zone 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 the need to interact with the parent It is important to note that the need to interact with the parent
does not preclude the development of key rollover logic; in does not preclude the development of key rollover logic; in
accordance with the goal of the rollover logic being able to accordance with the goal of the rollover logic, being able to
determine when a state change is "safe", the only effect of being determine when a state change is "safe", the only effect of being
dependent on the parent is that there may be a period of waiting for dependent on the parent is that there may be a period of waiting for
the parent to respond in addition to any delay the key rollover logic the parent to respond in addition to any delay the key rollover logic
requires. Although this introduces additional delays, even with a requires. Although this introduces additional delays, even with a
parent that is less than ideally responsive the only effect will be a parent that is less than ideally responsive, the only effect will be
slowdown in the rollover state transitions. This may cause a policy a slowdown in the rollover state transitions. This may cause a
violation, but will not cause any operational problems. policy violation, but will not cause any operational problems.
Like the ZSK case, there are three methods for rolling a KSK: Like the ZSK case, there are three methods for rolling a KSK:
o Double-KSK: the new KSK is added to the DNSKEY RRset which is then o Double-KSK: the new KSK is added to the DNSKEY RRset, which is
signed with both the old and new key. After waiting for the old then signed with both the old and new key. After waiting for the
RRset to expire from caches, the DS record in the parent zone is old RRset to expire from caches, the DS record in the parent zone
changed. After waiting a further interval for this change to be is changed. After waiting a further interval for this change to
reflected in caches, the old key is removed from the RRset. be reflected in caches, the old key is removed from the RRset.
o Double-DS: the new DS record is published. After waiting for this o Double-DS: the new DS record is published. After waiting for this
change to propagate into caches, the KSK is changed. After a change to propagate into caches, the KSK is changed. After a
further interval during which the old DNSKEY RRset expires from further interval during which the old DNSKEY RRset expires from
caches, the old DS record is removed. caches, the old DS record is removed.
o Double-RRset: the new KSK is added to the DNSKEY RRset which is o Double-RRset: the new KSK is added to the DNSKEY RRset, which is
then signed with both the old and new key, and the new DS record then signed with both the old and new key, and the new DS record
added to the parent zone. After waiting a suitable interval for is added to the parent zone. After waiting a suitable interval
the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY for the old DS and DNSKEY RRsets to expire from caches, the old
and DS record are removed. DNSKEY and DS records are removed.
In essence, Double-KSK means that the new KSK is introduced first and In essence, Double-KSK means that the new KSK is introduced first and
used to sign the DNSKEY RRset. The DS record is changed, and finally used to sign the DNSKEY RRset. The DS record is changed, and finally
the old KSK removed. It limits interactions with the parent to a the old KSK is removed. It limits interactions with the parent to a
minimum but, for the duration of the rollover, the size of the DNSKEY minimum but, for the duration of the rollover, the size of the DNSKEY
RRset is increased. RRset is increased.
With Double-DS, the order of operations is the other way round: With Double-DS, the order of operations is the other way around:
introduce the new DS, change the DNSKEY, then remove the old DS. The introduce the new DS, change the DNSKEY, then remove the old DS. The
size of the DNSKEY RRset is kept to a minimum, but two interactions size of the DNSKEY RRset is kept to a minimum, but two interactions
are required with the parent. are required with the parent.
Finally, Double-RRset is the fastest way to roll the KSK, but has the Finally, Double-RRset is the fastest way to roll the KSK, but has the
drawbacks of both of the other methods: a larger DNSKEY RRset and two drawbacks of both of the other methods: a larger DNSKEY RRset and two
interactions with the parent. interactions with the parent.
3. Key Rollover Timelines 3. Key Rollover Timelines
3.1. Key States 3.1. Key States
DNSSEC validation requires both the DNSKEY and information created DNSSEC validation requires both the DNSKEY and information created
from it (referred to as "associated data" in this section). In the from it (referred to as "associated data" in this section). In the
case of validation of an RR, the data associated with the the key is case of validation of an RR, the data associated with the key is the
the corresponding RRSIG. Where there is a need to validate a chain corresponding RRSIG. Where there is a need to validate a chain of
of trust, the associated data is the DS record. trust, the associated data is the DS record.
During the rolling process, keys move through different states. The During the rolling process, keys move through different states. The
defined states are: defined states are:
Generated Although keys may be created immediately prior to first Generated Although keys may be created immediately prior to first
use, some implementations may find it convenient to use, some implementations may find it convenient to
create a pool of keys in one operation and draw from it create a pool of keys in one operation and draw from it
as required. (Note: such a pre-generated pool must be as required. (Note: such a pre-generated pool must be
secured against surreptitious use.) Keys that have been secured against surreptitious use.) In the timelines
created but not yet used are said to be in the below, before the first event, the keys are considered to
be created but not yet used: they are said to be in the
"Generated" state. "Generated" state.
Published A key enters the published state when either it or its Published A key enters the published state when either it or its
associated data first appears in the appropriate zone. associated data first appears in the appropriate zone.
Ready The DNSKEY or its associated data have been published for Ready The DNSKEY or its associated data have been published for
long enough to guarantee that copies of the key(s) it is long enough to guarantee that copies of the key(s) it is
replacing (or associated data related to that key) have replacing (or associated data related to that key) have
expired from caches. expired from caches.
Active The data is starting to be used for validation. In the Active The data is starting to be used for validation. In the
case of a ZSK, it means that the key is now being be used case of a ZSK, it means that the key is now being used to
to sign RRsets and that both it and the created RRSIGs sign RRsets and that both it and the created RRSIGs
appear in the zone. In the case of a KSK, it means that appear in the zone. In the case of a KSK, it means that
it is possible to use it to validate a DNSKEY RRset as it is possible to use it to validate a DNSKEY RRset as
both the DNSKEY and DS records are present in their both the DNSKEY and DS records are present in their
relevant zones. Note that when this state is entered, it respective zones. Note that when this state is entered,
may not be possible for validating resolvers to use the it may not be possible for validating resolvers to use
data for validation in all cases: the zone signing may the data for validation in all cases: the zone signing
not have finished, or the data might not have reached the may not have finished or the data might not have reached
resolver because of propagation delays and/or caching the resolver because of propagation delays and/or caching
issues. If this is the case, the resolver will have to issues. If this is the case, the resolver will have to
rely on the predecessor data instead. rely on the predecessor data instead.
Retired The data has ceased to be used for validation. In the Retired The data has ceased to be used for validation. In the
case of a ZSK, it means that the key is no longer used to case of a ZSK, it means that the key is no longer used to
sign RRsets. In the case of a KSK, it means that the sign RRsets. In the case of a KSK, it means that the
successor DNSKEY and DS records are in place. In both successor DNSKEY and DS records are in place. In both
cases, the key (and its associated data) can be removed cases, the key (and its associated data) can be removed
as soon as it is safe to do so, i.e. when all validating as soon as it is safe to do so, i.e., when all validating
resolvers are able to use the new key and associated data resolvers are able to use the new key and associated data
to validate the zone. However, until this happens, the to validate the zone. However, until this happens, the
current key and associated data must remain in their current key and associated data must remain in their
respective zones. respective zones.
Dead The key and is associated data are present in their Dead The key and its associated data are present in their
respective zones, but there is no longer information respective zones, but there is no longer information
anywhere that require their presence for use in anywhere that requires their presence for use in
validation. Hence they can be removed at any time. validation. Hence, they can be removed at any time.
Removed Both the DNSKEY and its associated data have been removed Removed Both the DNSKEY and its associated data have been removed
from their respective zones. from their respective zones.
There is one additional state, used where [RFC5011] considerations
are in effect (see Section 3.3.4):
Revoked The DNSKEY is published for a period with the "revoke" Revoked The DNSKEY is published for a period with the "revoke"
bit set as a way of notifying validating resolvers that bit set as a way of notifying validating resolvers that
have configured it as an [RFC5011] trust anchor that it have configured it as a trust anchor, as used in
is about to be removed from the zone. [RFC5011], that it is about to be removed from the zone.
This state is used when [RFC5011] considerations are in
effect (see Section 3.3.4).
3.2. Zone-Signing Key Timelines 3.2. ZSK Rollover Timelines
The following sections describe the rolling of a ZSK. They show the The following sections describe the rolling of a ZSK. They show the
events in the lifetime of a key (referred to as "key N") and cover events in the lifetime of a key (referred to as "key N") and cover
its replacement by its successor (key N+1). its replacement by its successor (key N+1).
3.2.1. Pre-Publication Method 3.2.1. Pre-Publication Method
In this method, the new key is introduced into the DNSKEY RRset. In this method, the new key is introduced into the DNSKEY RRset.
After enough time to ensure that any cached DNSKEY RRsets contain After enough time to ensure that any cached DNSKEY RRsets contain
both keys, the zone is signed using the new key and the old both keys, the zone is signed using the new key and the old
skipping to change at page 10, line 4 skipping to change at page 10, line 22
In this method, the new key is introduced into the DNSKEY RRset. In this method, the new key is introduced into the DNSKEY RRset.
After enough time to ensure that any cached DNSKEY RRsets contain After enough time to ensure that any cached DNSKEY RRsets contain
both keys, the zone is signed using the new key and the old both keys, the zone is signed using the new key and the old
signatures are removed. Finally, when all signatures created with signatures are removed. Finally, when all signatures created with
the old key have expired from caches, the old key is removed. the old key have expired from caches, the old key is removed.
The following diagram shows the timeline of a Pre-Publication The following diagram shows the timeline of a Pre-Publication
rollover. Time increases along the horizontal scale from left to rollover. Time increases along the horizontal scale from left to
right and the vertical lines indicate events in the process. right and the vertical lines indicate events in the process.
Significant times and time intervals are marked. Significant times and time intervals are marked.
|1| |2| |3| |4| |5| |6| |7| |8| |1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | | | | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->| Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | | | | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - - Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | | | | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact Key N+1 Tpub Trdy Tact
---- Time ----> ---- Time ---->
Figure 1: Timeline for a Pre-Publication ZSK rollover. Figure 1: Timeline for a Pre-Publication ZSK Rollover
Event 1: Key N's DNSKEY record is put into the zone, i.e. it is added Event 1: 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 currently active added to the DNSKEY RRset, which is then re-signed with the currently
key-signing keys. The time at which this occurs is the publication active KSKs. The time at which this occurs is the publication time
time (Tpub), and the key is now said to be published. Note that the (Tpub), and the key is now said to be published. Note that the key
key is not yet used to sign records. is not yet used to sign records.
Event 2: Before it can be used, the key must be published for long Event 2: 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 for a change Here, Dprp is the propagation delay -- the time taken for a change
introduced at the master to replicate to all name servers. TTLkey is introduced at the master to replicate to all nameservers. TTLkey is
the time-to-live (TTL) for the DNSKEY records in the zone. The sum the TTL for the DNSKEY records in the zone. The sum is therefore the
is therefore the maximum time taken for existing DNSKEY records to maximum time taken for existing DNSKEY records to expire from caches,
expire from caches, regardless of the nameserver from which they were regardless of the nameserver from which they were retrieved.
retrieved.
(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 key N's to sign records. The time at which this event occurs is key N's
ready time (Trdy), which is given by: ready time (Trdy), which is given by:
Trdy(N) = Tpub(N) + Ipub Trdy(N) = Tpub(N) + Ipub
Event 3: At some later time, the key starts being used to sign Event 3: At some later time, the key starts being used to sign
RRsets. This point is the activation time (Tact) and after this, key RRsets. This point is the activation time (Tact) and after this, key
N is said to be active. N is said to be active.
Tact(N) >= Trdy(N) Tact(N) >= Trdy(N)
Event 4: At some point thought must be given to its successor (key Event 4: 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. The publication time of key N+1 depends on before it is activated. The publication time of key N+1 depends on
the activation time of key N: the activation time of key N:
Tpub(N+1) <= Tact(N) + Lzsk - Ipub Tpub(N+1) <= Tact(N) + 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 in the diagrams the actual ZSK lifetime). It should be noted that in the diagrams, the actual
key lifetime is represented; this may differ slightly from the key lifetime is represented; this may differ slightly from the
intended lifetime set by key management policy. intended lifetime set by key management policy.
Event 5: While key N is still active, its successor becomes ready. Event 5: 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 6: When key N has been in use for an interval equal to the ZSK Event 6: When key N has been in use for an interval equal to the ZSK
lifetime, it is retired (i.e. it will never again be used to generate lifetime, it is retired (i.e., it will never again be used to
new signatures) and key N+1 activated and used to sign the zone. generate new signatures) and key N+1 activated and used to sign the
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(N) = Tact(N) + Lzsk Tret(N) = Tact(N) + Lzsk
It is also the activation time of the successor key N+1. Note that It is also the activation time of the successor key N+1. Note that
operational considerations may cause key N to remain in use for a operational considerations may cause key N to remain in use for a
longer (or shorter) time than the lifetime set by the key management longer (or shorter) time than the lifetime set by the key management
policy. policy.
Event 7: The retired key needs to be retained in the zone whilst any Event 7: 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 old RRSIG record in the cache, but the old DNSKEY RRset has have an old RRSIG record in the cache, but the old DNSKEY RRset has
expired when it is asked to provide both to a client. In this case expired 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 the 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 once 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: in 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 the propagation delay, required re-signed with the new key. Dprp is the propagation delay, required
to guarantee that the updated zone information has reached all slave to guarantee that the updated zone information has reached all slave
servers, and TTLsig is the maximum TTL of all the RRSIG records in servers, and TTLsig is the maximum TTL of all the RRSIG records in
the zone created with the retiring key. the zone created with the retiring key.
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(N) = Tret(N) + Iret Tdea(N) = Tret(N) + Iret
... at which point the key is said to be dead. ... at which point the key is said to be dead.
Event 8: At any time after the key becomes dead, it can be removed Event 8: At any time after the key becomes dead, it can be removed
from the zone's DNSKEY RRset, which must then be re-signed with the from the zone's DNSKEY RRset, which must then be re-signed with the
current key-signing key. This time is the removal time (Trem), given current KSK. This time is the removal time (Trem), given by:
by:
Trem(N) >= Tdea(N) Trem(N) >= Tdea(N)
... 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
In this rollover, a new key is introduced and used to sign the zone; In this rollover, a new key is introduced and used to sign the zone;
the old key and signatures are retained. Once all cached DNSKEY the old key and signatures are retained. Once all cached DNSKEY and/
and/or RRSIG information contains copies of the new DNSKEY and RRSIGs or RRSIG information contains copies of the new DNSKEY and RRSIGs
created with it, the old DNSKEY and RRSIGs can be removed from the created with it, the old DNSKEY and RRSIGs can be removed from the
zone. zone.
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| |1| |2| |3| |4|
| | | | | | | |
Key N |<-------Lzsk----------->|<--->| Key N |<-------Lzsk----------->|<--->|
| | | | | | | |
| |<--Iret-->| | | |<--Iret-->| |
| | | | | | | |
Key N+1 | |<----Lzsk------- - - Key N+1 | |<----Lzsk------- - -
| | | | | | | |
Key N Tact Tdea Trem Key N Tact Tdea Trem
Key N+1 Tact Key N+1 Tact
---- 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 added to the DNSKEY RRset and is then used to sign Event 1: Key N is added to the DNSKEY RRset and is then used to sign
the zone; existing signatures in the zone are not removed. The key the zone; existing signatures in the zone are not removed. The key
is published and active: this is key N's activation time (Tact), is published and active: this is key N's activation time (Tact),
after which the key is said to be active. after which the key is said to be active.
Event 2: As the current key (key N) approaches the end of its actual Event 2: As the current key (key N) approaches the end of its actual
lifetime (Lzsk), the successor key (key N+1) is introduced into the lifetime (Lzsk), the successor key (key N+1) is introduced into the
zone and starts being used to sign RRsets: neither the current key zone and starts being used to sign RRsets: neither the current key
nor the signatures created with it are removed. The successor key is nor the signatures created with it are removed. The successor key is
now also active. now also active.
Tact(N+1) = Tact(N) + Lzsk - Iret Tact(N+1) = Tact(N) + Lzsk - Iret
Event 3: Before key N can be withdrawn from the zone, all RRsets that Event 3: 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 and Dprp is the propagation RRsets have been signed with the new key and Dprp is the propagation
delay, required to guarantee that the updated zone information has delay, required to guarantee that the updated zone information has
reached all slave servers. The final term (the maximum of TTLkey and reached all slave servers. The final term (the maximum of TTLkey and
TTLsig) is the period to wait for key and signature data associated TTLsig) is the period to wait for key and signature data associated
with key N to expire from caches. (TTLkey is the TTL of the DNSKEY with key N to expire from caches. (TTLkey is the TTL of the DNSKEY
RRset and TTLsig is the maximum TTL of all the RRSIG records in the RRset and TTLsig is the maximum TTL of all the RRSIG records in the
zone created with the ZSK. The two may be different: although the zone created with the ZSK. The two may be different: although the
TTL of an RRSIG is equal to the TTL of the RRs in the associated TTL of 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 RRset [RFC4034], the DNSKEY RRset only needs to be signed with the
KSK.) 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(N) = Tact(N+1) + Iret Tdea(N) = Tact(N+1) + Iret
Event 4: At some later time key N and the signatures generated with Event 4: At some later time, key N and the signatures generated with
it can be removed from the zone. This is the removal time (Trem), it can be removed from the zone. This is the removal time (Trem),
given by: given by:
Trem(N) >= Tdea(N) Trem(N) >= Tdea(N)
3.3. Key-Signing Key Rollover Timelines 3.3. KSK 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). (The case of introducing the replacement by its successor (key N+1). (The case of introducing the
first KSK into the zone is discussed in Section 3.3.5.) first KSK into the zone is discussed in Section 3.3.5.)
3.3.1. Double-KSK Method 3.3.1. Double-KSK Method
In this rollover, The new DNSKEY is added to the zone. After an In this rollover, the new DNSKEY is added to the zone. After an
interval long enough to guarantee that any cached DNSKEY RRsets interval long enough to guarantee that any cached DNSKEY RRsets
contain the new DNSKEY, the DS record in the parent zone is changed. contain the new DNSKEY, the DS record in the parent zone is changed.
After a further interval to allow the old DS record to expire from After a further interval to allow the old DS record to expire from
caches, the old DNSKEY is removed from the zone. caches, the old DNSKEY is removed from the zone.
The timeline for a Double-KSK rollover is shown below. The diagram The timeline for a Double-KSK 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| |1| |2| |3| |4|
| | | | | | | |
skipping to change at page 14, line 45 skipping to change at page 15, line 27
|5| |6| |7| |8| |9| |10| |5| |6| |7| |8| |9| |10|
| | | | | | | | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->| Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | | | | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - - Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | | | | | | | |
Key N Tret Tdea Trem Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact Key N+1 Tpub Trdy Tsbm Tact
---- Time (cont) ----> ---- Time (cont.) ---->
Figure 3: Timeline for a Double-KSK rollover. Figure 3: Timeline for a Double-KSK Rollover
Event 1: Key N is introduced into the zone; it is added to the DNSKEY Event 1: Key N is introduced into the zone; it is added to the DNSKEY
RRset, which is then signed by all currently active KSKs. (So at RRset, which is then signed by all currently active KSKs. (So at
this point, the DNSKEY RRset is signed by both key N and its 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 of key N (Tpub); after this the well.) This is the publication time of key N (Tpub); after this, the
key is said to be published. key is said to be published.
Event 2: Before it can be used, the key must be published for long Event 2: 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 in the child zone (IpubC) The interval is the publication interval in the child zone (IpubC)
and is given by: and is given by:
IpubC = DprpC + TTLkey IpubC = 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 N's ready time, RRset. The time at which this occurs is the key N's ready time,
Trdy, given by: Trdy, given by:
Trdy(N) = Tpub(N) + IpubC Trdy(N) = Tpub(N) + IpubC
Event 3: At some later time, the DS record corresponding to the new Event 3: 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, Tsbm: the submission time, Tsbm:
Tsbm(N) >= Trdy(N) Tsbm(N) >= Trdy(N)
Event 4: The DS record is published in the parent zone. As this is Event 4: 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 key N (Tact): rollover methods, this is called the activation time of key N (Tact):
Tact(N) = Tsbm(N) + Dreg Tact(N) = Tsbm(N) + 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 submitted to the parent zone manager for it to be record has been submitted to 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 organizational overhead of
transferring a record. In practice, Dreg will not be a fixed time: transferring a record. In practice, Dreg will not be a fixed time:
instead, the end of Dreg will be signalled by the appearance of the instead, the end of Dreg will be signaled by the appearance of the DS
DS record in the parent zone.) record in the parent zone.)
Event 5: While key N is active, thought needs to be given to its Event 5: 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 all KSKs.) before, this means that the DNSKEY RRset is signed by all KSKs.)
This time is the publication time of the successor key N+1, given by: This time is the publication time of the successor key N+1, given by:
Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC
... where Lksk is the actual lifetime of the KSK, and Dreg the ... where Lksk is the actual lifetime of the KSK, and Dreg the
registration delay. registration delay.
Event 6: After an interval IpubC, key N+1 becomes ready (in that all Event 6: After an interval IpubC, 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 key N+1 (Trdy). This time is the ready time of the successor key N+1 (Trdy).
Event 7: At the submission time of the successor key N+1, Tsbm(N+1), Event 7: At the submission time of the successor key N+1, Tsbm(N+1),
the DS record corresponding to key N+1 is submitted to the parent the DS record corresponding to key N+1 is submitted to the parent
zone. zone.
Event 8: The successor DS record is published in the parent zone and Event 8: The successor DS record is published in the parent zone and
the current DS record withdrawn. Key N is said to be retired and the the current DS record withdrawn. Key N is said to be retired and the
time at which this occurs is Tret(N), given by: time at which this occurs is Tret(N), given by:
Tret(N) = Tsbm(N+1) + Dreg Tret(N) = Tsbm(N+1) + Dreg
Event 9: Key N must remain in the zone until any caches that contain Event 9: 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, it is said to be dead. As the key is no longer used for anything, it is said to be dead.
This point is the dead time (Tdea), given by: This point is the dead time (Tdea), given by:
Tdea(N) = Tret(N) + Iret Tdea(N) = Tret(N) + Iret
Event 10: At some later time, key N is removed from the zone's DNSKEY Event 10: At some later time, key N is removed from the zone's DNSKEY
RRset (at the 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(N) >= Tdea(N) Trem(N) >= Tdea(N)
3.3.2. Double-DS Method 3.3.2. Double-DS Method
In this rollover, the new DS record is published in the parent zone. In this rollover, the new DS record is published in the parent zone.
When any caches that contain the DS RRset contain a copy of the new When any caches that contain the DS RRset contain a copy of the new
record, the KSK in the zone is changed. After a further interval for record, the KSK in the zone is changed. After a further interval for
the old DNSKEY RRset to expire from caches, the old DS record is the old DNSKEY RRset to expire from caches, the old DS record is
removed from the parent. removed from the parent.
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| |1| |2| |3| |4| |5|
| | | | | | | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk----- - - Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk---- - -
| | | | | | | | | |
Key N+1 | | | | |<--Dreg-- - - Key N+1 | | | | |<--Dreg-- - -
| | | | | | | | | |
Key N Tsbm Tpub Trdy Tact Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm Key N+1 Tsbm
---- Time ----> ---- Time ---->
(continued ...) (continued ...)
|6| |7| |8| |9| |10| |6| |7| |8| |9| |10|
| | | | | | | | | |
Key N - - -----Lksk--------->|<-Iret->|<---->| Key N - ----------Lksk--------->|<-Iret->|<---->|
| | | | | | | | | |
Key N+1 - - --Dreg-->|<-IpubP->|<------>|<------Lksk------ - - Key N+1 - --Dreg-->|<-IpubP->|<-->|<---Lksk------- - -
| | | | | | | | | |
Key N Tret Tdea Trem Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact Key N+1 Tpub Trdy Tact
---- Time ----> ---- Time ---->
Figure 4: Timeline for a Double-DS KSK rollover. Figure 4: Timeline for a Double-DS KSK Rollover
Event 1: The DS RR is submitted to the parent zone for publication. Event 1: The DS RR is submitted to the parent zone for publication.
This time is the submission time, Tsbm. This time is the submission time, Tsbm.
Event 2: After the registration delay, Dreg, the DS record is Event 2: After the registration delay, Dreg, the DS record is
published in the parent zone. This is the publication time (Tpub) of published in the parent zone. This is the publication time (Tpub) of
key N, given by: key N, given by:
Tpub(N) = Tsbm(N) + Dreg Tpub(N) = Tsbm(N) + Dreg
As before, in practice Dreg will not be a fixed time. Instead, the As before, in practice, Dreg will not be a fixed time. Instead, the
end of Dreg will be signalled by the appearance of the DS record in end of Dreg will be signaled by the appearance of the DS record in
the parent zone. the parent zone.
Event 3: At some later time, any cache that has a copy of the DS Event 3: 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,
N, if introduced into the DNSKEY RRset, could be used to validate the key N, if introduced into the DNSKEY RRset, could be used to validate
zone. For this reason, this time is known as the ready time, Trdy, the zone. For this reason, this time is known as the ready time,
and is given by: Trdy, and is given by:
Trdy(N) = Tpub(N) + IpubP Trdy(N) = Tpub(N) + IpubP
IpubP is the publication interval of the DS record (in the parent IpubP is the publication interval of the DS record (in the parent
zone) and is given by the expression: zone) and is given by the 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 4: At some later time, the key rollover takes place and the new Event 4: At some later time, the key rollover takes place and the new
key (key N) is introduced into the DNSKEY RRset and used to sign it. key (key N) is introduced into the DNSKEY RRset and used to sign it.
This time is key N's activation time (Tact) and at this point key N This time is key N's activation time (Tact) and at this point key N
is said to be active: is said to be active:
Tact(N) >= Trdy(N) Tact(N) >= Trdy(N)
Event 5: At some point thought must be given to key replacement. The Event 5: At some point, thought must be given to key replacement.
DS record for the successor key must be submitted to the parent zone The DS record for the successor key must be submitted to the parent
at a time such that when the current key is withdrawn, any cache that zone at a time such that when the current key is withdrawn, any cache
contains the zone's DS records has data about the DS record of the that contains the zone's DS records has data about the DS record of
successor key. The time at which this occurs is the submission time the successor key. The time at which this occurs is the submission
of the successor key N+1, given by: time of the successor key N+1, given by:
Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg
... where Lksk is the actual lifetime of key N (which may differ ... where Lksk is the actual lifetime of key N (which may differ
slightly from the lifetime set in the key management policy) and Dreg slightly from the lifetime set in the key management policy) and Dreg
is the registration delay. is the registration delay.
Event 6. After an interval Dreg, the successor DS record is Event 6. After an interval Dreg, the successor DS record is
published in the zone. published in the zone.
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. its DS record is now in caches that contain the parent DS RRset.
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
replaced in the DNSKEY RRset by key N+1; the RRset is then signed replaced in the DNSKEY RRset by key N+1; the RRset is then signed
with the new key. At this point, as both the old and new DS records with the new key. At this point, as both the old and new DS records
have been in the parent zone long enough to ensure that they are in have been in the parent zone long enough to ensure that they are in
caches that contain the DS RRset, the zone can be authenticated caches that contain the DS RRset, the zone can be authenticated
throughout the rollover. A validating resolver can authenticate throughout the rollover. A validating resolver can authenticate
either the old or new KSK. either the old or new KSK.
This time is the retire time (Tret) of key N, given by: This time is the retire time (Tret) of key N, given by:
Tret(N) = Tact(N) + Lksk Tret(N) = Tact(N) + Lksk
This is also the activation time of the successor key N+1. This is also the activation time of the successor key N+1.
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(N) = Tret(N) + Iret Tdea(N) = Tret(N) + Iret
... where Iret is the retire interval of the key, given by: ... where Iret is the retire interval of the key, 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(N) >= Tdea(N) Trem(N) >= Tdea(N)
3.3.3. Double-RRset Method 3.3.3. Double-RRset Method
In the Double-RRset rollover, the new DNSKEY and DS records are In the Double-RRset rollover, the new DNSKEY and DS records are
published simultaneously in the appropriate zones. Once enough time published simultaneously in the appropriate zones. Once enough time
has elapsed for the old DNSKEY and DS RRsets to expire from caches, has elapsed for the old DNSKEY and DS RRsets to expire from caches,
the old DNSKEY and DS records are removed from their respective the old DNSKEY and DS records are removed from their respective
zones. zones.
The timeline for this rollover is shown below. The diagram follows The timeline for this rollover is shown below. The diagram follows
the convention described in Section 3.2.1 the convention described in Section 3.2.1.
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Ipub->|<-----Lksk----->|<------>|
| | | | |
Key N+1 | | |<-Ipub->|<------Lksk--- - -
| | | | |
Key N Tpub Tact Tret Trem
Key N+1 Tpub Tact
---- Time ----> |1| |2| |3| |4| |5|
| | | | |
Key N |<-----------Lksk---------->|<---->|
| | | | |
| |<------Ipub----->| |
| | | | |
| |<-Dreg->|<-Iret->| |
| | | | |
Key N+1 | | |<----Lksk-------- - -
| | | | |
Key N Tact Tret Tdea Trem
Key N+1 Tpub Tact
Figure 5: Timeline for a Double-RRset KSK rollover. ---- Time ---->
Event 1: The key is added to and used for signing the DNSKEY RRset Figure 5: Timeline for a Double-RRset KSK Rollover
and is thereby published in the zone. At the same time the
corresponding DS record is submitted to the parent zone for
publication. This time is the publish time for key N (Tpub) and the
key is said to be published.
Event 2: At some later time, the DS record is published in the parent Event 1: The DS and DNSKEY records have appeared in their respective
zone and at some time after that, the updated information has reached zones and the latter has been used to sign the DNSKEY RRset. The key
all caches: any cache that holds a DNSKEY RRset from the child zone is published and active: this is key N's activation time (Tact).
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
record.
The time at which this occurs is called the activation time of key N Event 2: As the current key (key N) approaches the end of its actual
(Tact), given by: lifetime (Lksk), the successor key (key N+1) is introduced into the
zone and is used to sign the DNSKEY RRset. At the same time, the
successor DS record is submitted to the parent zone. This is the
publication time of the successor key (Tpub):
Tact(N) = Tpub(N) + Ipub Tpub(N+1) <= Tact(N) + Lksk - Ipub
... where Ipub is the composite publication interval for the DNSKEY ... where Ipub is defined below.
and DS records, given by:
Ipub = max(IpubP, IpubC), Event 3: After the registration delay (Dreg), the DS record appears
in the parent zone. The DNSKEY record is already in the child zone,
so with both the new key and its associated data now visible, this is
the key's activation time (Tact) and the key is now said to be
active.
IpubP being the publication interval of the DS record in the parent Tact(N+1) = Tpub(N+1) + Dreg
zone and IpubC the publication interval of the DNSKEY in the child
zone. The parent zone's publication interval is given by:
IpubP = Dreg + DprpP + TTLds Event 4: Before key N and its associated data can be withdrawn, all
RRsets in the caches of validating resolvers must contain the new DS
and/or DNSKEY. The time at which this occurs is the dead time of key
N (Tdea), given by:
where Dreg is the registration delay, the time taken for the DS Tdea(N) = Tpub(N+1) + Ipub
record to be published in the parent zone. DprpP is the parent
zone's propagation delay and TTLds is the TTL of the DS record in
that zone.
The child zone's publication interval is given by a similar equation: Ipub is the time it takes to guarantee that any prior cached
information about the DNSKEY and the DS RRsets have expired. For the
DNSKEY, this is the publication interval of the child (IpubC). For
the DS, the publication interval (IpubP) starts once the record
appears in the parent zone, which is Dreg after it has been
submitted. Hence:
IpubC = DprpC + TTLkey Ipub = max(Dreg + IpubP, IpubC)
... where DprpC is the propagation delay in the child zone and TTLkey The parent zone's publication interval is given by:
the TTL of a DNSKEY record.
Event 3: At some point we need to give thought to key replacement. IpubP = DprpP + TTLds
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
active when the current key has been active for its actual lifetime,
Lksk. This is the publication time (Tpub) of the successor key, and
is given by:
Tpub(N+1) <= Tact(N) + Lksk - Ipub where DprpP is the parent zone's propagation delay and TTLds is the
TTL of the DS record in that zone.
... where Lksk is the actual lifetime of the KSK and Ipub is as The child zone's publication interval is given by a similar equation:
defined above.
Event 4: Key N+1's DNSKEY and DS records are now in caches that IpubC = DprpC + TTLkey
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
time (Tact) of the successor key N+1 and by analogy with other
rollover methods, it is also the dead time of key N:
Tdea(N) = Tact(N) + Lksk where DprpC is the propagation delay in the child zone and TTLkey the
TTL of a DNSKEY record.
In analogy with other rollovers, we can also define a retire interval
-- the interval between a key becoming active and the time at which
its predecessor is considered dead. In this case, Iret is given by:
Iret = Ipub - Dreg
In other words, the retire interval of the predecessor key is the
greater of the publication interval of the parent, or the publication
interval of the child minus the registration delay.
Event 5: At some later time, the key N's DS and DNSKEY records are Event 5: 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(N) >= Tdea(N) Trem(N) >= Tdea(N)
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
where the trust anchor is a DS record in the parent zone, zone KSKs, 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
validating resolvers may have configured trust anchors directly. validating resolvers may have configured trust anchors directly.
Rolling a configured trust anchor is dealt with in [RFC5011]. It Rolling a configured trust anchor is dealt with in [RFC5011]. It
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 expression for the publication When the new key is introduced, the expression for the publication
interval of the DNSKEY(IpubC) in the Double-KSK and Double-RRset interval of the DNSKEY (IpubC) in the Double-KSK and Double-RRset
methods is modified to: methods is modified to:
IpubC >= DprpC + max(Itrp, TTLkey) IpubC >= DprpC + max(Itrp, TTLkey)
... where the right hand side of the expression now includes the ... where the right-hand side of the expression now includes the
"trust point" interval. This term is the interval required to "trust point" interval. This term is the interval required to
guarantee that a resolver configured for the automatic update of keys guarantee that a resolver configured for the automatic update of keys
from a particular trust point will see at least two validated DNSKEY according to [RFC5011] will accept the new key as a new trust point.
RRsets containing the new key (a requirement from [RFC5011], section That interval is given by:
2.4.1). It is defined by the expression:
Itrp >= (2 * queryInterval) + (n * retryTime) Itrp >= queryInterval + AddHoldDownTime + queryInterval
... where queryInterval and retryTime are as defined in section 2.3 ... where queryInterval is as defined in Section 2.3 of [RFC5011] and
of [RFC5011]. "n" is the total number of retries needed by the AddHoldDownTime is the Add Hold-Down Time defined in Section 2.4.1 of
resolver during the two attempts to get the DNSKEY RRset. the same document.
The first term of the expression (2 * queryInterval) represents the The first term of the expression (queryInterval) represents the time
time to obtain two validated DNSKEY RRsets. The second term (n * after which all validating resolvers can be guaranteed to have
retryTime) is a safety margin, with the value of "n" reflecting the obtained a copy of the DNSKEY RRset containing the new key. Once
degree of confidence in the communication between a resolver and the retrieved, a validating resolver needs to wait for AddHoldDownTime.
trust point. Providing it does not see a validly signed DNSKEY RRset without the
new key in that period, it will treat it as a trust anchor the next
time it retrieves the RRset, a process that can take up to another
queryInterval (the third term).
However, the expression for queryInterval given in [RFC5011] contains
the DNSKEY's RRSIG expiration interval, a parameter that only the
validating resolver can really calculate. In practice, a modified
query interval that depends only on TTLkey can be used:
modifiedQueryInterval = MAX(1hr, MIN(15 days, TTLkey / 2))
(This is obtained by taking the expression for queryInterval in
[RFC5011] and assuming a worst case for RRsigExpirationInterval. It
is greater than or equal to queryInterval for all values of the
expiration time.) The expression above then becomes (after
collecting terms):
Itrp >= AddHoldDownTime + 2 * modifiedQueryInterval
In the Double-DS method, instead of swapping the KSK RRs in a single 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 step, there must now be a period of overlap. In other words, the new
KSK must be introduced into the zone at least: KSK must be introduced into the zone at least:
DprpC + max(Itrp, TTLkey) 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 in the published DNSKEY RR, and the DNSKEY RRset re-signed bit is set in the published DNSKEY RR, and the DNSKEY RRset re-signed
with the current and revoked keys. The key is maintained in this with the current and revoked keys. The key is maintained in this
state for the "revoke" interval, Irev, given by: state for the revoke interval, Irev, given by:
Irev >= 30 days Irev >= DprpC + modifiedQueryInterval
... 30 days being the [RFC5011] remove hold-down time. After this As before, DprpC is the time taken for the revoked DNSKEY to
time, the key is dead and can be removed from the zone. propagate to all slave zones, and modifiedQueryInterval is the time
after which it can be guaranteed that all validating resolvers that
adhere to RFC 5011 have retrieved a copy of the DNSKEY RRset
containing the revoked key.
After this time, the key is dead and can be removed from the zone.
3.3.5. Introduction of First Keys 3.3.5. Introduction of First Keys
There are no timing considerations associated with the introduction There are no timing considerations associated with the introduction
of the first keys into a zone other that they must be introduced and of the first keys into a zone other that they must be introduced and
the zone validly signed before a chain of trust to the zone is the zone validly signed before a chain of trust to the zone is
created. created.
This is important: in the case of a secure parent, it means ensuring In the case of a secure parent, it means ensuring that the DS record
that the DS record is not published in the parent zone until there is is not published in the parent zone until there is no possibility
no possibility that a validating resolver can obtain the record yet that a validating resolver can obtain the record yet is not able to
is not able to obtain the corresponding DNSKEY. In the case of an obtain the corresponding DNSKEY. In the case of an insecure parent,
insecure parent, i.e. the initial creation of a new security apex, it i.e., the initial creation of a chain of trust or "security apex", it
is not possible to guarantee this. It is up to the operator of the is not possible to guarantee this. It is up to the operator of the
validating resolver to wait for the new KSK to appear at all servers validating resolver to wait for the new KSK to appear at all servers
for the zone before configuring the trust anchor. 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
signed with a new key as soon as possible. As a key must be in the re-signed with a new key as soon as possible. As a key must be in
ready state to sign the zone, having at least one additional key (a the ready state to sign the zone, having at least one additional key
standby key) in this state at all times will minimise delay. (a standby key) in this state at all times will minimize 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 the 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
Signature and Double-RRSIG methods, it would require pre-publication Double-Signature and Double-RRSIG methods, it would require
of the signatures. Essentially, the standby key would be permanently pre-publication of the signatures. Essentially, the standby key
active, as it would have to be periodically used to renew signatures. would be permanently active, as it would have to be periodically used
Zones would also permanently require two sets of signatures.) to renew signatures. Zones would also permanently require two sets
of signatures.)
It is also possible to have a standby KSK. The Double-KSK method It is also possible to have a standby KSK. The Double-KSK method
requires that the standby KSK be included in the DNSKEY RRset; requires that the standby KSK be included in the DNSKEY RRset;
rolling the key then requires just the introduction of the DS record rolling the key then requires just the introduction of the DS record
in the parent. Note that the standby KSK should also be used to sign in the parent. Note that the standby KSK should also be used to sign
the DNSKEY RRset. As the RRset and its signatures travel together, the DNSKEY RRset. As the RRset and its signatures travel together,
merely adding the KSK without using it to sign the DNSKEY RRset does merely adding the KSK without using it to sign the DNSKEY RRset does
not provide the desired time saving: for a KSK to be used in a not provide the desired time saving: for a KSK to be used in a
rollover the DNSKEY RRset must be signed with it, and this would rollover, the DNSKEY RRset must be signed with it, and this would
introduce a delay while the old RRset (not signed with the new key) introduce a delay while the old RRset (not signed with the new key)
expires from caches. expires from caches.
The idea of a standby KSK in the Double-RRset rollover method The idea of a standby KSK in the Double-RRset rollover method
effectively means having two active keys (as the standby KSK and effectively means having two active keys (as the standby KSK and
associated DS record would both be published at the same time in associated DS record would both be published at the same time in
their respective zones). their respective zones).
Finally, in the Double-DS method of rolling a KSK, it is not a Finally, in the Double-DS method of rolling a KSK, it is not a
standby key that is present, it is a standby DS record in the parent standby key that is present, it is a standby DS record in the parent
zone. zone.
Whatever algorithm is used, the standby item of data can be included Whatever algorithm is used, the standby item of data can be included
in the zone on a permanent basis, or be a successor introduced as in the zone on a permanent basis, or be a successor introduced as
early as possible. early as possible.
5. Algorithm Considerations 5. Algorithm Considerations
The preceding sections have implicitly assumed that all keys and The preceding sections have implicitly assumed that all keys and
signatures are created using a single algorithm. However, [RFC4035] signatures are created using a single algorithm. However,
(section 2.2) requires that there be an RRSIG for each RRset using at Section 2.2 of [RFC4035] requires that there be an RRSIG for each
least one DNSKEY of each algorithm in the zone apex DNSKEY RRset. RRset using at least one DNSKEY of each algorithm in the zone apex
DNSKEY RRset.
Except in the case of an algorithm rollover - where the algorithms Except in the case of an algorithm rollover -- where the algorithms
used to create the signatures are being changed - there is no used to create the signatures are being changed -- there is no
relationship between the keys of different algorithms. This means relationship between the keys of different algorithms. This means
that they can be rolled independently of one another. In other that they can be rolled independently of one another. In other
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. Summary 6. Summary
For ZSKs, "Pre-Publication" is generally considered to be the For ZSKs, the Pre-Publication method is generally considered to be
preferred way of rolling keys. As shown in this document, the time the preferred way of rolling keys. As shown in this document, the
taken to roll is wholly dependent on parameters under the control of time taken to roll is wholly dependent on parameters under the
the zone manager. control of the zone manager.
In contrast, "Double-RRset" is the most efficient method for KSK In contrast, the Double-RRset method is the most efficient 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
propagate in parallel. The time taken to roll KSKs may depend on propagate in parallel. The time taken to roll KSKs may depend on
factors related to the parent zone if the parent is signed. For factors related to the parent zone if the parent is signed. For
zones that intend to comply with the recommendations of [RFC5011], in zones that intend to comply with the recommendations of [RFC5011], in
virtually all cases the rollover time will be determined by the many cases, the rollover time will be determined by the times defined
RFC5011 "add hold-down" and "remove hold-down" times. It should be by RFC 5011. It should be emphasized that this delay is a policy
emphasized that this delay is a policy choice and not a function of choice and not a function of timing values and that it also requires
timing values and that it also requires changes to the rollover changes to the rollover process due to the need to manage revocation
process due to the need to manage revocation of trust anchors. of trust anchors.
Finally, the treatment of emergency key rollover is significantly Finally, the treatment of emergency key rollover is significantly
simplified by the introduction of standby keys as standard practice simplified by the introduction of standby keys as standard practice
during all types of rollovers. during all types of rollovers.
7. IANA Considerations 7. Security Considerations
This memo includes no request to IANA.
8. 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].
9. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy
Arends and Wouter Wijngaards.
10. Normative References 8. Normative References
[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, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[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, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[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, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, September 2007. Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, Operational Practices, Version 2", RFC 6781,
December 2012. DOI 10.17487/RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>.
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: <TYPE><id><ZONE>
<TYPE><id><ZONE>
where: where:
<TYPE> is an upper-case character indicating what type the symbol is. <TYPE> is an uppercase character indicating what type the symbol is.
Defined types are: Defined types are:
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, T and TTL are self-explanatory. Like I, both D and L are time I, 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, a "D"
if the events are defined in terms of the interval, e.g., the dead interval (delay) is a feature of the process, probably outside
time occurs "retire interval" after the retire time), D and L are control of the zone manager, and an "L" interval (lifetime) is chosen
fixed intervals: a "D" interval (delay) is a feature of the process, by the zone manager and is a feature of policy.
probably outside control of the zone manager, whereas an "L" interval
(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 lowercase 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
<ZONE> is an optional capital letter that distinguishes between the <ZONE> is an optional uppercase letter that distinguishes between the
same variable applied to different zones and is one of: same variable applied to different zones and is one of:
C child C child
P parent P parent
Within the rollover descriptions, times may be suffixed by a number Within the rollover descriptions, times may have a number in
in brackets indicating the instance of the key to which they apply, parentheses affixed to their end indicating the instance of the key
e.g. Tact(N) is the activation time of key N, Tpub(N+1) the to which they apply, e.g., Tact(N) is the activation time of key N,
publication time of key N+1 etc. Tpub(N+1) the publication time of key N+1 etc.
The list of variables used in the text given below. The list of variables used in the text given below.
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.
DprpC Propagation delay in the child zone. DprpC Propagation delay in the child zone.
DprpP Propagation delay in the parent zone. DprpP Propagation delay in the parent zone.
Dreg Registration delay: the time taken for a DS record Dreg Registration delay: the time taken for a DS record
submitted to a parent zone to appear in it. As a parent submitted to a parent zone to appear in it. As a parent
zone is often managed by a different organisation to that zone is often managed by a different organization than that
managing the child zone, the delays associated with passing managing the child zone, the delays associated with passing
data between organisations is captured by this term. data between organizations is captured by this term.
Dsgn Signing delay. After the introduction of a new ZSK, the Dsgn Signing delay. After the introduction of a new ZSK, the
amount of time taken for all the RRs in the zone to be amount of time taken for all the RRs in the zone to be
signed with it. signed with it.
Ipub Publication interval. The amount of time that must elapse Ipub Publication interval. The amount of time that must elapse
after the publication of a DNSKEY and/or its associated after the publication of a DNSKEY and/or its associated
data before it can be assumed that any resolvers that have data before it can be assumed that any resolvers that have
the relevant RRset cached have a copy of the new the relevant RRset cached have a copy of the new
information. information.
IpubC Publication interval in the child zone. IpubC Publication interval in the child zone.
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 DNSKEY or associated data enters the retire state for any a DNSKEY or associated data enters the retire state for any
dependent information (e.g. RRSIG for a ZSK) to be purged dependent information (e.g., RRSIG for a ZSK) to be purged
from validating resolver caches. 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
considerations. considerations of [RFC5011].
Itrp Trust-point interval. The amount of time that a trust Itrp Trust-point interval. The amount of time that a trust
anchor must be published for to guarantee that a resolver anchor must be published for in order to guarantee that a
configured for an automatic update of keys will see the new resolver configured for an automatic update of keys will
key at least twice. see the new key at least twice.
Lksk Lifetime of a key-signing key. This is the actual amount
of time for which this particular KSK is regarded as the
active KSK. Depending on when the key is rolled-over, the
actual lifetime may be longer or shorter than the intended
key lifetime indicated by management policy.
Lzsk Lifetime of a zone-signing key. This is the actual amount Lksk Lifetime of a KSK. This is the actual amount of time for
of time for which the ZSK is used to sign the zone. which this particular KSK is regarded as the active KSK.
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 the intended key lifetime may be longer or shorter than the intended key
lifetime indicated by management policy. lifetime indicated by management policy.
Lzsk Lifetime of a ZSK. This is the actual amount of time for
which the ZSK is used to sign the zone. Depending on when
the key is rolled over, the actual lifetime may be longer
or shorter than the intended key lifetime indicated by
management policy.
Tact Activation time. The time at which the key is regarded as Tact Activation time. The time at which the key is regarded as
the principal key for the zone. the principal key for the zone.
Tdea Dead time. The time at which any information held in Tdea Dead time. The time at which any information held in
validating resolver caches is guaranteed to contain validating resolver caches is guaranteed to contain
information related to the successor key. At this point, information related to the successor key. At this point,
the current key and its associated information are not the current key and its associated information are not
longed required for validation purposes. longed required for validation purposes.
Tpub Publication time. The time that the key or associated data Tpub Publication time. The time that the key or associated data
skipping to change at page 28, line 47 skipping to change at page 31, line 5
TTLds Time to live of a DS record. TTLds Time to live of a DS record.
TTLkey Time to live of a DNSKEY record. (By implication, this is TTLkey Time to live of a DNSKEY record. (By implication, this is
also the time to live of the signatures on the DNSKEY also the time to live of the signatures on the DNSKEY
RRset.) 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) Acknowledgements
o draft-ietf-dnsop-dnssec-key-timing-06
* Clarifications to various text, as identified in WGLC.
* Moved "Limitiation of Scope" section to be a subsection of
section 1.
o draft-ietf-dnsop-dnssec-key-timing-05
* Some more renamings of "Double-Signature" KSK rollover to
"Double-KSK".
* Remove Tgen from diagrams.
* Review by Richard Lamb.
* Updated KSK rollover summary text.
* Updated variable descriptions in the appendix.
o draft-ietf-dnsop-dnssec-key-timing-04
* Renamed to "DNSSEC Key Rollover Timing Considerations" to
emphasise that this draft concerns rollover timings.
* Updated 4641bis reference to RFC 6781.
* Add introductory paragraph to each rollover description
summarising its essential features.
* Remove detailed description of double-RRSIG ZSK rollover. It is
extremely unlikely to be used in any practical situation.
* "Double-Signature" KSK rollover renamed to "Double-KSK" to avoid
confusion with the ZSK rollover of the same name.
* Removed section 2.3 (rollover summary) which just listed the
order in which records are published.
* Matthijs Mekking added as co-author.
* Changed Lzsk and Kzsk definitions: actual lifetime instead of
intended lifetime.
* Update diagrams and text to better reflect key states and key
lifetimes.
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 The authors gratefully acknowledge help and contributions from Roy
Initial draft. Arends, Tim Wicinski, and Wouter Wijngaards.
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 United States
Email: stephen@isc.org Email: stephen@isc.org
URI: http://www.isc.org URI: http://www.isc.org
Johan Ihren Johan Ihren
Netnod Netnod
Franzengatan 5 Franzengatan 5
Stockholm, SE-112 51 Stockholm SE-112 51
Sweden Sweden
Email: johani@netnod.se Email: johani@netnod.se
URI: http://www.netnod.se URI: http://www.netnod.se
John Dickinson John Dickinson
Sinodun Internet Technologies Ltd Sinodun Internet Technologies Ltd
Magdalen Centre Magdalen Centre
Oxford Science Park Oxford Science Park
Robert Robertson Avenue Robert Robertson Avenue
Oxford, Oxfordshire OX4 4GA Oxford, Oxfordshire OX4 4GA
UK United Kingdom
Email: jad@sinodun.com Email: jad@sinodun.com
URI: http://www.sinodun.com URI: http://www.sinodun.com
W. (Matthijs) Mekking W. (Matthijs) Mekking
NLnet Labs Dyn, Inc.
Science Park 400 150 Dow St
Amsterdam 1098 XH Manchester NH 03101
The Netherlands United States
Email: matthijs@nlnetlabs.nl Email: mmekking@dyn.com
URI: http://www.nlnetlabs.nl URI: https://www.dyn.com
 End of changes. 175 change blocks. 
505 lines changed or deleted 439 lines changed or added

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