summaryrefslogtreecommitdiff
path: root/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt')
-rw-r--r--doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt1848
1 files changed, 1848 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt
new file mode 100644
index 0000000000000..60d2772b5dc3b
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-key-timing-02.txt
@@ -0,0 +1,1848 @@
+
+
+
+Internet Engineering Task Force S. Morris
+Internet-Draft ISC
+Intended status: Informational J. Ihren
+Expires: September 11, 2011 Netnod
+ J. Dickinson
+ Sinodun
+ March 10, 2011
+
+
+ DNSSEC Key Timing Considerations
+ draft-ietf-dnsop-dnssec-key-timing-02.txt
+
+Abstract
+
+ This document describes the issues surrounding the timing of events
+ in the rolling of a key in a DNSSEC-secured zone. It presents
+ timelines for the key rollover and explicitly identifies the
+ relationships between the various parameters affecting the process.
+
+Status of this Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on September 11, 2011.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 1]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Key Rolling Considerations . . . . . . . . . . . . . . . . 3
+ 1.2. Types of Keys . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 4
+ 2. Rollover Methods . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. ZSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. KSK Rollovers . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3. Key Rollover Timelines . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. Key States . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. Zone-Signing Key Timelines . . . . . . . . . . . . . . . . 9
+ 3.2.1. Pre-Publication Method . . . . . . . . . . . . . . . . 9
+ 3.2.2. Double-Signature Method . . . . . . . . . . . . . . . 11
+ 3.2.3. Double-RRSIG Method . . . . . . . . . . . . . . . . . 13
+ 3.3. Key-Signing Key Rollover Timelines . . . . . . . . . . . . 15
+ 3.3.1. Double-Signature Method . . . . . . . . . . . . . . . 15
+ 3.3.2. Double-DS Method . . . . . . . . . . . . . . . . . . . 18
+ 3.3.3. Double-RRset Method . . . . . . . . . . . . . . . . . 21
+ 3.3.4. Interaction with Configured Trust Anchors . . . . . . 23
+ 3.3.4.1. Addition of KSK . . . . . . . . . . . . . . . . . 23
+ 3.3.4.2. Removal of KSK . . . . . . . . . . . . . . . . . . 24
+ 3.3.5. Introduction of First KSK . . . . . . . . . . . . . . 24
+ 4. Standby Keys . . . . . . . . . . . . . . . . . . . . . . . . . 24
+ 5. Algorithm Considerations . . . . . . . . . . . . . . . . . . . 25
+ 6. Limitation of Scope . . . . . . . . . . . . . . . . . . . . . 26
+ 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
+ 11. Change History (To be removed on publication) . . . . . . . . 27
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 29
+ Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 29
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 2]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+1. Introduction
+
+1.1. Key Rolling Considerations
+
+ When a zone is secured with DNSSEC, the zone manager must be prepared
+ 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
+ existing keys, or it may be due to a management policy that demands
+ periodic key replacement for security or operational reasons. In
+ order to implement a key rollover, the keys need to be introduced
+ into and removed from the zone at the appropriate times.
+ Considerations that must be taken into account are:
+
+ o DNSKEY records and associated information (such as the associated
+ DS records or RRSIG records created with the key) are not only
+ held at the authoritative nameserver, they are also cached by
+ resolvers. The data on these systems can be interlinked, e.g. a
+ validating resolver may try to validate a signature retrieved from
+ a cache with a key obtained separately.
+
+ o Zone "boot-strapping" events, where a zone is signed for the first
+ time, can be common in configurations where a large number of
+ zones are being served. Procedures should be able to cope with
+ the introduction of keys into the zone for the first time as well
+ as "steady-state", where the records are being replaced as part of
+ normal zone maintenance.
+
+ o To allow for an emergency re-signing of the zone as soon as
+ possible after a key compromise has been detected, standby keys
+ (additional keys over and above those used to sign the zone) need
+ to be present.
+
+ o A query for the DNSKEY RRset returns all DNSKEY records in the
+ zone. As there is limited space in the UDP packet (even with
+ EDNS0 support), key records no longer needed must be periodically
+ removed. (For the same reason, the number of standby keys in the
+ zone should be restricted to the minimum required to support the
+ key management policy.)
+
+ 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
+ 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
+ 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
+ go bogus). In other words, although key management logic enforces
+ policy, it may not enforce it strictly.
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 3]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+1.2. Types of Keys
+
+ Although DNSSEC validation treats all keys equally, [RFC4033]
+ recognises the broad classification of zone-signing keys (ZSK) and
+ key-signing keys (KSK). A ZSK is used to authenticate information
+ within the zone; a KSK is used to authenticate the zone's DNSKEY
+ RRset. The main implication for this distinction concerns the
+ consistency of information during a rollover.
+
+ During operation, a validating resolver must use separate pieces of
+ information to perform an authentication. At the time of
+ authentication, each piece of information may be in its cache or may
+ need to be retrieved from the authoritative server. The rollover
+ process needs to happen in such a way that at all times during the
+ rollover the information is consistent. With a ZSK, the information
+ 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
+ is the DNSKEY and DS RRset with the latter being obtained from a
+ different zone.
+
+ Although there are similarities in the algorithms to roll ZSKs and
+ KSKs, there are a number of differences. For this reason, the two
+ types of rollovers are described separately. It is also possible to
+ use a single key as both the ZSK and KSK. However, the rolling of
+ this type of key is not treated in this document.
+
+1.3. Terminology
+
+ The terminology used in this document is as defined in [RFC4033] and
+ [RFC5011].
+
+ A number of symbols are used to identify times, intervals, etc. All
+ 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.1. ZSK Rollovers
+
+ A ZSK can be rolled in one of three ways:
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 4]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ o Pre-Publication: described in [RFC4641], the new key is introduced
+ into the DNSKEY RRset which is then re-signed. This state of
+ affairs remains in place for long enough to ensure that any cached
+ DNSKEY RRsets contain both keys. At that point signatures created
+ with the old key can be replaced by those created with the new
+ key, and the old signatures removed. During the re-signing
+ process (which may or may not be atomic depending on how the zone
+ is managed), it doesn't matter which key an RRSIG record retrieved
+ by a resolver was created with; cached copies of the DNSKEY RRset
+ will contain both the old and new keys.
+
+ Once the zone contains only signatures created with the new key,
+ there is an interval during which RRSIG records created with the
+ old key expire from caches. After this, there will be no
+ signatures anywhere that were created using the old key, and it
+ can can be removed from the DNSKEY RRset.
+
+ o Double-Signature: also mentioned in [RFC4641], this involves
+ introducing the new key into the zone and using it to create
+ additional RRSIG records; the old key and existing RRSIG records
+ are retained. During the period in which the zone is being signed
+ (again, the signing process may not be atomic), validating
+ resolvers are always able to validate RRSIGs: any combination of
+ old and new DNSKEY RRset and RRSIG allows at least one signature
+ to be validated.
+
+ Once the signing process is complete and enough time has elapsed
+ to allow all old information to expire from caches, the old key
+ and signatures can be removed from the zone. As before, during
+ this period any combination of DNSKEY RRset and RRSIG will allow
+ validation of at least one signature.
+
+ o Double-RRSIG: strictly speaking, the use of the term "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
+ method (here called the Double-RRSIG method) involves introducing
+ new signatures in the zone (while still retaining the old ones)
+ but not introducing the new key.
+
+ Once the signing process is complete and enough time has elapsed
+ 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
+ further interval during which the old DNSKEY RRset expires from
+ caches, the old signatures are removed from the zone.
+
+ Of three methods, Double-Signature is conceptually the simplest -
+ introduce the new key and new signatures, then approximately one TTL
+ later remove the old key and old signatures. Pre-Publication is more
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 5]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ complex - introduce the new key, approximately one TTL later sign the
+ records, and approximately one TTL after that remove the old key.
+ Double-RRSIG is essentially the reverse of Pre-Publication -
+ introduce the new signatures, approximately one TTL later change the
+ key, and approximately one TTL after that remove the old signatures.
+
+2.2. KSK Rollovers
+
+ For ZSKs, the issue for the validating resolver is to ensure that it
+ has access to the ZSK that corresponds to a particular signature. In
+ the KSK case this can never be a problem as the KSK is only used for
+ one signature (that over the DNSKEY RRset) and both the key the
+ signature travel together. Instead, the issue is to ensure that the
+ KSK is trusted.
+
+ Trust in the KSK is either due to the existence of a DS record in the
+ parent zone (which is itself trusted) or an explicitly configured
+ trust anchor. If the former, the rollover algorithm will need to
+ 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
+ latter, [RFC5011] timings will be needed to roll the keys. (Even in
+ the case where authentication is via a DS record, the zone manager
+ 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
+ configured as a trust anchor.)
+
+ It is important to note that this does not preclude the development
+ of key rollover logic; in accordance with the goal of the rollover
+ logic being able to determine when a state change is "safe", the only
+ effect of being dependent on the parent is that there may be a period
+ of waiting for the parent to respond in addition to any delay the key
+ rollover logic requires. Although this introduces additional delays,
+ even with a parent that is less than ideally responsive the only
+ effect will be a slowdown in the rollover state transitions. This
+ may cause a policy violation, but will not cause any operational
+ problems.
+
+ Like the ZSK case, there are three methods for rolling a KSK:
+
+ o Double-Signature: also known as Double-DNSKEY, the new KSK is
+ added to the DNSKEY RRset which is then signed with both the old
+ and new key. After waiting for the old RRset to expire from
+ caches, the DS record in the parent zone is changed. After
+ waiting a further interval for this change to be reflected in
+ 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.)
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 6]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ o Double-DS: the new DS record is published. After waiting for this
+ change to propagate into caches, the KSK is changed. After a
+ further interval during which the old DNSKEY RRset expires from
+ caches, the old DS record is removed.
+
+ 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
+ added to the parent zone. After waiting a suitable interval for
+ the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY
+ and DS record are removed.
+
+ In essence, "Double-Signature" means that the new KSK is introduced
+ first and used to sign the DNSKEY RRset. The DS record is changed,
+ and finally the old KSK removed. With "Double-DS" it is the other
+ way around. Finally, Double-RRset does both updates more or less in
+ parallel.
+
+2.3. Summary
+
+ The methods can be summarised as follows:
+
+ +------------------+------------------+-----------------------------+
+ | ZSK Method | KSK Method | Description |
+ +------------------+------------------+-----------------------------+
+ | Pre-Publication | (not applicable) | Publish the DNSKEY before |
+ | | | the RRSIG. |
+ | Double-Signature | Double-Signature | Publish the DNSKEY and |
+ | | | RRSIG at same time. (For a |
+ | | | KSK, this happens before |
+ | | | the DS is published.) |
+ | Double-RRSIG | (not applicable) | Publish RRSIG 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.1. Key States
+
+ During the rolling process, a key moves through different states.
+ The defined states are:
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 7]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Generated The key has been created, but has not yet been used for
+ anything.
+
+ Published The DNSKEY record - or information associated with it -
+ 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
+ guarantee that any previous versions of it have expired
+ from caches.
+
+ Active The key has started to be used to sign RRsets. Note that
+ when this state is entered, it may not be possible for
+ validating resolvers to use the key for 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 key's
+ predecessor instead.
+
+ Retired The key is in the zone but a successor key has become
+ active. As there may still be information in caches that
+ that require use of the key, it is being retained until
+ this information expires.
+
+ Dead The key is published in the zone but there is no longer
+ information anywhere that requires its presence. Hence
+ the key can be removed from the zone at any time.
+
+ Removed The key has been removed from the zone.
+
+ There is one additional state, used where [RFC5011] considerations
+ are in effect (see Section 3.3.4):
+
+ Revoked The key is published for a period with the "revoke" bit
+ set as a way of notifying validating resolvers that have
+ configured it as an [RFC5011] trust anchor that it is
+ about to be removed from the zone.
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 8]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+3.2. Zone-Signing Key Timelines
+
+ 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
+ its replacement by its successor (key N+1).
+
+3.2.1. Pre-Publication Method
+
+ The following diagram shows the timeline of a Pre-Publication
+ rollover. Time increases along the horizontal scale from left to
+ right and the vertical lines indicate events in the process.
+ Significant times and time intervals are marked.
+
+
+
+ |1| |2| |3| |4| |5| |6| |7| |8| |9|
+ | | | | | | | | |
+ Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
+ | | | | | | | | |
+ Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - -
+ | | | | | | | | |
+ Tgen Tpub Trdy Tact TpubS Tret Tdea Trem
+
+ ---- Time ---->
+
+
+ Figure 1: Timeline for a Pre-Publication 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'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 key-
+ signing key. The time at which this occurs is the key's publication
+ time (Tpub), and the key is now said to be published. 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
+ enough to guarantee that any cached version of the zone's DNSKEY
+ RRset includes this key.
+
+ This interval is the publication interval (Ipub) and, for the second
+ or subsequent keys in the zone, is given by:
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 9]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Ipub = Dprp + TTLkey
+
+ Here, Dprp is the propagation delay - the time taken in the worst-
+ case situation for a change introduced at the master to replicate to
+ all slave servers - which depends on the depth of the master-slave
+ hierarchy. TTLkey is the time-to-live (TTL) for the DNSKEY records
+ in the zone. The sum is therefore the maximum time taken for
+ existing DNSKEY records to expire from caches, regardless of the
+ nameserver from which they were retrieved.
+
+ (The case of introducing the first ZSK into the zone is discussed in
+ Section 3.3.5.)
+
+ 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
+ ready time (Trdy), which is given by:
+
+ Trdy = Tpub + Ipub
+
+ Event 4: at some later time, the key starts being used to sign
+ RRsets. This point is the activation time (Tact) and after this, the
+ key is said to be active.
+
+ Event 5: at some point thought must be given to its successor (key
+ N+1). As with the introduction of the currently active key into the
+ zone, the successor key will need to be published at least Ipub
+ before it is activated. Denoting the publication time of the
+ successor key by TpubS, then:
+
+ TpubS <= Tact + Lzsk - Ipub
+
+ 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
+ interval, Lzsk is not determined by timing logic, but by key
+ management policy. Lzsk will be set by the operator according to
+ 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.
+ From this time onwards, key N+1 could be used to sign the zone.
+
+ Event 7: When key N has been in use for an interval equal to the the
+ ZSK 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
+ zone. This is the retire time of key N (Tret) and is given by:
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 10]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Tret = Tact + Lzsk
+
+ It is also the activation time of the successor key (TactS). Note
+ that operational considerations may cause key N to remain in use for
+ longer than Lzsk; if so, the retirement actually occurs when the
+ successor key is made active.
+
+ Event 8: the retired key needs to be retained in the zone whilst any
+ RRSIG records created using this key are still published in the zone
+ or held in caches. (It is possible that a validating resolver could
+ have an unexpired RRSIG record and an expired DNSKEY RRset in the
+ cache when it is asked to provide both to a client. In this case the
+ DNSKEY RRset would need to be looked up again.) This means that once
+ the key is no longer used to sign records, it should be retained in
+ the zone for at least the retire interval (Iret) given by:
+
+ Iret = Dsgn + Dprp + TTLsig
+
+ 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
+ propagation delay, required to guarantee that the updated zone
+ information has reached all slave servers, and TTLsig is the maximum
+ TTL of all the RRSIG records in the zone.
+
+ The time at which all RRSIG records created with this key have
+ expired from resolver caches is the dead time (Tdea), given by:
+
+ Tdea = Tret + Iret
+
+ ...at which point the key is said to be dead.
+
+ Event 9: at any time after the key becomes dead, it can be removed
+ from the zone and the DNSKEY RRset re-signed with the current key-
+ signing key. This time is the removal time (Trem), given by:
+
+ Trem >= Tdea
+
+ ...at which time the key is said to be removed.
+
+3.2.2. Double-Signature Method
+
+ The timeline for a double-signature rollover is shown below. The
+ diagram follows the convention described in Section 3.2.1
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 11]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ |1| |2| |3| |4| |5|
+ | | | | |
+ Key N | |<----Lzsk--->|<---Iret--->| |
+ | | | | |
+ Key N+1 | | |<-----Lzsk------- - -
+ | | | | |
+ Tgen Tact Tret Tdea Trem
+
+ ---- Time ---->
+
+
+ Figure 2: 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 added to the DNSKEY RRset and is then used to sign
+ the zone; existing signatures in the zone are not removed. This is
+ the activation time (Tact), after which the key is said to be active.
+
+ Event 3: after the current key (key N) has been in use for its
+ intended lifetime (Lzsk), the successor key (key N+1) is introduced
+ into the zone and starts being used to sign RRsets: neither the
+ current key nor the signatures created with it are removed. The
+ successor is key is now active and the current key is said to be
+ 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
+
+ Event 4: before key N can be withdrawn from the zone, all RRsets that
+ need to be signed must have been signed by the successor key (key
+ 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
+ replaced - each RRset is signed by both the old and new key.
+
+ This takes Iret, the retire interval, given by the expression:
+
+ Iret = Dsgn + Dprp + max(TTLkey, TTLsig)
+
+ As before, Dsgn is the delay needed to ensure that all existing
+ RRsets have been signed with the new key, Dprp is the propagation
+ delay. The final term (the maximum of TTLkey and TTLsig) is the
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 12]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ period to wait for key and signature data associated with key N to
+ expire from caches. (TTLkey is the TTL of the DNSKEY RRset and
+ TTLsig is the maximum TTL of all the RRSIG records in the zone
+ created with the ZSK. The two may be different as although the TTL
+ 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 dead time (Tdea) so:
+
+ Tdea = Tret + Iret
+
+ Event 5: at some later time key N and its signatures can be removed
+ from the zone. This is the removal time Trem, given by:
+
+ Trem >= Tdea
+
+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
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 13]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ 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.
+
+ 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).
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 14]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ TrdyS = TpubS + IpubG
+
+ ... where IpubG is as defined above.
+
+ Event 8: at some later time key N is removed from the zone and the
+ successor key (key N+1) added. 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. The time at which this as
+ they can not 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
+
+ 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
+ replacement by its successor (key N+1).
+
+3.3.1. Double-Signature Method
+
+ The timeline for a double-signature rollover is shown below. The
+ diagram follows the convention described in Section 3.2.1
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 15]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ |1| |2| |3| |4| |5|
+ | | | | |
+ Key N | |<-Ipub->|<--->|<-Dreg->|<-----Lksk--- - -
+ | | | | |
+ Key N+1 | | | | |
+ | | | | |
+ Tgen Tpub Trdy Tsub Tact
+
+ ---- Time ---->
+
+ (continued...)
+
+ |6| |7| |8| |9| |10| |11|
+ | | | | | |
+ Key N - - -------------Lksk------->|<-Iret->| |
+ | | | | | |
+ Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
+ | | | | | |
+ TpubS TrdyS TsubS Tret Tdea Trem
+
+ ---- Time (cont) ---->
+
+
+ Figure 4: Timeline for a Double-Signature KSK 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 introduced into the zone; it is added to the DNSKEY
+ RRset, which is then signed by key N and all currently active KSKs.
+ (So at this point, the DNSKEY RRset is signed by both key N and its
+ 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
+ said to be published.
+
+ Event 3: before it can be used, the key must be published for long
+ enough to guarantee that any validating resolver that has a copy of
+ 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
+ about the DNSKEY RRset has expired.
+
+ The interval is the publication interval (Ipub) and, for the second
+ or subsequent KSKs in the zone, is given by:
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 16]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Ipub = DprpC + TTLkey
+
+ ... where DprpC is the propagation delay for the child zone (the zone
+ 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,
+ given by:
+
+ Trdy = Tpub + Ipub
+
+ (The case of introducing the first KSK into the zone is discussed in
+ Section 3.3.5.)
+
+ Event 4: at some later time, the DS record corresponding to the new
+ KSK is submitted to the parent zone for publication. This time is
+ the submission time, Tsub.
+
+ Event 5: the DS record is published in the parent zone. As this is
+ the point at which all information for authentication - both DNSKEY
+ and DS record - is available in the two zones, in analogy with other
+ rollover methods, this is called the activation time of the key
+ (Tact):
+
+ Tact = Tsub + Dreg
+
+ ... 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
+ placed in the zone. (Parent zones are often managed by different
+ entities, and this term accounts for the organisational overhead of
+ transferring a record.)
+
+ Event 6: while key N is active, thought needs to be given to its
+ successor (key N+1). At some time before the scheduled end of the
+ KSK lifetime, the successor KSK is published in the zone. (As
+ before, this means that the DNSKEY RRset is signed by both the
+ current and successor KSK.) This time is the publication time of the
+ successor key, TpubS, given by:
+
+ TpubS <= Tact + Lksk - Dreg - Ipub
+
+ ... where Lksk is the scheduled lifetime of the KSK.
+
+ Event 7: after an interval Ipub, key N+1 becomes ready (in that all
+ caches that have a copy of the DNSKEY RRset have a copy of this key).
+ This time is the ready time of the successor (TrdyS).
+
+ Event 8: at the submission time of the successor (TsubS), the DS
+ record corresponding to key N+1 is submitted to the parent zone.
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 17]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Event 9: the successor DS record is published in the parent zone and
+ the current DS record withdrawn. The current key is said to be
+ retired and the time at which this occurs is Tret, given by:
+
+ Tret = Tact + Lksk
+
+ Event 10: key N must remain in the zone until any caches that contain
+ a copy of the DS RRset have a copy containing the new DS record.
+ This interval is the retire interval, given by:
+
+ Iret = DprpP + TTLds
+
+ ... where DprpP is the propagation delay in the parent zone and TTLds
+ 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
+ point is the dead time (Tdea), given by:
+
+ Tdea = Tret + Iret
+
+ Event 11: at some later time, key N is removed from the zone (at the
+ remove time Trem); the key is now said to be removed.
+
+ Trem >= Tdea
+
+3.3.2. Double-DS Method
+
+ The timeline for a double-DS rollover is shown below. The diagram
+ follows the convention described in Section 3.2.1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 18]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ |1| |2| |3| |4| |5| |6|
+ | | | | | |
+ Key N | |<-Dreg->|<-IpubP->|<-->|<---------Lksk------- - -
+ | | | | | |
+ Key N+1 | | | | |<---->|<--Dreg+IpubP- - -
+ | | | | | |
+ Tgen Tsub Tpub Trdy Tact TsubS
+
+ ---- Time ---->
+
+ (continued...)
+
+ |7| |8| |9| |10|
+ | | | |
+ Key N - - -----Lksk---------->|<-Iret->| |
+ | | | |
+ Key N+1 - - --Dreg+IpubP->|<--->|<------Lksk------ - -
+ | | | |
+ TrdyS Tret Tdea Trem
+
+ ---- Time ---->
+
+
+ Figure 5: Timeline for a Double-DS KSK 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: the DS RR is submitted to the parent zone for publication.
+ This time is the submission time, Tsub.
+
+ Event 3: after the registration delay, Dreg, the DS record is
+ published in the parent zone. This is the publication time Tpub,
+ given by:
+
+ Tpub = Tsub + Dreg
+
+ Event 4: at some later time, any cache that has a copy of the DS
+ RRset will have a copy of the DS record for key N. At this point, key
+ N, if introduced into the DNSKEY RRset, could be used to validate the
+ zone. For this reason, this time is known as the key's ready time,
+ Trdy, and is given by:
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 19]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Trdy = Tpub + IpubP
+
+ IpubP is the parent publication interval and is given by the
+ expression:
+
+ IpubP = DprpP + TTLds
+
+ ... where DprpP is the propagation delay for the parent zone and
+ TTLds the TTL assigned to DS records in that zone.
+
+ Event 5: at some later time, the key rollover takes place and the new
+ key (key N) introduced and used to sign the RRset.
+
+ 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,
+ the zone can be authenticated throughout the rollover - either the
+ resolver has a copy of the DNSKEY RRset authenticated by the
+ predecessor key, or it has a copy of the updated RRset authenticated
+ with the new key.
+
+ This time is key N's activation time (Tact) and at this point the key
+ is said to be active.
+
+ Event 6: at some point thought must be given to key replacement. The
+ DS record for the successor key must be submitted to the parent zone
+ at a time such that when the current key is withdrawn, any cache that
+ contains the zone's DS records have data about the DS record of the
+ successor key. The time at which this occurs is the submission time
+ of the successor, given by:
+
+ TsubS <= Tact + Lksk - IpubP - Dreg
+
+ ... where Lksk is the lifetime of key N according to policy.
+
+ Event 7: the successor key (key N+1) enters the ready state i.e. its
+ DS record is now in caches that contain the parent DS RRset. This is
+ the ready time of the successor key, TrdyS.
+
+ (The interval between events 6 and 7 for the key N+1 correspond to
+ the the interval between events 2 and 4 for key N)
+
+ Event 8: when key N has been active for its lifetime (Lksk), it is
+ removed from the DNSKEY RRset and key N+1 added; the RRset is then
+ signed with the new key. This is the retire time of the key, Tret,
+ given by:
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 20]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Tret = Tact + Lksk
+
+ 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
+ analogy with other rollover methods, this is called the dead time,
+ Tdea, and is given by:
+
+ Tdea = Tret + Iret
+
+ ... where Iret is the retire interval, given by:
+
+ Iret = DprpC + TTLkey
+
+ As before, this term includes DprpC, the time taken to propagate the
+ RRset change through the master-slave hierarchy of the child zone and
+ 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
+ parent zone. In analogy with other rollover methods, this is the
+ removal time (Trem), given by:
+
+ Trem >= Tdea
+
+3.3.3. Double-RRset Method
+
+ The timeline for a double-RRset rollover is shown below. The diagram
+ follows the convention described in Section 3.2.1
+
+
+
+ |1| |2| |3| |4| |5| |6|
+ | | | | | |
+ Key N | |<-Ipub->|<-----Lksk----->| |
+ | | | | | |
+ Key N+1 | | | |<-Ipub->| |
+ | | | | | |
+ Tgen Tpub Tact TpubS Tret Trem
+
+ ---- Time ---->
+
+
+ Figure 6: Timeline for a Double-RRset KSK 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
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 21]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ separate event. Keys that are available for use but not published
+ are said to be generated.
+
+ Event 2: the key is added to and used for signing the DNSKEY RRset
+ and is thereby published in the zone. At the same time the
+ corresponding DS record is submitted to the parent zone for
+ publication. This time is the publish time (Tpub) and the key is now
+ said to be published.
+
+ Event 3: at some later time, the DS record is published in the parent
+ zone and at some time after that, the updated information has reached
+ 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
+ copy of the parent DS RRset will have a copy that includes the new DS
+ record.
+
+ The time at which this occurs is called the activation time of the
+ new KSK (Tact), given by:
+
+ Tact = Tpub + Ipub
+
+ ... where Ipub is the publication interval, given by:
+
+ Ipub = max(IpubP, IpubC),
+
+ IpubP being the publication interval in the parent zone and IpubC the
+ publication interval in the child zone. The parent zone's
+ publication interval is given by:
+
+ IpubP = Dreg + DprpP + TTLds
+
+ where Dreg is the registration delay, the time taken for the DS
+ record to be published in the parent zone. DprpP is the parent
+ zone's propagation delay and TTLds is the TTL of the DS record in
+ that zone.
+
+ The child's publication interval is given by a similar equation:
+
+ IpubC = DprpC + TTLkey
+
+ ... where DprpC is the propagation delay in the child zone and TTLkey
+ the TTL of a DNSKEY record.
+
+ Event 4: at some point we need to give thought to key replacement.
+ The successor key (key N+1) must be introduced into the zone (and its
+ 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.
+ This time is TpubS, the publication time of the successor key, and is
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 22]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ given by:
+
+ TpubS <= Tact + Lksk - Ipub
+
+ ... where Lksk is the lifetime of the KSK.
+
+ Event 5: key N+1's DNSKEY and DS records are in any caches that
+ contain the child zone DNSKEY and/or the parent zone DS RR, and so
+ 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
+ methods, it is also the retire time of the current key. Since at
+ this time the zone can be validated by the successor key, there is no
+ 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
+
+ Event 6: at some later time, the key N's DS and DNSKEY records can be
+ removed from their respective zones. In analogy with other rollover
+ methods, this is the removal time (Trem), given by:
+
+ Trem >= Tdea
+
+3.3.4. Interaction with Configured Trust Anchors
+
+ Although the preceding sections have been concerned with rolling KSKs
+ where the trust anchor is a DS record in the parent zone, zone
+ managers may want to take account of the possibility that some
+ validating resolvers may have configured trust anchors directly.
+
+ Rolling a configured trust anchor is dealt with in [RFC5011]. It
+ 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
+ "revoke" bit set) for some time after use.
+
+3.3.4.1. Addition of KSK
+
+ When the new key is introduced, the publication interval (Ipub) in
+ the Double-Signature and Double-RRset methods should also be subject
+ to the condition:
+
+ Ipub >= Dprp + max(30 days, TTLkey)
+
+ ... where the right hand side of the expression is the time taken for
+ the change to propagate to all nameservers for the zone plus the add
+ hold-down time defined in section 2.4.1 of [RFC5011].
+
+ In the Double-DS method, instead of the changing of the KSK RR being
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 23]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ instantaneous, there must now be a period of overlap. In other
+ words, the new KSK must be introduced into the zone at least:
+
+ DprpC + max(30 days, TTLkey)
+
+ ... before the switch is made.
+
+3.3.4.2. Removal of KSK
+
+ 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
+ time, instead of being declared "dead", it is revoked; the "revoke"
+ bit is set on the DNSKEY RR and is published in (and used to sign)
+ the DNSKEY RRset. The key is maintained in this state for the
+ "revoke" interval, Irev, given by:
+
+ Irev >= 30 days
+
+ ... 30 days being the [RFC5011] remove hold-down time. After this
+ time, the key is dead and can be removed from the zone.
+
+3.3.5. Introduction of First KSK
+
+ There is an additional consideration when introducing a KSK into a
+ zone for the first time, and that is that no validating resolver
+ should be in a position where it can access the trust anchor before
+ the KSK appears in the zone. To do so will cause it to declare the
+ zone to be bogus.
+
+ This is important: in the case of a secure parent, it means ensuring
+ that the DS record is not published in the parent zone until there is
+ no possibility that a validating resolver can obtain the record yet
+ not be able to obtain the corresponding DNSKEY. In the case of an
+ insecure parent, i.e. the initial creation of a new security apex, it
+ is not possible to guarantee this. It is up to the operator of the
+ validating resolver to wait for the new KSK to appear at all servers
+ for the zone before configuring the trust anchor.
+
+
+4. Standby Keys
+
+ Although keys will usually be rolled according to some regular
+ schedule, there may be occasions when an emergency rollover is
+ required, e.g. if the active key is suspected of being compromised.
+ The aim of the emergency rollover is to allow the zone to be re-
+ signed with a new key as soon as possible. As a key must be in the
+ ready state to sign the zone, having at least one additional key (a
+ standby key) in this state at all times will minimise delay.
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 24]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ In the case of a ZSK, a standby key only really makes sense with the
+ Pre-Publication method. A permanent standby DNSKEY RR should be
+ included in zone or successor keys could be introduced as soon as
+ possible after a key becomes active. Either way results in one or
+ more additional ZSKs in the DNSKEY RRset that can immediately be used
+ to sign the zone if the current key is compromised.
+
+ (Although in theory the mechanism could be used with both the Double-
+ Signature and Double-RRSIG methods, it would require pre-publication
+ of the signatures. Essentially, the standby key would be permanently
+ active, as it would have to be periodically used to renew signatures.
+ Zones would also permanently require two sets of signatures.)
+
+ It is also possible to have a standby KSK. The Double-Signature
+ method requires that the standby KSK be included in the DNSKEY RRset;
+ rolling the key then requires just the introduction of the DS record
+ in the parent. Note that the standby KSK should also be used to sign
+ the DNSKEY RRset. As the RRset and its signatures travel together,
+ merely adding the KSK without using it to sign the DNSKEY RRset does
+ not provide the desired time saving: for a KSK to be used in a
+ rollover the DNSKEY RRset must be signed with it, and this would
+ introduce a delay while the old RRset (not signed with the new key)
+ expires from caches.
+
+ The idea of a standby KSK in the Double-RRset rollover method
+ effectively means having two active keys (as the standby KSK and
+ associated DS record would both be published at the same time in
+ their respective zones).
+
+ Finally, in the Double-DS method of rolling a KSK, it is not a
+ standby key that is present, it is a standby DS record in the parent
+ zone.
+
+ 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
+ early as possible.
+
+
+5. Algorithm Considerations
+
+ The preceding sections have implicitly assumed that all keys and
+ signatures are created using a single algorithm. However, [RFC4035]
+ (section 2.4) states that "There MUST be an RRSIG for each RRset
+ using at least one DNSKEY of each algorithm in the zone apex DNSKEY
+ RRset".
+
+ Except in the case of an algorithm rollover - where the algorithms
+ used to create the signatures are being changed - there is no
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 25]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ relationship between the keys of different algorithms. This means
+ that they can be rolled independently of one another. In other
+ words, the key rollover logic described above should be run
+ separately for each algorithm; the union of the results is included
+ in the zone, which is signed using the active key for each algorithm.
+
+
+6. Limitation of Scope
+
+ This document represents current thinking at the time of publication.
+ However, the subject matter is evolving and it is more than likely
+ that this document will need to be revised in the future.
+
+ Some of the techniques and ideas that DNSSEC operators considering
+ differ from this those described in this document. Of note are
+ alternatives to the strict split into KSK and ZSK key roles and the
+ consequences for rollover logic from partial signing (i.e. when the
+ new key initially only signs a fraction of the zone while leaving
+ other signatures generated by the old key in place).
+
+ Furthermore, as noted in section 5, this document covers only rolling
+ keys of the same algorithm, it does not cover transition to/from/
+ addition/deletion of different algorithms. Algorithm rollovers will
+ require a separate document.
+
+ The reader is therefore reminded that DNSSEC is as of publication in
+ early stages of deployment, and best practices may further develop
+ over time.
+
+
+7. Summary
+
+ For ZSKs, "Pre-Publication" is generally considered to be the
+ preferred way of rolling keys. As shown in this document, the time
+ taken to roll is wholly dependent on parameters under the control of
+ the zone manager.
+
+ In contrast, "Double-RRset" is the most efficient method for KSK
+ rollover due to the ability to have new DS records and DNSKEY RRsets
+ propagate in parallel. The time taken to roll KSKs may depend on
+ factors related to the parent zone if the parent is signed. For
+ zones that intend to comply with the recommendations of [RFC5011], in
+ virtually all cases the rollover time will be determined by the
+ RFC5011 "add hold-down" and "remove hold-down" times. It should be
+ emphasized that this delay is a policy choice and not a function of
+ timing values and that it also requires changes to the rollover
+ process due to the need to manage revocation of trust anchors.
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 26]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Finally, the treatment of emergency key rollover is significantly
+ simplified by the introduction of standby keys as standard practice
+ during all types of rollovers.
+
+
+8. IANA Considerations
+
+ This memo includes no request to IANA.
+
+
+9. Security Considerations
+
+ This document does not introduce any new security issues beyond those
+ already discussed in [RFC4033], [RFC4034], [RFC4035] and [RFC5011].
+
+
+10. Acknowledgements
+
+ The authors gratefully acknowledge help and contributions from Roy
+ Arends, Matthijs Mekking and Wouter Wijngaards.
+
+
+11. Change History (To be removed on publication)
+
+ o draft-ietf-dnsop-dnssec-key-timing-02
+ * Significant re-wording of some sections.
+ * Removal of events noting change of state of predecessor key from
+ ZSK Double-RRSIG and Double-Signature methods.
+ * Change order of bullet points (and some wording) in section 1.1.
+ * Remove discussion of advantages and disadvantages of key roll
+ methods from section 2: draft is informative and does not give
+ recommendations.
+ * Removal of discussion of upper limit to retire time relationship
+ to signature lifetime.
+ * Remove timing details of first key in the zone and move
+ discussion of first signing of a zone to later in the document).
+ (Matthijs Mekking)
+ * Removal of redundant symbols from Appendix A.
+
+ o draft-ietf-dnsop-dnssec-key-timing-01
+ * Added section on limitation of scope.
+
+ o draft-ietf-dnsop-dnssec-key-timing-00
+ * Change to author contact details.
+
+ o draft-morris-dnsop-dnssec-key-timing-02
+ * General restructuring.
+ * Added descriptions of more rollovers (IETF-76 meeting).
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 27]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ * Improved description of key states and removed diagram.
+ * Provided simpler description of standby keys.
+ * Added section concerning first key in a zone.
+ * Moved [RFC5011] to a separate section.
+ * Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott Rose, Sion
+ Lloyd, Tony Finch).
+
+ o draft-morris-dnsop-dnssec-key-timing-01
+ * Use latest boilerplate for IPR text.
+ * List different ways to roll a KSK (acknowledgements to Mark
+ Andrews).
+ * Restructure to concentrate on key timing, not management
+ procedures.
+ * Change symbol notation (Diane Davidowicz and others).
+ * Added key state transition diagram (Diane Davidowicz).
+ * Corrected spelling, formatting, grammatical and style errors
+ (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
+ * Added note that in the case of multiple algorithms, the
+ signatures and rollovers for each algorithm can be considered as
+ more or less independent (Alfred Hoenes).
+ * Take account of the fact that signing a zone is not atomic
+ (Chris Thompson).
+ * Add section contrasting pre-publication rollover with double
+ signature rollover (Matthijs Mekking).
+ * Retained distinction between first and subsequent keys in
+ definition of initial publication interval (Matthijs Mekking).
+
+ o draft-morris-dnsop-dnssec-key-timing-00
+ Initial draft.
+
+
+12. References
+
+12.1. Normative References
+
+ [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.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 28]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Extensions", RFC 4035, March 2005.
+
+ [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
+ Trust Anchors", RFC 5011, September 2007.
+
+12.2. Informative References
+
+ [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ RFC 4641, September 2006.
+
+
+Appendix A. List of Symbols
+
+ The document defines a number of symbols, all of which are listed
+ here. All are of the form:
+
+ All symbols used in the text are of the form:
+
+ <TYPE><id><INST>
+
+ where:
+
+ <TYPE> is an upper-case character indicating what type the symbol is.
+ Defined types are:
+
+ D delay: interval that is a feature of the process
+
+ I interval between two events
+
+ L lifetime: interval set by the zone manager
+
+ T a point in time
+
+ TTL TTL of a record
+
+ I and T and TTL are self-explanatory. Like I, D, and L are time
+ 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
+ time occurs "retire interval" after the retire time), D, and L are
+ fixed intervals: a "D" interval (delay) is a feature of the process,
+ probably outside control of the zone manager, whereas an "L" interval
+ (lifetime) is chosen by the zone manager and is a feature of policy.
+
+ <id> is lower-case and defines what object or event the variable is
+ related to, e.g.
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 29]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ act activation
+
+ pub publication
+
+ ret retire
+
+ Finally, <INST> is a capital letter that distinguishes between the
+ same variable applying to different instances of an object and is one
+ of:
+
+ C child
+
+ G signature
+
+ K key
+
+ P parent
+
+ S successor
+
+ The list of variables used in the text is:
+
+ Dprp Propagation delay. The amount of time for a change made at
+ a master nameserver to propagate to all the slave
+ nameservers.
+
+ DprpC Propagation delay in the child zone.
+
+ DprpP Propagation delay in the parent zone.
+
+ Dreg Registration delay: the time taken for a DS record
+ submitted to a parent zone to appear in it. As a parent
+ zone is often managed by a different organisation to that
+ managing the child zone, the delays associated with passing
+ data between zones is captured by this term.
+
+ Dsgn Signing delay. After the introduction of a new ZSK, the
+ amount of time taken for all the RRs in the zone to be
+ signed with it.
+
+ Ipub Publication interval. The amount of time that must elapse
+ after the publication of a key before it can be assumed
+ that any resolvers that have the DNSKEY RRset cached have a
+ copy of this key.
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 30]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ 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.
+
+ Iret Retire interval. The amount of time that must elapse after
+ a key enters the retire state for any signatures created
+ with it to be purged from validating resolver caches.
+
+ Irev Revoke interval. The amount of time that a KSK must remain
+ published with the revoke bit set to satisfy [RFC5011]
+ considerations.
+
+ Lksk Lifetime of a key-signing key. This is the intended amount
+ of time for which this particular KSK is regarded as the
+ active KSK. Depending on when the key is rolled-over, the
+ actual lifetime may be longer or shorter than this.
+
+ Lzsk Lifetime of a zone-signing key. This is the intended
+ amount of time for which the ZSK is used to sign the zone.
+ Depending on when the key is rolled-over, the actual
+ lifetime may be longer or shorter than this.
+
+ 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.
+
+ Tdea Dead time of a key. Applicable only to ZSKs, this is the
+ time at which any record signatures held in validating
+ resolver caches are guaranteed to be created with the
+ successor key.
+
+ Tgen Generate time of a key. 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.
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 31]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ 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
+ starts being used to sign the zone.
+
+ Trdy Ready time of a key. The time at which it can be
+ guaranteed that validating resolvers that have key
+ 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.
+
+ Tsub Submission time - the time at which the DS record of a KSK
+ is submitted to the parent.
+
+ TsubS Submission time of the successor key.
+
+ TTLds Time to live of a DS record (in the parent zone).
+
+ TTLkey Time to live of a DNSKEY record.
+
+ TTLsig The maximum time to live of all the RRSIG records in the
+ zone that were created with the ZSK.
+
+
+Authors' Addresses
+
+ Stephen Morris
+ Internet Systems Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ Phone: +1 650 423 1300
+ Email: stephen@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 32]
+
+Internet-Draft DNSSEC Key Timing Considerations March 2011
+
+
+ Johan Ihren
+ Netnod
+ Franzengatan 5
+ Stockholm, SE-112 51
+ Sweden
+
+ Phone: +46 8615 8573
+ Email: johani@autonomica.se
+
+
+ John Dickinson
+ Sinodun Internet Technologies Ltd
+ Stables 4 Suite 11, Howbery Park
+ Wallingford, Oxfordshire OX10 8BA
+ UK
+
+ Phone: +44 1491 818120
+ Email: jad@sinodun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morris, et al. Expires September 11, 2011 [Page 33]
+