draft-ietf-dnsop-dnssec-key-timing-03.txt   draft-ietf-dnsop-dnssec-key-timing-04.txt 
Internet Engineering Task Force S. Morris Internet Engineering Task Force S. Morris
Internet-Draft ISC Internet-Draft ISC
Intended status: Informational J. Ihren Intended status: Informational J. Ihren
Expires: January 10, 2013 Netnod Expires: January 5, 2015 Netnod
J. Dickinson J. Dickinson
Sinodun Sinodun
July 9, 2012 W. Mekking
NLnet Labs
July 4, 2014
DNSSEC Key Timing Considerations DNSSEC Key Rollover Timing Considerations
draft-ietf-dnsop-dnssec-key-timing-03.txt draft-ietf-dnsop-dnssec-key-timing-04.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 This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2013. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . 2
1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . 4
2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4
2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 5 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . 7
2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . 7
3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 8 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . 8
3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . 8
3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11
3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . 13
3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 12 3.3.1. Double-KSK Method . . . . . . . . . . . . . . . . . . 13
3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . 16
3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 19
3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 16 3.3.4. Interaction with Configured Trust Anchors . . . . . . 21
3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18 3.3.5. Introduction of First Keys . . . . . . . . . . . . . 23
3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.4. Interaction with Configured Trust Anchors . . . . . . 23 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . 24
3.3.5. Introduction of First Keys . . . . . . . . . . . . . . 24 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 24
4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. Normative References . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix B. Change History (To be removed on publication) . . . 29
11. Normative References . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 28
Appendix B. Change History (To be removed on publication) . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
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 51 skipping to change at page 3, line 40
zone should be restricted to the minimum required to support the zone should be restricted to the minimum required to support the
key management policy.) key management policy.)
Management policy, e.g., how long a key is used for, also needs to be Management policy, e.g., how long a key is used for, also needs to be
considered. However, the point of key management logic is not to considered. However, the point of key management logic is not to
ensure that a rollover is completed at a certain time but rather to ensure that a rollover is completed at a certain time but rather to
ensure that no changes are made to the state of keys published in the ensure that no changes are made to the state of keys published in the
zone until it is "safe" to do so ("safe" in this context meaning that zone until it is "safe" to do so ("safe" in this context meaning that
at no time during the rollover process does any part of the zone ever at no time during the rollover process does any part of the zone ever
go bogus). In other words, although key management logic enforces go bogus). In other words, although key management logic enforces
policy, it may not enforce it strictly. policy, it may not enforce it strictly. In Section 3, the lifetime
of a key reflects the actual lifetime of a key, which may be longer
or shorter than the intended amount of time.
A high-level overview of key rollover can be found in A high-level overview of key rollover can be found in [RFC6781]. In
[I-D.ietf-dnsop-rfc4641bis]. In contrast, this document focuses on contrast, this document focuses on the low-level timing detail of two
the low-level timing detail of two classes of operations described classes of operations described there, the rollover of zone-signing
there, the rollover of key-signing keys, and the rollover of zone keys (ZSKs), and the rollover of key-signing keys (KSKs).
signing keys.
1.2. Types of Keys 1.2. Types of Keys
Although DNSSEC validation treats all keys equally, [RFC4033] Although DNSSEC validation treats all keys equally, [RFC4033]
recognises the broad classification of zone-signing keys (ZSK) and recognises the broad classification of ZSKs and KSKs. A ZSK is used
key-signing keys (KSK). A ZSK is used to authenticate information to authenticate information within the zone; a KSK is used to
within the zone; a KSK is used to authenticate the zone's DNSKEY authenticate the zone's DNSKEY RRset. The main implication for this
RRset. The main implication for this distinction concerns the distinction concerns the consistency of information during a
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 the 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 at all times during the
rollover the information is consistent. With a ZSK, the information rollover the information is consistent. With a ZSK, the information
is the RRSIG (plus associated RRset) and the DNSKEY. These are both is the RRSIG (plus associated RRset) and the DNSKEY. These are both
obtained from the same zone. In the case of the KSK, the information obtained from the same zone. In the case of the KSK, the information
is the DNSKEY and DS RRset with the latter being obtained from a is the DNSKEY and DS RRset with the latter being obtained from a
different zone. 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. It is also possible to types of rollovers are described separately. It is also possible to
skipping to change at page 4, line 45 skipping to change at page 4, line 39
this type of key is not treated in this document. this type of key is not treated in this document.
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].
A number of symbols are used to identify times, intervals, etc. All A number of symbols are used to identify times, intervals, etc. All
are listed in Appendix A. are listed in Appendix A.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
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
any caching validator has access to a particular signature that
corresponds to a 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 [I-D.ietf-dnsop-rfc4641bis], the new o Pre-Publication: described in [RFC6781], the new key is introduced
key is introduced into the DNSKEY RRset which is then re-signed. into the DNSKEY RRset which is then re-signed. This state of
This state of affairs remains in place for long enough to ensure affairs remains in place for long enough to ensure that any cached
that any cached DNSKEY RRsets contain both keys. At that point DNSKEY RRsets contain both keys. At that point signatures created
signatures created with the old key can be replaced by those with the old key can be replaced by those created with the new
created with the new key, and the old signatures removed. During key, and the old signatures removed. During the re-signing
the re-signing process (which may or may not be atomic depending process (which may or may not be atomic depending on how the zone
on how the zone is managed), it doesn't matter which key an RRSIG is managed), it doesn't matter which key an RRSIG record retrieved
record retrieved by a resolver was created with; cached copies of by a resolver was created with; cached copies of the DNSKEY RRset
the DNSKEY RRset will contain both the old and new keys. will contain both the old and new keys.
Once the zone contains only signatures created with the new key, Once the zone contains only signatures created with the new key,
there is an interval during which RRSIG records created with the there is an interval during which RRSIG records created with the
old key expire from caches. After this, there will be no old key expire from caches. After this, there will be no
signatures anywhere that were created using the old key, and it signatures anywhere that were created using the old key, and it
can can be removed from the DNSKEY RRset. can be removed from the DNSKEY RRset.
o Double-Signature: also mentioned in [I-D.ietf-dnsop-rfc4641bis], o Double-Signature: also mentioned in [RFC6781], this involves
this involves introducing the new key into the zone and using it introducing the new key into the zone and using it to create
to create additional RRSIG records; the old key and existing RRSIG additional RRSIG records; the old key and existing RRSIG records
records are retained. During the period in which the zone is are retained. During the period in which the zone is being signed
being signed (again, the signing process may not be atomic), (again, the signing process may not be atomic), validating
validating resolvers are always able to validate RRSIGs: any resolvers are always able to validate RRSIGs: any combination of
combination of old and new DNSKEY RRset and RRSIG allows at least old and new DNSKEY RRset and RRSIGs allows at least one signature
one signature to be validated. to be validated.
Once the signing process is complete and enough time has elapsed Once the signing process is complete and enough time has elapsed
to allow all old information to expire from caches, the old key to make sure that all validators that have the DNSKEY and
and signatures can be removed from the zone. As before, during signatures in cache, have both the old and new information, the
this period any combination of DNSKEY RRset and RRSIG will allow old key and signatures can be removed from the zone. As before,
validation of at least one signature. during this period any combination of DNSKEY RRset and RRSIGs will
allow validation of at least one signature.
o Double-RRSIG: strictly speaking, the use of the term "Double- o Double-RRSIG: strictly speaking, the use of the term "Double-
Signature" above is a misnomer as the method is not only double Signature" above is a misnomer as the method is not only double
signature, it is also double key as well. A true Double-Signature signature, it is also double key as well. A true Double-Signature
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 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. Pre-Publication is more later remove the old key and old signatures. It is also the fastest,
complex - introduce the new key, approximately one TTL later sign the but suffers from increasing the size of the zone and the size of
records, and approximately one TTL after that remove the old key. responses.
Pre-Publication is more complex - introduce the new key,
approximately one TTL later sign the records, and approximately one
TTL after that remove the old key. It does however keep the zone and
response sizes to a minimum.
Double-RRSIG is essentially the reverse of Pre-Publication - Double-RRSIG is essentially the reverse of Pre-Publication -
introduce the new signatures, approximately one TTL later change the introduce the new signatures, approximately one TTL later change the
key, and approximately one TTL after that remove the old signatures. key, and approximately one TTL after that remove the old signatures.
However, it has the disadvantage of the Pre-Publication method in
terms of time taken to perform the rollover, the disadvantage of the
Double-Signature rollover in terms of zone and response sizes, and
none of the advantages of either. For these reasons, it is unlikely
to be used in any real-world situations and so will not be considered
further in this document.
2.2. KSK Rollovers 2.2. KSK Rollovers
For ZSKs, the issue for the validating resolver is to ensure that it In the KSK case, there should not be a problem that a caching
has access to the ZSK that corresponds to a particular signature. In validator does not have access to a particular signature that
the KSK case, this can never be a problem as the KSK is only used for corresponds to a valid KSK. The KSK is only used for one signature
one signature (that over the DNSKEY RRset) and both the key and the (that over the DNSKEY RRset) and both the key and the signature
signature travel together. Instead, the issue is to ensure that the travel together. Instead, the issue is to ensure that the KSK is
KSK is trusted. trusted.
Trust in the KSK is either due to the existence of a signed and Trust in the KSK is either due to 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
skipping to change at page 6, line 49 skipping to change at page 7, line 5
effect of being dependent on the parent is that there may be a period effect of being 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 of waiting for the parent to respond in addition to any delay the key
rollover logic requires. Although this introduces additional delays, rollover logic requires. Although this introduces additional delays,
even with a parent that is less than ideally responsive the only even with a parent that is less than ideally responsive the only
effect will be a slowdown in the rollover state transitions. This effect will be a slowdown in the rollover state transitions. This
may cause a policy violation, but will not cause any operational may cause a policy violation, but will not cause any operational
problems. 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-Signature: also known as Double-DNSKEY, the new KSK is o Double-KSK: the new KSK is added to the DNSKEY RRset which is then
added to the DNSKEY RRset which is then signed with both the old signed with both the old and new key. After waiting for the old
and new key. After waiting for the old RRset to expire from RRset to expire from caches, the DS record in the parent zone is
caches, the DS record in the parent zone is changed. After changed. After waiting a further interval for this change to be
waiting a further interval for this change to be reflected in reflected in caches, the old key is removed from the RRset.
caches, the old key is removed from the RRset. (The name "Double-
Signature" is used because, like the ZSK method of the same name,
the new key is introduced and immediately used for signing.)
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 added to the parent zone. After waiting a suitable interval for
the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY
and DS record are removed. and DS record are removed.
In essence, "Double-Signature" means that the new KSK is introduced In essence, "Double-KSK" means that the new KSK is introduced first
first and used to sign the DNSKEY RRset. The DS record is changed, and used to sign the DNSKEY RRset. The DS record is changed, and
and finally the old KSK removed. With "Double-DS" it is the other finally the old KSK removed. With "Double-DS" it is the other way
way around. Finally, Double-RRset does both updates more or less in around. Finally, Double-RRset does both updates more or less in
parallel. parallel.
2.3. Summary Of the three methods, the major disadvantages are the number of times
you have to contact the parent and the size of the DNSKEY RRset. In
The methods can be summarised as follows: Double-Signature there is just one parent interaction but there is a
larger DNSKEY RRset. In the case of Double-DS there are two
+------------------+------------------+-----------------------------+ interactions with the parent (although the second one does not slow
| ZSK Method | KSK Method | Description | down your rollover). The Double-RRset is the fastest, but has both
+------------------+------------------+-----------------------------+ the disadvantages of the other two methods.
| Pre-Publication | (not applicable) | Publish the DNSKEY before |
| | | the RRSIGs. |
| Double-Signature | Double-Signature | Publish the DNSKEY and |
| | | RRSIGs at same time. For a |
| | | KSK, this happens before |
| | | the DS is published. |
| Double-RRSIG | (not applicable) | Publish RRSIGs before the |
| | | DNSKEY. |
| (not applicable) | Double-DS | Publish DS before the |
| | | DNSKEY. |
| (not applicable) | Double-RRset | Publish DNSKEY and DS in |
| | | parallel. |
+------------------+------------------+-----------------------------+
Table 1
3. Key Rollover Timelines 3. Key Rollover Timelines
3.1. Key States 3.1. Key States
During the rolling process, a key moves through different states. During the rolling process, keys move through different states. The
The defined states are: defined states are:
Generated The key has been created, but has not yet been used for Generated The key has been created, but has not yet been used for
anything. anything.
Published The DNSKEY record - or information associated with it - Published The DNSKEY and/or DS record is published in the zone.
is published in the zone, but predecessors of the key (or
associated information) may be held in caches.
The idea of "associated information" is used in rollover
methods where RRSIG or DS records are published first and
the DNSKEY is changed in an atomic operation. It allows
the rollover still to be thought of as moving through a
set of states. In the rest of this section, the term
"key data" should be taken to mean "key or associated
information".
Ready The new key data has been published for long enough to Ready The DNSKEY and/or DS record have been published for long
guarantee that any previous versions of the DNSKEY RRset enough to guarantee that any previous versions of the
have expired from caches. DNSKEY RRset have expired from caches.
Active The key has started to be used to sign RRsets. Note that Active The data is starting to be used for validation. In the
when this state is entered, it may not be possible for case of a ZSK, it means that the key has been started to
validating resolvers to use the key for validation in all be used to sign RRsets. In the case of a KSK, it means
cases: the zone signing may not have finished, or the that it is possible to use it to validate a DNSKEY RRset
data might not have reached the resolver because of as the DNSKEY and DS records are present in the relevant
propagation delays and/or caching issues. If this is the zones. Note that when this state is entered, it may not
case, the resolver will have to rely on the key's be possible for validating resolvers to use the data for
predecessor instead. validation in all cases: the zone signing may not have
finished, or the data might not have reached the resolver
because of propagation delays and/or caching issues. If
this is the case, the resolver will have to rely on the
predecessor data instead.
Retired A successor key has become active and this key is no Retired The data has ceased to be used for validation. In the
longer being used to generate RRSIGs. However, as there case of a ZSK, it means that the key is no longer used to
may still be RRSIGs in caches that were generated using sign RRsets. In the case of a KSK, it means that the
this key, it is being retained in the zone until they successor DNSKEY and DS records are in place: this key
have expired. and its DS record can be removed as soon as it is safe to
do so. However, until this happens, the resource records
may still available for use in validation.
Dead The key is published in the zone but there is no longer Dead The DNSKEY and/or DS record are present in the zone but
information anywhere that requires its presence. Hence there is no longer information anywhere that requires its
the key can be removed from the zone at any time. presence for use in validation. Hence it can be removed
from the zone at any time.
Removed The key has been removed from the zone. Removed The DNSKEY and/or DS record have been removed from the
zone.
There is one additional state, used where [RFC5011] considerations There is one additional state, used where [RFC5011] considerations
are in effect (see Section 3.3.4): are in effect (see Section 3.3.4):
Revoked The key is published for a period with the "revoke" bit Revoked The DNSKEY is published for a period with the "revoke"
set as a way of notifying validating resolvers that have bit set as a way of notifying validating resolvers that
configured it as an [RFC5011] trust anchor that it is have configured it as an [RFC5011] trust anchor that it
about to be removed from the zone. is about to be removed from the zone.
3.2. Zone-Signing Key Timelines 3.2. Zone-Signing Key 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.
After enough time to ensure that any cached DNSKEY RRsets contain
both keys, the the zone is signed using the new key and the old
signatures are removed. Finally, when all signatures created with
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| |9| |0| |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---- - -
| | | | | | | | | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS Tret Tdea Trem Key N Tgen Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tgen 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 is generated at the generate time (Tgen). Although Event 0: Key N and N+1 are generated at the generate time (Tgen).
there is no reason why the key cannot be generated immediately prior Although there is no reason why the key cannot be generated
to its publication in the zone (Event 2), some implementations may immediately prior to its publication in the zone (Event 1), some
find it convenient to create a pool of keys in one operation and draw implementations may find it convenient to create a pool of keys in
from that pool as required. For this reason, it is shown as a one operation and draw from that pool as required. For this reason,
separate event. Keys that are available for use but not published it is shown as a separate event. Keys that are available for use but
are said to be generated. not published are said to be generated.
Event 2: Key N's DNSKEY record is put into the zone, i.e., it is Event 1: Key N's DNSKEY record is put into the zone, i.e., it is
added to the DNSKEY RRset which is then re-signed with the current added to the DNSKEY RRset which is then re-signed with the current
key-signing key. The time at which this occurs is the key's active key-signing keys. The time at which this occurs is the key's
publication time (Tpub), and the key is now said to be published. publication time (Tpub), and the key is now said to be published.
Note that the key is not yet used to sign records. Note that the key is not yet used to sign records.
Event 3: Before it can be used, the key must be published for long Event 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 in the worst- Here, Dprp is the propagation delay - the time taken for a change
case situation for a change introduced at the master to replicate to introduced at the master to replicate to all name servers. TTLkey is
all slave servers - which depends on the depth of the master-slave the time-to-live (TTL) for the DNSKEY records in the zone. The sum
hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records is therefore the maximum time taken for existing DNSKEY records to
in the zone. The sum is therefore the maximum time taken for expire from caches, regardless of the nameserver from which they were
existing DNSKEY records to expire from caches, regardless of the retrieved.
nameserver from which they were 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 the key'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 = Tpub + Ipub Trdy(N) = Tpub(N) + Ipub
Event 4: 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, the RRsets. This point is the activation time (Tact) and after this, key
key is said to be active. N is said to be active.
Event 5: At some point thought must be given to its successor (key Tact(N) >= Trdy(N)
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. Denoting the publication time of the before it is activated. The publication time of key N+1 depends on
successor key by TpubS, then: the activation time of key N:
TpubS <= Tact + 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 unlike the publication ZSK lifetime). It should be noted that in the diagrams the actual
interval, Lzsk is not determined by timing logic, but by key key lifetime is represented; this may differ slightly from the
management policy. Lzsk will be set by the operator according to intended lifetime set by key management policy.
their assessment of the risks posed by continuing to use a key and
the risks associated with key rollover. However, operational
considerations may mean a key is active for slightly more or less
than Lzsk.
Event 6: 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 7: 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 lifetime, it is retired (i.e., it will never again be used to
generate new signatures) and key N+1 activated and used to sign the generate new signatures) and key N+1 activated and used to sign the
zone. This is the retire time of key N (Tret) and is given by: zone. This is the retire time of key N (Tret), and is given by:
Tret = Tact + Lzsk Tret(N) = Tact(N) + Lzsk
It is also the activation time of the successor key (TactS). Note It is also the activation time of the successor key N+1. Note that
that operational considerations may cause key N to remain in use for operational considerations may cause key N to remain in use for
longer than Lzsk; if so, the retirement actually occurs when the longer than the lifetime set by the key management policy.
successor key is made active.
Event 8: 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 unexpired RRSIG record and an expired DNSKEY RRset in the have an old RRSIG record in the cache, but the old DNSKEY RRset has
cache when it is asked to provide both to a client. In this case the expired when it is asked to provide both to a client. In this case
DNSKEY RRset would need to be looked up again.) This means that once the DNSKEY RRset would need to be looked up again.) This means that
the key is no longer used to sign records, it should be retained in once the key is no longer used to sign records, it should be retained
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 (as described above) the re-signed with the new key. Dprp is the propagation delay, required
propagation delay, required to guarantee that the updated zone to guarantee that the updated zone information has reached all slave
information has reached all slave servers, and TTLsig is the maximum servers, and TTLsig is the maximum TTL of all the RRSIG records in
TTL of all the RRSIG records in the zone created with the ZSK. 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 = Tret + 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 9: 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 key-signing key. This time is the removal time (Trem), given
by: by:
Trem >= Tdea 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;
the old key and signatures are retained. Once all cached DNSKEY and/
or RRSIG information contains copies of the new DNSKEY and RRSIGs
created with it, the old DNSKEY and RRSIGs can be removed from the
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
|0| |1| |2| |3| |4|
|1| |2| |3| |4| |5| | | | | |
| | | | | Key N | |<-------Lzsk----------->|<--->|
Key N | |<----Lzsk--->|<---Iret--->| | | | | | |
| | | | | | | |<--Iret-->| |
Key N+1 | | |<-----Lzsk------- - - | | | | |
| | | | | Key N+1 | | |<----Lzsk------- - -
Tgen Tact Tret Tdea Trem | | | | |
Key N Tgen Tact Tdea Trem
Key N+1 Tgen 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 generated at the generate time (Tgen). Although Event 0: Key N and N+1 are generated at the generate time (Tgen).
there is no reason why the key cannot be generated immediately prior Although there is no reason why the key cannot be generated
to its publication in the zone (Event 2), some implementations may immediately prior to its publication in the zone (Event 1), some
find it convenient to create a pool of keys in one operation and draw implementations may find it convenient to create a pool of keys in
from that pool as required. For this reason, it is shown as a one operation and draw from that pool as required. For this reason,
separate event. Keys that are available for use but not published it is shown as a separate event. Keys that are available for use but
are said to be generated. not published are said to be generated.
Event 2: 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. This is the zone; existing signatures in the zone are not removed. The key
the activation time (Tact), after which the key is said to be active. is published and active: this is key N's activation time (Tact),
after which the key is said to be active.
Event 3: After the current key (key N) has been in use for its Event 2: As the current key (key N) approaches the end of its actual
intended lifetime (Lzsk), the successor key (key N+1) is introduced lifetime (Lzsk), the successor key (key N+1) is introduced into the
into the zone and starts being used to sign RRsets: neither the zone and starts being used to sign RRsets: neither the current key
current key nor the signatures created with it are removed. The nor the signatures created with it are removed. The successor key is
successor is key is now active and the current key is said to be now also active.
retired. This time is the retire time of the key (Tret); it is also
the activation time of the successor key (TactS).
Tret = Tact + Lzsk Tact(N+1) = Tact(N) + Lzsk - Iret
Event 4: 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. The final term (the maximum of TTLkey and TTLsig) is the delay, required to guarantee that the updated zone information has
period to wait for key and signature data associated with key N to reached all slave servers. The final term (the maximum of TTLkey and
expire from caches. (TTLkey is the TTL of the DNSKEY RRset and TTLsig) is the period to wait for key and signature data associated
TTLsig is the maximum TTL of all the RRSIG records in the zone with key N to expire from caches. (TTLkey is the TTL of the DNSKEY
created with the ZSK. The two may be different: although the TTL of RRset and TTLsig is the maximum TTL of all the RRSIG records in the
an RRSIG is equal to the TTL of the RRs in the associated RRset zone created with the ZSK. The two may be different: although the
[RFC4034], the DNSKEY RRset only needs to be signed with the KSK.) 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
KSK.)
At the end of this interval, key N is said to be dead. This occurs At the end of this interval, key N is said to be dead. This occurs
at the dead time (Tdea) so: at the dead time (Tdea) so:
Tdea = Tret + Iret Tdea(N) = Tact(N+1) + Iret
Event 5: 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 >= Tdea Trem(N) >= Tdea(N)
3.2.3. Double-RRSIG Method
The timeline for a double-signature rollover is shown below. The
diagram follows the convention described in Section 3.2.1
|1||2| |3| |4||5| |6| |7||8| |9| |10|
| | | | | | | | | |
Key N | |<-Dsgn->| | |<--------Lzsk-------->|<-Iret->| |
| |<---IpubG-->| | | | | | |
| | | | | | | | | |
Key N+1 | | | | | |<-IpubG->| | | |
| | | | | | | | | |
Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem
---- Time ---->
Figure 3: Timeline for a Double-Signature ZSK rollover.
Event 1: Key N is generated at the generate time (Tgen). Although
there is no reason why the key cannot be generated immediately prior
to its publication in the zone (Event 2), some implementations may
find it convenient to create a pool of keys in one operation and draw
from that pool as required. For this reason, it is shown as a
separate event. Keys that are available for use but not published
are said to be generated.
Event 2: Key N is used to sign the zone but existing signatures are
retained. Although the new ZSK is not published in the zone at this
point, for analogy with the other ZSK rollover methods and because
this is the first time that key information is visible (albeit
indirectly through the created signatures) this time is called the
publication time (Tpub).
Event 3: After the signing interval, Dsgn, all RRsets that need to be
signed have been signed by the new key. (As a result, all these
RRsets are now signed twice, once by the (still-absent) key N and
once by its predecessor.
Event 4: There is now a delay while the old signature information
expires from caches. This interval is given by the expression:
Dprp + TTLsig
As before, Dprp is the propagation delay and TTLsig is the maximum
TTL of all the RRSIG records in the zone created with the ZSK.
Again in analogy with other key rollover methods, this is defined as
key N's ready time (Trdy) and the key is said to be in the ready
state. (Although the key is not in the zone, it is ready to be
used.) The interval between the publication and ready times is the
publication interval of the signature, IpubG, i.e.,
Trdy = Tpub + IpubG
where
IpubG = Dsgn + Dprp + TTLsig
Event 5: At some later time the predecessor key is removed and the
key N added to the DNSKEY RRset. As all the signed RRs have
signatures created by the old and new keys, the records can still be
authenticated. This time is the activation time (Tact) and the key
is now said to be active.
Event 6: At some point thought must be given to rolling the key. The
first step is to publish signatures created by the successor key (key
N+1) early enough for key N to be replaced after it has been active
for its scheduled lifetime. This occurs at TpubS (the publication
time of the successor), given by:
TpubS <= Tact + Lzsk - IpubG
Event 7: The signatures have propagated and the new key could be
added to the zone. This time is the ready time of the successor key
(TrdyS).
TrdyS = TpubS + IpubG
... where IpubG is as defined above.
Event 8: At some later time key N is removed from the zone's DNSKEY
RRset and the successor key (key N+1) is added to it. This is the
retire time of the key (Tret).
Event 9: The signatures must remain in the zone for long enough that
the new DNSKEY RRset has had enough time to propagate to all caches.
Once caches contain the new DNSKEY, the old signatures are no longer
of use and can be considered to be dead as they cannot be validated
by any key. In analogy with other rollover methods, the time at
which this occurs is the dead time (Tdea), given by:
Tdea = Tret + Iret
... where Iret is the retire interval, given by:
Iret = Dprp + TTLkey
Dprp is as defined earlier and TTLkey is the TTL of the DNSKEY RRset.
Event 10: At some later time the signatures can be removed from the
zone. In analogy with other rollover methods, this time is called
the remove time (Trem) and is given by:
Trem >= Tdea
3.3. Key-Signing Key Rollover Timelines 3.3. Key-Signing Key Rollover Timelines
The following sections describe the rolling of a KSK. They show the The following sections describe the rolling of a KSK. They show the
events in the lifetime of a key (referred to as "key N") and cover it events in the lifetime of a key (referred to as "key N") and cover it
replacement by its successor (key N+1). replacement by its successor (key N+1).
3.3.1. Double-Signature Method 3.3.1. Double-KSK Method
In this rollover, The new DNSKEY is added to the zone. After an
interval long enough to guarantee that any cached DNSKEY RRsets
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
caches, the old DNSKEY is removed from the 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| |5| |0| |1| |2| |3| |4|
| | | | | | | | | |
Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - - Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - -
| | | | | | | | | |
Key N+1 | | | | | Key N+1 | | | | |
| | | | | | | | | |
Tgen Tpub Trdy Tsub Tact Key N Tgen Tpub Trdy Tsubds Tact
Key N+1 Tgen
---- Time ----> ---- Time ---->
(continued ...) (continued ...)
|6| |7| |8| |9| |10| |11| |5| |6| |7| |8| |9| |10|
| | | | | | | | | | | |
Key N - - -------------Lksk------->|<-Iret->| | Key N - - -------------Lksk------->|<-Iret->|<----->|
| | | | | | | | | | | |
Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - - Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | | | | | | | |
TpubS TrdyS TsubS Tret Tdea Trem Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsubds Tact
---- Time (cont) ----> ---- Time (cont) ---->
Figure 4: Timeline for a Double-Signature KSK rollover. Figure 3: Timeline for a Double-Signature KSK rollover.
Event 1: Key N is generated at the generate time (Tgen). Although Event 0: Key N and N+1 are generated at the generate time (Tgen).
there is no reason why the key cannot be generated immediately prior Although there is no reason why the key cannot be generated
to its publication in the zone (Event 2), some implementations may immediately prior to its publication in the zone (Event 1), some
find it convenient to create a pool of keys in one operation and draw implementations may find it convenient to create a pool of keys in
from that pool as required. For this reason, it is shown as a one operation and draw from that pool as required. For this reason,
separate event. Keys that are available for use but not published it is shown as a separate event. Keys that are available for use but
are said to be generated. not published are said to be generated.
Event 2: 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 key N and all currently active KSKs. RRset, which is then signed by all currently active KSKs. (So at
(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 (Tpub); after this the key is well.) This is the publication time of key N (Tpub); after this the
said to be published. key is said to be published.
Event 3: 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 (Ipub) and, for the second The interval is the publication interval (Ipub) and, for the second
or subsequent KSKs in the zone, is given by: or subsequent KSKs in the zone, is given by:
Ipub = DprpC + TTLkey Ipub = DprpC + TTLkey
... where DprpC is the propagation delay for the child zone (the zone ... where DprpC is the propagation delay for the child zone (the zone
containing the KSK being rolled) and TTLkey the TTL for the DNSKEY containing the KSK being rolled) and TTLkey the TTL for the DNSKEY
RRset. The time at which this occurs is the key's ready time, Trdy, RRset. The time at which this occurs is the key N's ready time,
given by: Trdy, given by:
Trdy = Tpub + Ipub Trdy(N) = Tpub(N) + Ipub
(The case of introducing the first KSK into the zone is discussed in (The case of introducing the first KSK into the zone is discussed in
Section 3.3.5.) Section 3.3.5.)
Event 4: At some later time, the DS record corresponding to the new Event 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, Tsub. the submission time, Tsubds:
Event 5: The DS record is published in the parent zone. As this is Tsubds(N) >= Trdy(N)
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 the key rollover methods, this is called the activation time of key N (Tact):
(Tact):
Tact = Tsub + Dreg Tact(N) = Tsubds(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 received by 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 organisational overhead of
transferring a record.) 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
DS record in the parent zone.)
Event 6: 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 both the before, this means that the DNSKEY RRset is signed by all active
current and successor KSK.) This time is the publication time of the KSKs.) This time is the publication time of the successor key N+1,
successor key, TpubS, given by: given by:
TpubS <= Tact + Lksk - Dreg - Ipub Tpub(N+1) <= Tact(N) + Lksk - Dreg - Ipub
... where Lksk is the scheduled lifetime of the KSK. ... where Lksk is the actual lifetime of the KSK, and Dreg the
registration delay. In practice, Dreg will not be a fixed time:
Event 7: After an interval Ipub, key N+1 becomes ready (in that all instead, the end of Dreg will be signalled by the appearance of the
DS record in the parent zone.
Event 6: After an interval Ipub, key N+1 becomes ready (in that all
caches that have a copy of the DNSKEY RRset have a copy of this key). caches that have a copy of the DNSKEY RRset have a copy of this key).
This time is the ready time of the successor (TrdyS). This time is the ready time of the successor key N+1 (Trdy).
Event 8: At the submission time of the successor (TsubS), the DS Event 7: At the submission time of the successor key N+1,
record corresponding to key N+1 is submitted to the parent zone. Tsubds(N+1), the DS record corresponding to key N+1 is submitted to
the parent zone.
Event 9: The successor DS record is published in the parent zone and Event 8: The successor DS record is published in the parent zone and
the current DS record withdrawn. The current key is said to be the current DS record withdrawn. Key N is said to be retired and the
retired and the time at which this occurs is Tret, given by: time at which this occurs is Tret(N), given by:
Tret = Tact + Lksk Tret(N) = Tsubds(N+1) + Dreg
Event 10: 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, is said to be dead. This As the key is no longer used for anything, is said to be dead. This
point is the dead time (Tdea), given by: point is the dead time (Tdea), given by:
Tdea = Tret + Iret Tdea(N) = Tret(N) + Iret
Event 11: 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 >= Tdea 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.
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
the old DNSKEY RRset to expire from caches, the old DS record is
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| |6| |0| |1| |2| |3| |4| |5|
| | | | | | | | | | | |
Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - - Key N | |<-Dreg->|<-IpubP->|<-->|<-------Lksk----- - -
| | | | | | | | | | | |
Key N+1 | | | | |<---->|<--Dreg+IpubP- - - Key N+1 | | | | | |<--Dreg-- - -
| | | | | | | | | | | |
Tgen Tsub Tpub Trdy Tact TsubS Key N Tgen Tsubds Tpub Trdy Tact
Key N+1 Tgen Tsubds
---- Time ----> ---- Time ---->
(continued ...) (continued ...)
|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------ - -
| | | | | | | | |
TrdyS Tret Tdea Trem Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ----> ---- Time ---->
Figure 5: Timeline for a Double-DS KSK rollover. Figure 4: Timeline for a Double-DS KSK rollover.
Event 1: Key N is generated at the generate time (Tgen). Although Event 0: Key N and N+1 are generated at the generate time Tgen(key).
there is no reason why the key cannot be generated immediately prior Although there is no reason why the key cannot be generated
to its publication in the zone (Event 2), some implementations may immediately prior to its use, some implementations may find it
find it convenient to create a pool of keys in one operation and draw convenient to create a pool of keys in one operation and draw from
from that pool as required. For this reason, it is shown as a that pool as required. For this reason, it is shown as a separate
separate event. Keys that are available for use but not published event. Keys that are available for use but not published are said to
are said to be generated. be generated.
Event 2: 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, Tsub. This time is the submission time, Tsubds.
Event 3: 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, published in the parent zone. This is the publication time (Tpub) of
given by: key N, given by:
Tpub = Tsub + Dreg Tpub(N) = Tsubds(N) + Dreg
Event 4: 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 key's ready time, the zone. For this reason, this time is known as the key's ready
Trdy, and is given by: time, Trdy, and is given by:
Trdy = Tpub + IpubP Trdy(N) = Tpub(N) + IpubP
IpubP is the parent publication interval and is given by the IpubP is the publication interval of the DS record and is given by
expression: 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 5: 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 key (key N) is introduced into the DNSKEY RRset and used to sign
that. that, while the old key is removed from the DNSKEY RRset.
As both the old and new DS records have been in the parent zone long As both the old and new DS records have been in the parent zone long
enough to ensure that they are in caches that contain the DS RRset, enough to ensure that they are in caches that contain the DS RRset,
the zone can be authenticated throughout the rollover - the the zone can be authenticated throughout the rollover - the
validating resolver either has a copy of the DNSKEY RRset validating resolver either has a copy of the DNSKEY RRset
authenticated by the predecessor key, or it has a copy of the updated authenticated by the predecessor key, or it has a copy of the updated
RRset authenticated with the new key. RRset authenticated with the new key.
This time is key N's activation time (Tact) and at this point the key This time is key N's activation time (Tact) and at this point key N
is said to be active. is said to be active:
Event 6: At some point thought must be given to key replacement. The Tact(N) >= Trdy(N)
Event 5: At some point thought must be given to key replacement. The
DS record for the successor key must be submitted to the parent zone DS record for the successor key must be submitted to the parent zone
at a time such that when the current key is withdrawn, any cache that at a time such that when the current key is withdrawn, any cache that
contains the zone's DS records has data about the DS record of the contains the zone's DS records has data about the DS record of the
successor key. The time at which this occurs is the submission time successor key. The time at which this occurs is the submission time
of the successor, given by: of the successor key N+1, given by:
TsubS <= Tact + Lksk - IpubP - Dreg Tsubds(N+1) <= Tact(N) + Lksk - Ipub - Dreg
... where Lksk is the lifetime of key N according to policy. ... where Lksk is the actual lifetime of key N (which may differ
slightly from the lifetime set in the key management policy) and Dreg
is the registration delay. Again, Dreg will not be a fixed time:
instead, the end of Dreg will be signalled by the appearance of the
DS record in the parent zone.
Event 6. After an interval Dreg, the successor DS record is
published in the zone at time Tpub.
Event 7: The successor key (key N+1) enters the ready state, i.e., Event 7: The successor key (key N+1) enters the ready state, i.e.,
its 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.
This is the ready time of the successor key, TrdyS. This is the ready time of the successor key N+1, Trdy.
(The interval between events 6 and 7 for the key N+1 correspond to
the interval between events 2 and 4 for key N)
Event 8: When key N has been active for its lifetime (Lksk), it is Event 8: When key N has been active for its lifetime (Lksk), it is
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. This is the retire time (Tret) of key N, given by: with the new key. This is the retire time (Tret) of key N, given by:
Tret = Tact + Lksk Tret(N) = Tact(N) + Lksk
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 = Tret + Iret Tdea(N) = Tret(N) + Iret
... where Iret is the retire interval, 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 >= Tdea Trem(N) >= Tdea(N)
3.3.3. Double-RRset Method 3.3.3. Double-RRset Method
The timeline for a double-RRset rollover is shown below. The diagram In the double-RRset rollover, the new DNSKEY and DS records are
follows the convention described in Section 3.2.1 published simultaneously in the appropriate zones. Once enough time
has elapsed for the old DNSKEY and DS RRsets to expire from caches,
the old DNSKEY and DS records are removed from their respective
zones.
|1| |2| |3| |4| |5| |6| The timeline for this rollover is shown below. The diagram follows
| | | | | | the convention described in Section 3.2.1
Key N | |<-Ipub->|<-----Lksk----->| | |0| |1| |2| |3| |4| |5|
| | | | | | | | | | | |
Key N+1 | | | |<-Ipub->| | Key N | |<-Ipub->|<-----Lksk----->|<------>|
| | | | | | | | | | | |
Tgen Tpub Tact TpubS Tret Trem Key N+1 | | | |<-Ipub->|<------Lksk--- - -
| | | | | |
Key N Tgen Tpub Tact Tret Trem
Key N+1 Tgen Tpub Tact
---- Time ----> ---- Time ---->
Figure 6: Timeline for a Double-RRset KSK rollover. Figure 5: Timeline for a Double-RRset KSK rollover.
Event 1: Key N is generated at the generate time (Tgen). Although Event 0: Key N and N+1 are generated at the generate time (Tgen).
there is no reason why the key cannot be generated immediately prior Although there is no reason why the key cannot be generated
to its publication in the zone (Event 2), some implementations may immediately prior to its publication in the zone (Event 1), some
find it convenient to create a pool of keys in one operation and draw implementations may find it convenient to create a pool of keys in
from that pool as required. For this reason, it is shown as a one operation and draw from that pool as required. For this reason,
separate event. Keys that are available for use but not published it is shown as a separate event. Keys that are available for use but
are said to be generated. not published are said to be generated.
Event 2: The key is added to and used for signing the DNSKEY RRset Event 1: The key is added to and used for signing the DNSKEY RRset
and is thereby published in the zone. At the same time the and is thereby published in the zone. At the same time the
corresponding DS record is submitted to the parent zone for corresponding DS record is submitted to the parent zone for
publication. This time is the publish time (Tpub) and the key is now publication. This time is the publish time for key N (Tpub) and the
said to be published. key is said to be published.
Event 3: At some later time, the DS record is published in the parent Event 2: At some later time, the DS record is published in the parent
zone and at some time after that, the updated information has reached zone and at some time after that, the updated information has reached
all caches: any cache that holds a DNSKEY RRset from the child zone all caches: any cache that holds a DNSKEY RRset from the child zone
will have a copy that includes the new KSK, and any cache that has a will have a copy that includes the new KSK, and any cache that has a
copy of the parent DS RRset will have a copy that includes the new DS copy of the parent DS RRset will have a copy that includes the new DS
record. record.
The time at which this occurs is called the activation time of the The time at which this occurs is called the activation time of key N
new KSK (Tact), given by: (Tact), given by:
Tact = Tpub + Ipub Tact(N) = Tpub(N) + Ipub
... where Ipub is the publication interval, given by: ... where Ipub is the composite publication interval for the DNSKEY
and DS records, given by:
Ipub = max(IpubP, IpubC), Ipub = max(IpubP, IpubC),
IpubP being the publication interval in the parent zone and IpubC the IpubP being the publication interval of the DS record in the parent
publication interval in the child zone. The parent zone's zone and IpubC the publication interval of the DNSKEY in the child
publication interval is given by: zone. The parent zone's publication interval is given by:
IpubP = Dreg + DprpP + TTLds IpubP = Dreg + DprpP + TTLds
where Dreg is the registration delay, the time taken for the DS where Dreg is the registration delay, the time taken for the DS
record to be published in the parent zone. DprpP is the parent 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 zone's propagation delay and TTLds is the TTL of the DS record in
that zone. that zone.
The child's publication interval is given by a similar equation: The child zone's publication interval is given by a similar equation:
IpubC = DprpC + TTLkey IpubC = DprpC + TTLkey
... where DprpC is the propagation delay in the child zone and TTLkey ... where DprpC is the propagation delay in the child zone and TTLkey
the TTL of a DNSKEY record. the TTL of a DNSKEY record.
Event 4: At some point we need to give thought to key replacement. Event 3: At some point we need to give thought to key replacement.
The successor key (key N+1) must be introduced into the zone (and its The successor key (key N+1) must be introduced into the zone (and its
DS record submitted to the parent) at a time such that it becomes DS record submitted to the parent) at a time such that it becomes
active when the current key has been active for its lifetime, Lksk. active when the current key has been active for its actual lifetime,
This time is TpubS, the publication time of the successor key, and is Lksk. This is the publication time (Tpub) of the successor key, and
given by: is given by:
TpubS <= Tact + Lksk - Ipub Tpub(N+1) <= Tact(N) + Lksk - Ipub
... where Lksk is the lifetime of the KSK. ... where Lksk is the actual lifetime of the KSK and Ipub is as
defined above.
Event 5: Key N+1's DNSKEY and DS records are in any caches that Event 4: Key N+1's DNSKEY and DS records are now in caches that
contain the child zone DNSKEY and/or the parent zone DS RR, and so contain the child zone DNSKEY and/or the parent zone DS RR, and so
the zone can be validated with the new key. This is the activation the zone can be validated with the new key. This is the activation
time of the successor key (TactS) and by analogy with other rollover time (Tact) of the successor key N+1 and by analogy with other
methods, it is also the retire time of the current key. Since at rollover methods, it is also the dead time of key N:
this time the zone can be validated by the successor key, there is no
reason to keep the current key in the zone and the time can also be
regarded as the current key's dead time. Thus:
Tret = Tdea = TactS = Tact + Lksk Tdea(N) = Tact(N) + Lksk
Event 6: 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 >= Tdea 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 KSKs
where the trust anchor is a DS record in the parent zone, zone where the trust anchor is a DS record in the parent zone, zone
managers may want to take account of the possibility that some managers may want to take account of the possibility that some
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 publication interval (Ipub) in When the new key is introduced, the publication interval (Ipub) in
the Double-Signature and Double-RRset methods should also be subject the Double-Signature and Double-RRset methods should also be subject
to the condition: to the condition:
Ipub >= Dprp + max(Itrp, TTLkey) Ipub >= Dprp + max(Itrp, TTLkey)
... where the right hand side of the expression is the time taken for ... where the right hand side of the expression is the time taken for
the change to propagate to all nameservers for the zone plus the the change to propagate to all nameservers for the zone plus the
"trust point" interval. This latter term is the interval required to "trust point" interval. This latter 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 from a particular trust point will see at least two validated DNSKEY
RRsets containing the new key (a requirement from [RFC5011], section RRsets containing the new key (a requirement from [RFC5011], section
2.4.1). It is defined by the expression: 2.4.1). It is defined by the expression:
Itrp >= (2 * queryInterval) + (n * retryTime) Itrp >= (2 * queryInterval) + (n * retryTime)
... where queryInterval and retryTime are as defined in section 2.3 ... where queryInterval and retryTime are as defined in section 2.3
of [RFC5011]. "n" is the total number of retries needed by the of [RFC5011]. "n" is the total number of retries needed by the
resolver during the two attempts to get the DNSKEY RRset. resolver during the two attempts to get the DNSKEY RRset.
The first term of the expression (2 * queryInterval) represents the The first term of the expression (2 * queryInterval) represents the
time to obtain two validated DNSKEY RRsets. The second term (n * time to obtain two validated DNSKEY RRsets. The second term (n *
retryTime) is a safety margin, with the value of "n" reflecting the retryTime) is a safety margin, with the value of "n" reflecting the
degree of confidence in the communication between a resolver and the degree of confidence in the communication between a resolver and the
trust point. trust point.
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 >= 30 days
... 30 days being the [RFC5011] remove hold-down time. After this ... 30 days being the [RFC5011] remove hold-down time. After this
time, the key is dead and can be removed from the zone. time, the key is dead and can be removed from the zone.
3.3.5. Introduction of First 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.
skipping to change at page 26, line 10 skipping to change at page 24, line 32
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, [RFC4035]
(section 2.4) states that "There MUST be an RRSIG for each RRset (section 2.4) requires that there be an RRSIG for each RRset using at
using at least one DNSKEY of each algorithm in the zone apex DNSKEY least one DNSKEY of each algorithm in the zone apex DNSKEY RRset.
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. Limitation of Scope 6. Limitation of Scope
skipping to change at page 27, line 34 skipping to change at page 26, line 8
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
This document does not introduce any new security issues beyond those This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011]. already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
10. Acknowledgements 10. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy The authors gratefully acknowledge help and contributions from Roy
Arends, Matthijs Mekking and Wouter Wijngaards. Arends and Wouter Wijngaards.
11. Normative References 11. Normative References
[I-D.ietf-dnsop-rfc4641bis]
Kolkman, O. and M. Mekking, "DNSSEC Operational Practices,
Version 2", draft-ietf-dnsop-rfc4641bis-11 (work in
progress), April 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements", RFC
RFC 4033, March 2005. 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", RFC 5011, September 2007. Trust Anchors", STD 74, RFC 5011, September 2007.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, December
2012.
Appendix A. List of Symbols Appendix A. List of Symbols
The document defines a number of symbols, all of which are listed The document defines a number of symbols, all of which are listed
here. All are of the form: here. All are of the form:
All symbols used in the text are of the form: All symbols used in the text are of the form:
<TYPE><id><INST> <TYPE><id><INST>
where: where:
<TYPE> is an upper-case character indicating what type the symbol is. <TYPE> is an upper-case 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
skipping to change at page 29, line 4 skipping to change at page 27, line 16
I and T and TTL are self-explanatory. Like I, both D and L are time I and T and TTL are self-explanatory. Like I, both D and L are time
periods, but whereas I values are intervals between two events (even periods, but whereas I values are intervals between two events (even
if the events are defined in terms of the interval, e.g., the dead if the events are defined in terms of the interval, e.g., the dead
time occurs "retire interval" after the retire time), D and L are time occurs "retire interval" after the retire time), D and L are
fixed intervals: a "D" interval (delay) is a feature of the process, fixed intervals: a "D" interval (delay) is a feature of the process,
probably outside control of the zone manager, whereas an "L" interval probably outside control of the zone manager, whereas an "L" interval
(lifetime) is chosen by the zone manager and is a feature of policy. (lifetime) is chosen by the zone manager and is a feature of policy.
<id> is lower-case and defines what object or event the variable is <id> is lower-case and defines what object or event the variable is
related to, e.g., related to, e.g.,
act activation act activation
pub publication pub publication
ret retire ret retire
Finally, <INST> is a capital letter that distinguishes between the <INST> is a capital letter that distinguishes between the same
same variable applying to different instances of an object and is one variable applying to different instances of an object and is one of:
of:
C child C child
G signature
P parent P parent
S successor Within the rollover descriptions, times are suffixed the a number in
brackets indicating the the key to which they apply, e.g. Tact(N) is
the activation time of key N, Tpub(N+1) the publication time of key
N+1 etc.
The list of variables used in the text is: 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 organisation to that
managing the child zone, the delays associated with passing managing the child zone, the delays associated with passing
data between zones is captured by this term. data between zones 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 key before it can be assumed after the publication of a record before it can be assumed
that any resolvers that have the DNSKEY RRset cached have a that any resolvers that have the relevant RRset cached have
copy of this key. a copy of the new information.
IpubC Publication interval in the child zone. IpubC Publication interval in the child zone.
IpubG Publication interval for the signature created by a ZSK:
the amount of time that must elapse after the signature has
been created before it can be assumed that any resolves
that have the RRset and RRSIG cached have a copy of this
signature.
IpubP Publication interval in the parent zone. IpubP Publication interval in the parent zone.
Iret Retire interval. The amount of time that must elapse after Iret Retire interval. The amount of time that must elapse after
a key enters the retire state for any signatures created a DNSKEY or DS record enters the retire state for any
with it to be purged from validating resolver caches. dependent information (e.g. RRSIG for a DNSKEY) to be
purged from validating resolver caches.
Irev Revoke interval. The amount of time that a KSK must remain Irev Revoke interval. The amount of time that a KSK must remain
published with the revoke bit set to satisfy [RFC5011] published with the revoke bit set to satisfy [RFC5011]
considerations. considerations.
Itrp Trust-point interval. The amount of time that a trust 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 to guarantee that a resolver
configured for an automatic update of keys will see the new configured for an automatic update of keys will see the new
key at least twice. key at least twice.
Lksk Lifetime of a key-signing key. This is the intended amount Lksk Lifetime of a key-signing key. This is the actual amount
of time for which this particular KSK is regarded as the of time for which this particular KSK is regarded as the
active KSK. Depending on when the key is rolled-over, the active KSK. Depending on when the key is rolled-over, the
actual lifetime may be longer or shorter than this. actual lifetime may be longer or shorter than the intended
key lifetime indicated by management policy.
Lzsk Lifetime of a zone-signing key. This is the intended Lzsk Lifetime of a zone-signing key. This is the actual amount
amount of time for which the ZSK is used to sign the zone. of time for which the ZSK is used to sign the zone.
Depending on when the key is rolled-over, the actual Depending on when the key is rolled-over, the actual
lifetime may be longer or shorter than this. lifetime may be longer or shorter than the intended key
lifetime indicated by management policy.
Tact Activation time of the key; the time at which the key is
regarded as the principal key for the zone.
TactS Activation time of the successor key. Tact Activation time of the rollover; the time at which the key
is regarded as the principal key for the zone.
Tdea Dead time of a key. Applicable only to ZSKs, this is the Tdea Dead time of a key. Applicable only to ZSKs, this is the
time at which any record signatures held in validating time at which any record signatures held in validating
resolver caches are guaranteed to be created with the resolver caches are guaranteed to be created with the
successor key. successor key.
Tgen Generate time of a key. The time that a key is created. Tgen Generation time of a rollover. The time that a key is
created.
Tpub Publication time of a key. The time that a key appears in
a zone for the first time.
TpubS Publication time of the successor key.
Trem Removal time of a key. The time at which a key is removed
from the zone.
Tret Retire time of a key. The time at which a successor key Tpub Publication time of a rollover. The time that information
starts being used to sign the zone. such as the DNSKEY or DS record appears in the zone for the
first time.
Trdy Ready time of a key. The time at which it can be Trem Removal time of a rollover. The time at which information
guaranteed that validating resolvers that have key is removed from the zone.
information from this zone cached have a copy of this key
in their cache. (In the case of KSKs, should the
validating resolvers also have DS information from the
parent zone cached, the cache must include information
about the DS record corresponding to the key.)
TrdyS Ready time of a successor key. Tret Retire time of a rollover. The time at which successor
information starts being used.
Tsub Submission time - the time at which the DS record of a KSK Trdy Ready time of a rollover. The time at which it can be
is submitted to the parent. guaranteed that validating resolvers that have information
from this zone cached have a copy of the new information in
their cache. (In the case of KSKs, should the validating
resolvers also have DS information from the parent zone
cached, the cache must include information about the DS
record corresponding to the key.)
TsubS Submission time of the successor key. Tsubds Submission time. The time at which the DS record of a KSK
is submitted to the parent zone.
TTLds Time to live of a DS record (in the parent zone). 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) Appendix B. Change History (To be removed on publication)
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 o draft-ietf-dnsop-dnssec-key-timing-03
* Clarifications of and corrections to wording (Marc Lampo, Alfred * Clarifications of and corrections to wording (Marc Lampo, Alfred
Hoenes). Hoenes).
* Updated timings related to trust anchor interaction (Matthijs * Updated timings related to trust anchor interaction (Matthijs
Mekking). Mekking).
* Updated RFC 4641 reference to 4641bis (Alfred Hoenes). * Updated RFC 4641 reference to 4641bis (Alfred Hoenes).
* Moved change history to end of document (Alfred Hoenes). * Moved change history to end of document (Alfred Hoenes).
o draft-ietf-dnsop-dnssec-key-timing-02 o draft-ietf-dnsop-dnssec-key-timing-02
* Significant re-wording of some sections. * Significant re-wording of some sections.
skipping to change at page 32, line 4 skipping to change at page 30, line 23
* Updated timings related to trust anchor interaction (Matthijs * Updated timings related to trust anchor interaction (Matthijs
Mekking). Mekking).
* Updated RFC 4641 reference to 4641bis (Alfred Hoenes). * Updated RFC 4641 reference to 4641bis (Alfred Hoenes).
* Moved change history to end of document (Alfred Hoenes). * Moved change history to end of document (Alfred Hoenes).
o draft-ietf-dnsop-dnssec-key-timing-02 o draft-ietf-dnsop-dnssec-key-timing-02
* Significant re-wording of some sections. * Significant re-wording of some sections.
* Removal of events noting change of state of predecessor key from * Removal of events noting change of state of predecessor key from
ZSK Double-RRSIG and Double-Signature methods. ZSK Double-RRSIG and Double-Signature methods.
* Change order of bullet points (and some wording) in section 1.1. * Change order of bullet points (and some wording) in section 1.1.
* Remove discussion of advantages and disadvantages of key roll * Remove discussion of advantages and disadvantages of key roll
methods from section 2: draft is informative and does not give methods from section 2: draft is informative and does not give
recommendations. recommendations.
* Removal of discussion of upper limit to retire time relationship * Removal of discussion of upper limit to retire time relationship
to signature lifetime. to signature lifetime.
* Remove timing details of first key in the zone and move * Remove timing details of first key in the zone and move
discussion of first signing of a zone to later in the document). discussion of first signing of a zone to later in the document.
(Matthijs Mekking) (Matthijs Mekking)
* Removal of redundant symbols from Appendix A. * Removal of redundant symbols from Appendix A.
o draft-ietf-dnsop-dnssec-key-timing-01 o draft-ietf-dnsop-dnssec-key-timing-01
* Added section on limitation of scope. * Added section on limitation of scope.
o draft-ietf-dnsop-dnssec-key-timing-00 o draft-ietf-dnsop-dnssec-key-timing-00
* Change to author contact details. * Change to author contact details.
o draft-morris-dnsop-dnssec-key-timing-02 o draft-morris-dnsop-dnssec-key-timing-02
skipping to change at page 33, line 13 skipping to change at page 31, line 32
Initial draft. Initial draft.
Authors' Addresses Authors' Addresses
Stephen Morris Stephen Morris
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 423 1300
Email: stephen@isc.org Email: stephen@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
Phone: +46 8615 8573 Email: johani@netnod.se
Email: johani@autonomica.se URI: http://www.netnod.se
John Dickinson John Dickinson
Sinodun Internet Technologies Ltd Sinodun Internet Technologies Ltd
Stables 4 Suite 11, Howbery Park Magdalen Centre
Wallingford, Oxfordshire OX10 8BA Oxford Science Park
Robert Robertson Avenue
Oxford, Oxfordshire OX4 4GA
UK UK
Phone: +44 1491 818120
Email: jad@sinodun.com Email: jad@sinodun.com
URI: http://www.sinodun.com
W. (Matthijs) Mekking
NLnet Labs
Science Park 400
Amsterdam 1098 XH
The Netherlands
Email: matthijs@nlnetlabs.nl
URI: http://www.nlnetlabs.nl
 End of changes. 201 change blocks. 
619 lines changed or deleted 558 lines changed or added

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