One document matched: draft-ietf-dnsop-dnssec-key-timing-05.xml
<?xml version="1.0"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC4033 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC5011 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY RFC6781 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6781.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<?rfc tocappendix="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<?rfc comments="no" ?>
<?rfc inline="yes" ?>
<rfc category="info" docName="draft-ietf-dnsop-dnssec-key-timing-05.txt" ipr="trust200902">
<!-- Revision: 03-3 -->
<front>
<title abbrev="Key Timing">DNSSEC Key Rollover Timing Considerations</title>
<author fullname="Stephen Morris" initials="S." surname="Morris">
<organization abbrev="ISC">Internet Systems Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<code>94063</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>stephen@isc.org</email>
<uri>http://www.isc.org</uri>
</address>
</author>
<author fullname="Johan Ihren" initials="J." surname="Ihren">
<organization>Netnod</organization>
<address>
<postal>
<street>Franzengatan 5</street>
<code>SE-112 51</code>
<city>Stockholm</city>
<region/>
<country>Sweden</country>
</postal>
<email>johani@netnod.se</email>
<uri>http://www.netnod.se</uri>
</address>
</author>
<author fullname="John Dickinson" initials="J." surname="Dickinson">
<organization abbrev="Sinodun">Sinodun Internet Technologies Ltd</organization>
<address>
<postal>
<street>Magdalen Centre</street>
<street>Oxford Science Park</street>
<street>Robert Robertson Avenue</street>
<city>Oxford</city>
<code>OX4 4GA</code>
<region>Oxfordshire</region>
<country>UK</country>
</postal>
<email>jad@sinodun.com</email>
<uri>http://www.sinodun.com</uri>
</address>
</author>
<author fullname="W. (Matthijs) Mekking" initials="W." surname="Mekking">
<organization abbrev="NLnet Labs">NLnet Labs</organization>
<address>
<postal>
<street>Science Park 400</street>
<city>Amsterdam</city>
<code>1098 XH</code>
<country>The Netherlands</country>
</postal>
<email>matthijs@nlnetlabs.nl</email>
<uri>http://www.nlnetlabs.nl</uri>
</address>
</author>
<date/>
<!-- Meta-data Declarations -->
<area>Operations & Management</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>dnssec</keyword>
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Key Rolling Considerations">
<t>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: </t>
<t>
<list style="symbols">
<t>DNSKEY records and associated information (such as the
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.</t>
<t>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.</t>
<t> 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. </t>
<t>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.)</t>
</list>
</t>
<t>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.</t>
<t>A high-level overview of key rollover can be found in
<xref target="RFC6781"/>. In contrast,
this document focuses on the low-level timing detail of
two classes of operations described there, the rollover
of zone-signing keys (ZSKs), and the rollover of key-signing keys
(KSKs).</t>
</section>
<section title="Types of Keys">
<t>Although DNSSEC validation treats all keys equally, <xref
target="RFC4033"/> recognises the broad classification of
ZSKs and KSKs. 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. </t>
<t> 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 an 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. </t>
<t> 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. </t>
</section>
<section title="Terminology">
<t> The terminology used in this document is as defined in
<xref target="RFC4033"/> and <xref target="RFC5011"/>. </t>
<t>A number of symbols are used to identify times,
intervals, etc. All are listed in <xref
target="list_of_symbols"/>.</t>
</section>
</section>
<section title="Rollover Methods">
<section title="ZSK Rollovers">
<t>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.</t>
<t>A ZSK can be rolled in one of three ways:</t>
<t>
<list style="symbols">
<t>Pre-Publication: described in <xref target="RFC6781"/>,
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.
<vspace blankLines="1"/>
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 be removed from the DNSKEY RRset. </t>
<t>Double-Signature: also mentioned in <xref
target="RFC6781"/>, 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 RRSIGs allows
at least one signature to be validated.
<vspace blankLines="1"/>
Once the signing process is complete and
enough time has elapsed to make sure that all validators that
have the DNSKEY and signatures in cache have both the old
and new information, the old key and signatures can be
removed from the zone. As before, during this period any
combination of DNSKEY RRset and RRSIGs will allow
validation of at least one signature.</t>
<t>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.
<vspace blankLines="1"/>
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.</t>
</list>
</t>
<t>Of the 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. It is also the
fastest, but suffers from increasing the size of the zone and
the size of responses.</t>
<t>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.</t>
<t>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. 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.</t>
</section>
<section title="KSK Rollovers">
<t>In the KSK case, there should not be a problem that a caching
validator does not have access to a particular signature that
corresponds to a valid KSK. The KSK is only used for one signature
(that over the DNSKEY RRset) and both the key and the signature
travel together. Instead, the issue is to ensure that the KSK is
trusted.</t>
<t>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 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, <xref target="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 <xref target="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.)</t>
<t>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.</t>
<t>Like the ZSK case, there are three methods for rolling a KSK:</t>
<t>
<list style="symbols">
<t>Double-KSK: 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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>In essence, Double-KSK means that the new KSK is introduced
first and used to sign the DNSKEY RRset. The DS record is changed,
and finally the old KSK removed. It limits interactions with
the parent to a minimum but, for the duration of the rollover,
the size of the DNSKEY RRset is increased.</t>
<t>With Double-DS, the order of operations is the other way
round: introduce the new DS, change the DNSKEY, then remove
the old DS. The size of the DNSKEY RRset is kept to a minimum,
but two interactions are required with the parent.</t>
<t>Finally, Double-RRset is the fastest way to roll the KSK,
but has the drawbacks of both of the other methods: a larger
DNSKEY RRset and two interactions with the parent.</t>
</section>
</section>
<section title="Key Rollover Timelines" anchor="rollover_timelines">
<section title="Key States">
<t>A DNSSEC key contributes two pieces of information to the
validation process:
the DNSKEY itself and the data created from it. In the case of the
validation of an RR, the data created from the DNSKEY is the
RRSIG. Where there is a need to validate a chain or trust,
the data created from the DNSKEY is the DS. In this section,
the term "associated data" refers to the RRSIGs created from a
DNSKEY when discussing a ZSK, or to the DNSKEY's corresponding
DS record when referring to a KSK.</t>
<t>During the rolling process, keys move through different states.
The defined states are:</t>
<t>
<list style="hanging" hangIndent="12">
<t hangText="Generated">Although keys may be created
immediately prior to first use, some implementations may find
it convenient to create a pool of keys in one operation and
draw from it as required. (Note: such a pre-generated pool
must be secured against surreptitious use.) Keys that have
been created but not yet used are said to be in the "Generated"
state.</t>
<t hangText="Published">A key enters the published state when
either it or its associated data first appears in the
appropriate zone.</t>
<t hangText="Ready">The DNSKEY or its associated data have
been published for long enough to guarantee that any previous
versions of the DNSKEY and/or associated data have expired
from caches.</t>
<t hangText="Active">The data is starting to be used for
validation. In the case of a ZSK, it means that the key is
now being be used to sign RRsets and that both it and
the created RRSIGs appear in the zone. In the case of a KSK,
it means that it is possible to use it to validate a DNSKEY
RRset as both the DNSKEY and DS records are present in their
relevant zones. Note that when this state is entered, it
may not be possible for validating resolvers to use the data
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
predecessor data instead. </t>
<t hangText="Retired">The data has ceased to be used for
validation. In the case of a ZSK, it means that the key
is no longer used to sign RRsets. In the case of a KSK,
it means that the successor DNSKEY and DS records are
in place. In both cases, the key (and its associated
data) can be removed as soon as it is safe to do so, i.e.
when all validating resolvers are able to use the new key and
associated data to validate the zone. However, until this
happens, the current key and associated data must remain in
their respective zones.</t>
<t hangText="Dead">The key and is associated data are present
in their respective zones, but there is no longer information
anywhere that require their presence for use in validation.
Hence they can be removed at any time.</t>
<t hangText="Removed">Both the DNSKEY and its associated
data have been removed from their respective zones.</t>
</list>
</t>
<t>There is one additional state, used where <xref
target="RFC5011"/> considerations are in effect (see <xref
target="trust_anchors"/>):</t>
<t>
<list style="hanging" hangIndent="12">
<t hangText="Revoked">The DNSKEY is published for a period
with the "revoke" bit set as a way of notifying validating
resolvers that have configured it as an <xref
target="RFC5011"/> trust anchor that
it is about to be removed from the zone.</t>
</list>
</t>
</section>
<section title="Zone-Signing Key Timelines" anchor="zsk">
<t>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).
</t>
<section title="Pre-Publication Method" anchor="zsk_prepublication">
<t>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 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.</t>
<t>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. </t>
<figure align="center" anchor="prepublication_zsk_rollover"
title="Timeline for a Pre-Publication ZSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N |<-Ipub->|<--->|<-------Lzsk------>|<-Iret->|<--->|
| | | | | | | |
Key N+1 | | | |<-Ipub->|<-->|<---Lzsk---- - -
| | | | | | | |
Key N Tpub Trdy Tact Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->]]>
</artwork>
</figure>
<t>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 currently active key-signing keys. The time at which this
occurs is the publication time (Tpub), and the key is
now said to be published. Note that the key is not yet used
to sign records. </t>
<t>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 RRset includes this key.</t>
<t>This interval is the publication interval (Ipub) and, for
the second or subsequent keys in the zone, is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = Dprp + TTLkey</t>
</list>
</t>
<t>Here, Dprp is the propagation delay - the time taken
for a change introduced at
the master to replicate to all name servers.
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.</t>
<t>(The case of introducing the first ZSK into the zone is
discussed in <xref target="first_key"/>.)</t>
<t>After a delay of Ipub, the key is said to be ready and
could be used to sign records. The time at which this event
occurs is key N's ready time (Trdy), which is given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy(N) = Tpub(N) + Ipub</t>
</list>
</t>
<t>Event 3: At some later time, the key starts being used to
sign RRsets. This point is the activation time (Tact) and after
this, key N is said to be active.</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact(N) >= Trdy(N)</t>
</list>
</t>
<t>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 zone, the successor key will need to be published at least
Ipub before it is activated. The publication time of key N+1 depends
on the activation time of key N: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tpub(N+1) <= Tact(N) + Lzsk - Ipub</t>
</list>
</t>
<t>Here, Lzsk is the length of time for which a ZSK will be
used (the ZSK lifetime). It should be noted that in the diagrams
the actual key lifetime is represented; this may differ slightly from
the intended lifetime set by key management policy.</t>
<t>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.</t>
<t>Event 6: When key N has been in use for an interval equal to
the ZSK lifetime, it is retired (i.e. it will never again be
used to generate 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:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret(N) = Tact(N) + Lzsk</t>
</list>
</t>
<t>It is also the activation time of the successor key N+1.
Note that operational considerations may cause key N to remain
in use for a longer (or shorter) time than the lifetime set
by the key management policy. </t>
<t>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 or held in caches. (It is
possible that a validating resolver could have an old RRSIG
record in the cache, but the old DNSKEY RRset has expired when it is
asked to provide both to a client. In this case the DNSKEY
RRset would need to be looked up again.) This means that
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:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = Dsgn + Dprp + TTLsig</t>
</list>
</t>
<t>Dsgn is the delay needed to ensure that all existing RRsets
have been re-signed with the new key.
Dprp is the propagation delay, required 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 created with the retiring key.</t>
<t>The time at which all RRSIG records created with this key
have expired from resolver caches is the dead time (Tdea),
given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea(N) = Tret(N) + Iret</t>
</list>
</t>
<t>... at which point the key is said to be dead.</t>
<t>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 current key-signing key. This time is
the removal time (Trem), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem(N) >= Tdea(N)</t>
</list>
</t>
<t>... at which time the key is said to be removed.</t>
</section>
<section title="Double-Signature Method" anchor="zsk_doublesignature">
<t>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.</t>
<t>The timeline for a double-signature rollover is shown below. The diagram
follows the convention described in <xref target="zsk_prepublication"/></t>
<figure align="center" anchor="doublesignature_zsk_rollover"
title="Timeline for a Double-Signature ZSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4|
| | | |
Key N |<-------Lzsk----------->|<--->|
| | | |
| |<--Iret-->| |
| | | |
Key N+1 | |<----Lzsk------- - -
| | | |
Key N Tact Tdea Trem
Key N+1 Tact
---- Time ---->]]>
</artwork>
</figure>
<t>Event 1: Key N is added to the DNSKEY RRset and is then
used to sign the zone; existing signatures in the zone are
not removed. The key is published and active: this is key N's
activation time (Tact), after which the key is said to be active.</t>
<t>Event 2: As the current key (key N) approaches the end of
its actual lifetime (Lzsk), the successor key (key N+1) is
introduced into the zone and starts being used to sign RRsets:
neither the current key nor the signatures created with it are
removed. The successor key is now also active. </t>
<t>
<list hangIndent="10" style="empty">
<t>Tact(N+1) = Tact(N) + Lzsk - Iret</t>
</list>
</t>
<t>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 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.</t>
<t>This takes Iret, the retire interval, given by the
expression:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = Dsgn + Dprp + max(TTLkey, TTLsig)</t>
</list>
</t>
<t>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 delay, required to guarantee that the updated
zone information has reached all slave servers.
The final term (the maximum of
TTLkey and TTLsig) is the period to wait for key and
signature data associated with key N to expire from
caches. (TTLkey is the TTL of the DNSKEY RRset and TTLsig
is the maximum TTL of all the RRSIG records in the zone
created with the ZSK. The two may be different: although
the TTL of an RRSIG is equal to the TTL of the RRs in the
associated RRset <xref target="RFC4034"/>, the DNSKEY RRset
only needs to be signed with the KSK.)</t>
<t>At the end of this interval, key N is said to be
dead. This occurs at the dead time (Tdea) so:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea(N) = Tact(N+1) + Iret</t>
</list>
</t>
<t>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), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem(N) >= Tdea(N)</t>
</list>
</t>
</section>
</section>
<section title="Key-Signing Key Rollover Timelines" anchor="ksk">
<t>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).
(The case of introducing the first KSK into the zone is discussed
in <xref target="first_key"/>.)</t>
<section title="Double-KSK Method">
<t>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.</t>
<t>The timeline for a Double-KSK rollover is shown below.
The diagram follows the convention described in
<xref target="zsk_prepublication"/>.</t>
<figure align="center" anchor="double_dnskey_ksk_rollover"
title="Timeline for a Double-KSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4|
| | | |
Key N |<-IpubC->|<--->|<-Dreg->|<-----Lksk--- - -
| | | |
Key N+1 | | | |
| | | |
Key N Tpub Trdy Tsbm Tact
Key N+1
---- Time ---->
(continued ...)
|5| |6| |7| |8| |9| |10|
| | | | | |
Key N - - --------------Lksk------->|<-Iret->|<----->|
| | | | | |
Key N+1 |<-IpubC->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tsbm Tact
---- Time (cont) ---->]]>
</artwork>
</figure>
<t>Event 1: Key N is introduced into the zone; it is added
to the DNSKEY RRset, which is then signed by all
currently active KSKs. (So at 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 of key N (Tpub); after this the key is said to
be published.</t>
<t>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 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.</t>
<t>The interval is the publication interval in the child zone (IpubC)
and is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + TTLkey</t>
</list>
</t>
<t>... 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 N's ready time, Trdy, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy(N) = Tpub(N) + IpubC</t>
</list>
</t>
<t>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 the submission time, Tsbm: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tsbm(N) >= Trdy(N)</t>
</list>
</t>
<t>Event 4: 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 key N (Tact):</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact(N) = Tsbm(N) + Dreg</t>
</list>
</t>
<t>... where Dreg is the registration delay, the time taken
after the DS record has been submitted to the parent zone
manager for it to be placed in the zone. (Parent zones are
often managed by different entities, and this term accounts
for the organisational overhead of 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.)</t>
<t>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 KSK lifetime, the successor KSK is
published in the zone. (As before, this means that the DNSKEY
RRset is
signed by all KSKs.) This time is the
publication time of the successor key N+1, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tpub(N+1) <= Tact(N) + Lksk - Dreg - IpubC</t>
</list>
</t>
<t>... where Lksk is the actual lifetime of the KSK, and Dreg
the registration delay.</t>
<t>Event 6: After an interval IpubC, key N+1
becomes ready (in that all caches that have a
copy of the DNSKEY RRset have a copy of this key). This time is
the ready time of the successor key N+1 (Trdy).</t>
<t>Event 7: At the submission time of the successor key N+1,
Tsbm(N+1), the DS
record corresponding to key N+1 is submitted to
the parent zone.</t>
<t>Event 8: The successor DS record is published in the
parent zone and the current DS record withdrawn. Key N
is said to be retired and the time at which this occurs
is Tret(N), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret(N) = Tsbm(N+1) + Dreg</t>
</list>
</t>
<t>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. This interval is the
retire interval, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = DprpP + TTLds</t>
</list>
</t>
<t>... where DprpP is the propagation delay in the parent
zone and TTLds the TTL of a DS record in the parent zone.</t>
<t>As the key is no longer used for anything, it is said to be dead.
This point is the dead time (Tdea), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea(N) = Tret(N) + Iret</t>
</list>
</t>
<t>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.</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem(N) >= Tdea(N)</t>
</list>
</t>
</section>
<section title="Double-DS Method">
<t>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.</t>
<t>The timeline for a Double-DS rollover is shown below.
The diagram follows the convention described in
<xref target="zsk_prepublication"/></t>
<figure align="center" anchor="double_ds_ksk_rollover"
title="Timeline for a Double-DS KSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Dreg->|<-IpubP->|<-->|<-------Lksk----- - -
| | | | |
Key N+1 | | | | |<--Dreg-- - -
| | | | |
Key N Tsbm Tpub Trdy Tact
Key N+1 Tsbm
---- Time ---->
(continued ...)
|6| |7| |8| |9| |10|
| | | | |
Key N - - -----Lksk--------->|<-Iret->|<---->|
| | | | |
Key N+1 - - --Dreg-->|<-IpubP->|<------>|<------Lksk------ - -
| | | | |
Key N Tret Tdea Trem
Key N+1 Tpub Trdy Tact
---- Time ---->]]>
</artwork>
</figure>
<t>Event 1: The DS RR is submitted to the parent zone for publication.
This time is the submission time, Tsbm.</t>
<t>Event 2: After the registration delay, Dreg, the DS
record is published in the parent zone. This is the
publication time (Tpub) of key N, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tpub(N) = Tsbm(N) + Dreg</t>
</list>
</t>
<t>As before, in practice Dreg will not be a fixed time. Instead,
the end of Dreg will be signalled by the appearance of the DS
record in the parent zone.</t>
<t>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 N, if introduced
into the DNSKEY RRset, could be used to validate the
zone. For this reason, this time is known as the ready
time, Trdy, and is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy(N) = Tpub(N) + IpubP</t>
</list>
</t>
<t>IpubP is the publication interval of the DS record
(in the parent zone) and is given by the expression:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubP = DprpP + TTLds</t>
</list>
</t>
<t>... where DprpP is the propagation delay for the parent
zone and TTLds the TTL assigned to DS records in that
zone. </t>
<t>Event 4: At some later time, the key rollover takes
place and the new key (key N) is introduced into the
DNSKEY RRset and used to sign it.
This time is key N's activation time (Tact) and at this
point key N is said to be active:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact(N) >= Trdy(N)</t>
</list>
</t>
<t>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 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 successor key. The time at which this occurs is the
submission time of the successor key N+1, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tsbm(N+1) <= Tact(N) + Lksk - IpubP - Dreg</t>
</list>
</t>
<t>... 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.</t>
<t>Event 6. After an interval Dreg, the successor DS record is
published in the zone.</t>
<t> 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.</t>
<t>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 with the new key. At this point, as both the old and
new DS records have been in the parent zone long enough to ensure
that they are in caches that contain the DS RRset, the zone
can be authenticated throughout the rollover. A validating
resolver can authenticate either the old or new KSK.</t>
<t>This time is the retire time (Tret) of key N, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret(N) = Tact(N) + Lksk</t>
</list>
</t>
<t>This is also the activation time of the successor key
N+1.</t>
<t>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: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea(N) = Tret(N) + Iret</t>
</list>
</t>
<t> ... where Iret is the retire interval of the
key, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = DprpC + TTLkey</t>
</list>
</t>
<t>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.</t>
<t>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:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem(N) >= Tdea(N)</t>
</list>
</t>
</section>
<section title="Double-RRset Method">
<t>In the Double-RRset rollover, the new DNSKEY and DS
records are 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.</t>
<t>The timeline for this rollover is shown below.
The diagram follows the convention described in
<xref target="zsk_prepublication"/></t>
<figure align="center" anchor="double_rrset_ksk_rollover"
title="Timeline for a Double-RRset KSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4| |5|
| | | | |
Key N |<-Ipub->|<-----Lksk----->|<------>|
| | | | |
Key N+1 | | |<-Ipub->|<------Lksk--- - -
| | | | |
Key N Tpub Tact Tret Trem
Key N+1 Tpub Tact
---- Time ---->]]>
</artwork>
</figure>
<t>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 corresponding DS record is submitted to the
parent zone for publication. This time is the publish time
for key N (Tpub) and the key is said to be published.</t>
<t>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 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.</t>
<t>The time at which this occurs is called the activation time of
key N (Tact), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact(N) = Tpub(N) + Ipub</t>
</list>
</t>
<t>... where Ipub is the composite publication interval for
the DNSKEY and DS records, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = max(IpubP, IpubC),</t>
</list>
</t>
<t>IpubP being the publication interval of the DS
record in the parent zone and
IpubC the publication interval of the DNSKEY in the child zone.
The parent zone's publication interval is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubP = Dreg + DprpP + TTLds</t>
</list>
</t>
<t>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.
</t>
<t>The child zone's publication interval is given by a similar equation:
</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + TTLkey</t>
</list>
</t>
<t>... where DprpC is the propagation delay in the child zone and
TTLkey the TTL of a DNSKEY record.
</t>
<t>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 DS record submitted to the parent) at a time
such that it becomes active when the current key has been
active for its actual lifetime, Lksk. This is the
publication time (Tpub) of the successor key, and is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tpub(N+1) <= Tact(N) + Lksk - Ipub</t>
</list>
</t>
<t>... where Lksk is the actual lifetime of the KSK and Ipub is
as defined above.</t>
<t> 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 the zone can be
validated with the new key. This is the activation time (Tact) of
the successor key N+1 and by analogy with other rollover
methods, it is also the dead time of key N:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea(N) = Tact(N) + Lksk</t>
</list>
</t>
<t>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 methods,
this is the removal time (Trem), given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem(N) >= Tdea(N)</t>
</list>
</t>
</section>
<section title="Interaction with Configured Trust Anchors" anchor="trust_anchors">
<t>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.</t>
<t>Rolling a configured trust anchor is dealt with in <xref
target="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.</t>
<section title="Addition of KSK">
<t>When the new key is introduced, the expression for the
publication interval of the DNSKEY(IpubC) in the Double-KSK and
Double-RRset methods is modified to:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC >= DprpC + max(Itrp, TTLkey)</t>
</list>
</t>
<t>... where the right hand side of the expression now
includes the "trust point" interval. This
term is the interval required to guarantee that
a resolver configured for the automatic update of keys from
a particular trust point will see at least two validated
DNSKEY RRsets containing the new key
(a requirement from <xref target="RFC5011"/>, section 2.4.1).
It is defined by the expression:
</t>
<t>
<list hangIndent="10" style="empty">
<t>Itrp >= (2 * queryInterval) + (n * retryTime)</t>
</list>
</t>
<t>... where queryInterval and retryTime are as defined in
section 2.3 of <xref target="RFC5011"/>. "n" is the total
number of retries needed by the resolver during the two
attempts to get the DNSKEY RRset.</t>
<t>The first term of the expression (2 * queryInterval)
represents the time to obtain two validated DNSKEY RRsets.
The second term (n * retryTime) is a safety margin, with
the value of "n" reflecting the degree of confidence in the communication
between a resolver and the trust point.</t>
<t>In the Double-DS method, instead of swapping the KSK RRs
in a single step, there must now be a period of overlap.
In other words, the new KSK must be introduced into the
zone at least:</t>
<t>
<list hangIndent="10" style="empty">
<t>DprpC + max(Itrp, TTLkey)</t>
</list>
</t>
<t>... before the switch is made.</t>
</section>
<section title="Removal of KSK">
<t>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 in the published
DNSKEY RR, and the DNSKEY RRset re-signed with the current
and revoked keys. The key is maintained in this state for the
"revoke" interval, Irev, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Irev >= 30 days</t>
</list>
</t>
<t>... 30 days being the <xref target="RFC5011"/> remove
hold-down time. After this time, the key is dead and can
be removed from the zone.</t>
</section>
</section>
<section title="Introduction of First Keys" anchor="first_key">
<t>There are no timing considerations associated with the
introduction 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 created.</t>
<t>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 is not able to obtain the
corresponding DNSKEY. In the case of an insecure parent,
i.e. the initial creation of a new security apex,
it 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.</t>
</section>
</section>
</section>
<section title="Standby Keys">
<t> 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. </t>
<t> 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 the 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.</t>
<t> (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.) </t>
<t>It is also possible to have a standby KSK.
The Double-KSK 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.</t>
<t>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).
</t>
<t>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.</t>
<t>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. </t>
</section>
<section title="Algorithm Considerations">
<t>The preceding sections have implicitly assumed that all keys
and signatures are created using a single algorithm. However,
<xref target="RFC4035"/> (section 2.4) requires that there
be an RRSIG for each RRset using at least one DNSKEY of each
algorithm in the zone apex DNSKEY RRset.</t>
<t>Except in the case of an algorithm rollover - where the
algorithms used to create the signatures are being changed -
there is no 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.</t>
</section>
<section title="Limitation of Scope">
<t>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.</t>
<t>Some of the techniques and ideas that DNSSEC operators are
considering differ from this those described in this document.
Of particular interest 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).</t>
<t>Furthermore, as noted in section 5, this document covers only
rolling keys of the same algorithm: it does not cover transitions
between algorithms. The timing issues
associated with algorithm rollovers will require a separate document.</t>
<t>The reader is therefore reminded that DNSSEC is, as of date
of publication, in the early stages of deployment, and best practices
may further develop over time.</t>
</section>
<section title="Summary">
<t> 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.</t>
<t> 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 <xref target="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.</t>
<t>Finally, the treatment of emergency key rollover is
significantly simplified by the introduction of standby keys as
standard practice during all types of rollovers. </t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This document does not introduce any new security issues
beyond those already discussed in <xref target="RFC4033"/>,
<xref target="RFC4034"/>, <xref target="RFC4035"/> and <xref
target="RFC5011"/>.</t>
</section>
<section title="Acknowledgements">
<t>The authors gratefully acknowledge help and contributions
from Roy Arends and Wouter Wijngaards.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!--?rfc
include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC4033; &RFC4034; &RFC4035; &RFC5011; &RFC6781;
</references>
<!--
<references title="Informative References">
</references>
-->
<section title="List of Symbols" anchor="list_of_symbols">
<t> The document defines a number of symbols, all of which are listed here. All are of the
form:</t>
<t>All symbols used in the text are of the form:</t>
<t>
<list hangIndent="10" style="empty">
<t><TYPE><id><ZONE></t>
</list>
</t>
<t> where:</t>
<t><TYPE> is an upper-case character indicating what type the symbol is. Defined
types are:</t>
<t>
<list hangIndent="10" style="hanging">
<t hangText="D">delay: interval that is a feature of the process</t>
<t hangText="I">interval between two events</t>
<t hangText="L">lifetime: interval set by the zone manager</t>
<t hangText="T">a point in time</t>
<t hangText="TTL">TTL of a record</t>
</list>
</t>
<t>I, T and TTL are self-explanatory. Like I, both D and L are time periods, but whereas I values are
intervals between two events (even 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. </t>
<t><id> is lower-case and defines what object or event the variable is related
to, e.g.,</t>
<t>
<list hangIndent="10" style="hanging">
<t hangText="act">activation</t>
<t hangText="pub">publication</t>
<t hangText="ret">retire</t>
</list>
</t>
<t><ZONE> is an optional capital letter that distinguishes between the same
variable applied to different zones and is one of:</t>
<t>
<list hangIndent="10" style="hanging">
<t hangText="C">child</t>
<t hangText="P">parent</t>
</list>
</t>
<t>Within the rollover descriptions, times may be suffixed by
a number in brackets indicating the instance of 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.</t>
<t>The list of variables used in the text given below.</t>
<t>
<list hangIndent="10" style="hanging">
<t hangText="Dprp">Propagation delay. The amount of time for a change made at a master
nameserver to propagate to all the slave nameservers.</t>
<t hangText="DprpC">Propagation delay in the child zone.</t>
<t hangText="DprpP">Propagation delay in the parent zone.</t>
<t hangText="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 organisations is captured by this term.</t>
<t hangText="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.</t>
<t hangText="Ipub">Publication interval. The amount of time
that must elapse after the publication of a DNSKEY and/or its
associated data before it can be assumed that any resolvers
that have the relevant RRset cached have a copy of the new
information.</t>
<t hangText="IpubC">Publication interval in the child zone.</t>
<t hangText="IpubP">Publication interval in the parent zone.</t>
<t hangText="Iret">Retire interval. The amount of time that must elapse after a DNSKEY
or associated data enters the retire state for any dependent information (e.g. RRSIG for a
ZSK) to be purged from validating resolver caches.</t>
<t hangText="Irev">Revoke interval. The amount of time that a KSK must remain published
with the revoke bit set to satisfy <xref target="RFC5011"/> considerations.</t>
<t hangText="Itrp">Trust-point interval. The amount of time that a trust anchor must be
published for to guarantee that a resolver configured for an automatic update of keys
will see the new key at least twice.
</t>
<t hangText="Lksk">Lifetime of a key-signing key. This is the actual amount of time for
which this particular KSK is regarded as the active KSK. Depending on when the key is
rolled-over, the actual lifetime may be longer or shorter than the intended key
lifetime indicated by management policy.</t>
<t hangText="Lzsk">Lifetime of a zone-signing key. This is the actual amount of time for
which the ZSK is used to sign the zone. Depending on when the key is rolled-over, the
actual lifetime may be longer or shorter than the intended key lifetime indicated by
management policy.</t>
<t hangText="Tact">Activation time. The time at which the key is regarded
as the principal key for the zone.</t>
<t hangText="Tdea">Dead time. The time at which any information
held in validating resolver caches is guaranteed to contain information related
to the successor key. At this point, the current key and its associated information
are not longed required for validation purposes.</t>
<t hangText="Tpub">Publication time. The time
that the key or associated data appears in the zone for the first time.</t>
<t hangText="Trem">Removal time. The time at which the key and
its associated information starts being removed from their respective zones.</t>
<t hangText="Tret">Retire time. The time at which successor information starts
being used.</t>
<t hangText="Trdy">Ready time. The time at which it can be guaranteed that
validating resolvers that have information about the key and/or associated data cached have a
copy of the new information.</t>
<t hangText="Tsbm">Submission time. The time at which the DS record of a KSK is submitted to
the parent zone.</t>
<t hangText="TTLds">Time to live of a DS record.</t>
<t hangText="TTLkey">Time to live of a DNSKEY record. (By implication, this is also the
time to live of the signatures on the DNSKEY RRset.)</t>
<t hangText="TTLsig">The maximum time to live of all the RRSIG records in the zone
that were created with the ZSK.</t>
</list>
</t>
</section>
<section title="Change History (To be removed on publication)">
<t>
<list style="symbols">
<t>
draft-ietf-dnsop-dnssec-key-timing-05
<vspace/>
* Some more renamings of "Double-Signature" KSK rollover to "Double-KSK".
<vspace/>
* Remove Tgen from diagrams.
<vspace/>
* Review by Richard Lamb.
<vspace/>
* Updated KSK rollover summary text.
<vspace/>
* Updated variable descriptions in the appendix.
</t>
<t>
draft-ietf-dnsop-dnssec-key-timing-04
<vspace/>
* Renamed to "DNSSEC Key Rollover Timing Considerations" to emphasise
that this draft concerns rollover timings.
<vspace/>
* Updated 4641bis reference to RFC 6781.
<vspace/>
* Add introductory paragraph to each rollover description summarising
its essential features.
<vspace/>
* Remove detailed description of double-RRSIG ZSK rollover. It is extremely
unlikely to be used in any practical situation.
<vspace/>
* "Double-Signature" KSK rollover renamed to "Double-KSK" to avoid confusion
with the ZSK rollover of the same name.
<vspace/>
* Removed section 2.3 (rollover summary) which just listed the order in which
records are published.
<vspace/>
* Matthijs Mekking added as co-author.
<vspace/>
* Changed Lzsk and Kzsk definitions: actual lifetime instead of intended lifetime.
<vspace/>
* Update diagrams and text to better reflect key states and key lifetimes.
</t>
<t>
draft-ietf-dnsop-dnssec-key-timing-03
<vspace/>
* Clarifications of and corrections to wording (Marc Lampo, Alfred Hoenes).
<vspace/>
* Updated timings related to trust anchor interaction (Matthijs Mekking).
<vspace/>
* Updated RFC 4641 reference to 4641bis (Alfred Hoenes).
<vspace/>
* Moved change history to end of document (Alfred Hoenes).
</t>
<t>
draft-ietf-dnsop-dnssec-key-timing-02
<vspace/>
* Significant re-wording of some sections.
<vspace/>
* Removal of events noting change of state of predecessor key from ZSK
Double-RRSIG and Double-Signature methods.
<vspace/>
* Change order of bullet points (and some wording) in section 1.1.
<vspace/>
* Remove discussion of advantages and disadvantages of key roll
methods from section 2: draft is informative and does not give
recommendations.
<vspace/>
* Removal of discussion of upper limit to retire time relationship to
signature lifetime.
<vspace/>
* 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)
<vspace/>
* Removal of redundant symbols from Appendix A.
</t>
<t>
draft-ietf-dnsop-dnssec-key-timing-01
<vspace/>
* Added section on limitation of scope.
</t>
<t>
draft-ietf-dnsop-dnssec-key-timing-00
<vspace/>
* Change to author contact details.
</t>
<t>
draft-morris-dnsop-dnssec-key-timing-02
<vspace/>
* General restructuring.
<vspace/>
* Added descriptions of more rollovers (IETF-76 meeting).
<vspace/>
* Improved description of key states and removed diagram.
<vspace/>
* Provided simpler description of standby keys.
<vspace/>
* Added section concerning first key in a zone.
<vspace/>
* Moved <xref target="RFC5011"/> to a separate section.
<vspace/>
* Various nits fixed (Alfred Hoenes, Jeremy Reed, Scott
Rose, Sion Lloyd, Tony Finch).
</t>
<t>
draft-morris-dnsop-dnssec-key-timing-01
<vspace/>
* Use latest boilerplate for IPR text.
<vspace/>
* List different ways to roll a KSK (acknowledgements
to Mark Andrews).
<vspace/>
* Restructure to concentrate on key timing, not
management procedures.
<vspace/>
* Change symbol notation (Diane Davidowicz and others).
<vspace/>
* Added key state transition diagram (Diane Davidowicz).
<vspace/>
* Corrected spelling, formatting, grammatical and style
errors (Diane Davidowicz, Alfred Hoenes and Jinmei Tatuya).
<vspace/>
* 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).
<vspace/>
* Take account of the fact that signing a zone is not
atomic (Chris Thompson).
<vspace/>
* Add section contrasting pre-publication rollover with
double signature rollover (Matthijs Mekking).
<vspace/>
* Retained distinction between first and subsequent keys
in definition of initial publication interval (Matthijs
Mekking).
</t>
<t>
draft-morris-dnsop-dnssec-key-timing-00
<vspace/>
Initial draft.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:50:26 |