One document matched: draft-ietf-dnsop-dnssec-key-timing-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- 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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2308 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4641 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4641.xml">
<!ENTITY RFC5011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5011.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.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="4"?>
<!-- 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-01.txt" ipr="trust200902">
<!-- Revision: 00.b -->
<front>
<title>DNSSEC Key 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>
<phone>+1 650 423 1300</phone>
<email>stephen@isc.org</email>
</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>
<phone>+46 8615 8573</phone>
<email>johani@autonomica.se</email>
</address>
</author>
<author fullname="John Dickinson" initials="J." surname="Dickinson">
<organization abbrev="Sinodun">Sinodun Internet Technologies Ltd</organization>
<address>
<postal>
<street>Stables 4 Suite 11, Howbery Park</street>
<city>Wallingford</city>
<code>OX10 8BA</code>
<region>Oxfordshire</region>
<country>UK</country>
</postal>
<phone>+44 1491 818120</phone>
<email>jad@sinodun.com</email>
</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
RRSIG records created with the key or the associated DS
records) are not only held at the authoritative
nameserver, they are also cached at client 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>A query for the key RRset returns all DNSKEY records in
the zone. As there is limited space in the UDP packet
(even with EDNS0 support), dead key records must be
periodically removed. (For the same reason, the number of
stand-by keys in the zone should be restricted to the
minimum required to support the key management
policy.)</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,
stand-by keys (additional keys over and above those used
to sign the zone) need to be present. </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>
</section>
<section title="Types of Keys">
<t>Although DNSSEC validation treats all keys equally, <xref
target="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 key set in the zone. 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
the validating resolver's 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 through 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> There are similarities in the rolling of ZSKs and KSKs:
replace the RRSIG (plus RR) by the DNSKEY and replace the
DNSKEY by the DS, and the ZSK rolling algorithms are virtually
the same as the KSK algorithms. However, there are a number of
differences, and for this reason the two types of rollovers
are described separately 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 large number of symbols are used to identify times,
intervals, etc. All are listed in <xref
target="list_of_symbols"/>.</t>
</section>
<!--
<section title="Requirements Language">
<t>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 <xref target="RFC2119"/>.</t>
</section>
-->
</section>
<section title="Rollover Methods">
<section title="ZSK Rollovers">
<t>A ZSK can be rolled in one of three ways:</t>
<t>
<list style="symbols">
<t>Pre-Publication. Described in <xref target="RFC4641"/>,
the new key is introduced into the DNSKEY RRset, leaving
the existing keys and signatures in place. This state of
affairs remains in place for long enough to ensure that
any DNSKEY RRsets cached in client validating resolvers
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 client was created with; clients
with a cached copy of the DNSKEY RRset will have a copy
containing 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
client 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. </t>
<t>Double-Signature. Also mentioned in <xref
target="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),
client 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.<vspace
blankLines="1"/> 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.</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
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 to have a copy of both signatures, the ZSK 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 three methods, Double-Signature is the simplest
conceptually - introduce the new key and new signatures, then
approximately one TTL later remove the old key and signatures.
The drawback of this method is a noticeable increase in the
size of the DNSSEC data, affecting both the overall size of
the zone and the size of the 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. However,
the amount of DNSSEC data is kept to a minimum which reduces
the impact on performance. </t>
<t>The Double-RRSIG combines the increase in data volume of
the Double-Signature method with the complexity of
Pre-Publication. It has few (if any) advantages and a
description is only included here for completeness.</t>
</section>
<section title="KSK Rollovers">
<t>In the ZSK case 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.</t>
<t>Trust in the KSK is either due to the existence of an
explicitly configured trust anchor in the validating resolver
or DS record in the parent zone (which is itself trusted). If
the former, <xref target="RFC5011"/> timings will be needed to
roll the keys. If the latter, 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. (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-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.) </t>
<t>Double-DS: the new DS record is published. After
waiting for this change to propagate into the caches of
all validating resolvers, 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 validating resolver caches, the old DNSKEY and
DS record are removed.</t>
</list>
</t>
<t>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.</t>
<t>The strategies have different advantages and disadvantages:</t>
<t>
<list style="symbols">
<t>Double-Signature minimizes the number of interactions
with the parent zone. However, for the period of the
rollover the DNSKEY RRset is signed with two KSKs, so
increasing the size of the response to a query for this
data.</t>
<t>Double-DS keeps the size of the DNSKEY RRset to a
minimum, but does require the additional administrative
overhead of two interactions with the parent to roll a
KSK. (Although this can be mitigated if the parent has
the ability for a child zone to schedule the withdrawal of
the old key at the same time as the introduction of the
new one.)</t>
<t>Finally, Double-RRset allows the rollover to be done in
roughly half the time of the other two methods; it also
supports policies that require a period of running with
old and new KSKs simultaneously. However, it does have the
disadvantages of both the other two methods - it requires
two signatures during the period of the rollover and two
interactions with the parent. </t>
</list>
</t>
</section>
<section title="Summary">
<t>The methods can be summarised as follows:</t>
<texttable anchor="method_comparison">
<ttcol align="left">ZSK Method</ttcol>
<ttcol align="left">KSK Method</ttcol>
<ttcol align="left">Description</ttcol>
<c>Pre-Publication</c>
<c>(not applicable)</c>
<c>Publish the DNSKEY before the RRSIG.</c>
<c>Double-Signature</c>
<c>Double-Signature</c>
<c>Publish the DNSKEY and RRSIG at same time. (For a KSK,
this happens before the DS is published.)</c>
<c>Double-RRSIG</c>
<c>(not applicable)</c>
<c>Publish RRSIG before the DNSKEY.</c>
<c>(not applicable)</c>
<c>Double-DS</c>
<c>Publish DS before the DNSKEY.</c>
<c>(not applicable)</c>
<c>Double-RRset</c>
<c>Publish DNSKEY and DS in parallel.</c>
<!-- <postamble>Applicability of rollover methods.</postamble> -->
</texttable>
</section>
</section>
<section title="Key Rollover Timelines">
<section title="Key States">
<t>During the rolling process, a key moves through different states. These states are:</t>
<t>
<list style="hanging" hangIndent="12">
<t hangText="Generated">The key has been created, but has
not yet been used for anything.</t>
<t hangText="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 resolver caches.<vspace blankLines="1"/> 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" should
be taken to mean "key or associated information".</t>
<t hangText="Ready">The key has been published for long
enough to guarantee that all caches that might contain a
copy of the key RRset have a copy that includes this
key.</t>
<t hangText="Active">The key is in the zone and has
started to be used to sign RRsets or authenticate the
DNSKEY RRset. Note that when this state is entered, it
might not be possible for every validating resolver to use
the key for validation: 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. </t>
<t hangText="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. </t>
<t hangText="Dead">The key is published in the zone but
there is no information anywhere that requires its
presence.</t>
<t hangText="Removed">The key has been removed from the
zone.</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 key is published for a period
with the "revoke" bit set as a way of notifying validating
resolvers that have configured it as a trust anchor that
it is about to be removed from the zone.</t>
</list>
</t>
</section>
<section title="Zone-Signing Key Timelines" anchor="zsk">
<section title="Pre-Publication Method" anchor="zsk_prepublication">
<t>The following diagram shows the time line of a particular
ZSK and its replacement by its successor using the
Pre-Publication method. Time increases along the horizontal
scale from left to right and the vertical lines indicate
events in the life of the key. The events are numbered;
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| |9|
| | | | | | | | |
Key N | |<-Ipub->|<--->|<-------Lzsk----->|<-Iret->|<--->|
| | | | | | | | |
Key N+1 | | | | |<-Ipub->|<->|<---Lzsk-- - -
| | | | | | | | |
Tgen Tpub Trdy Tact TpubS Tret Tdea Trem
---- Time ---->
]]>
</artwork>
</figure>
<t>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 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.</t>
<t>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. </t>
<t>Event 3: before it can be used, the key must be published
for long enough to guarantee that any resolver that has a
copy of the DNSKEY RRset from the zone 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>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
any 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
time taken for existing DNSKEY records to expire from the
caches of downstream validating resolvers, regardless of the
nameserver from which they were retrieved. </t>
<t>In the case of the first key in the zone, Ipub is
slightly different because it is not information about a
DNSKEY RRset that may be cached, it is information about its
absence. In this case:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = Dprp + Ingc</t>
</list>
</t>
<t>where Ingc is the negative cache interval from the zone's
SOA record, calculated according to <xref target="RFC2308"/>
as the minimum of the TTL of the SOA record itself (TTLsoa),
and the "minimum" field in the record's parameters (SOAmin),
i.e.</t>
<t>
<list hangIndent="10" style="empty">
<t>Ingc = min(TTLsoa, SOAmin)</t>
</list>
</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 the key's ready time (Trdy), which is given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy = Tpub + Ipub</t>
</list>
</t>
<t>Event 4: at some later time, the key starts being used to
sign RRsets. This point is the active time (Tact) and after
this, the key is said to be active.</t>
<t>Event 5: while this key is active, 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
used. Denoting the publication time of the successor key by
TpubS, then: </t>
<t>
<list hangIndent="10" style="empty">
<t>TpubS <= Tact + 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 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. </t>
<t>Event 6: while the key N is still active, its successor
becomes ready. From this time onwards, it could be used to
sign the zone.</t>
<t>Event 7: at some point the decision is made to start
signing the zone using the successor key. This will be when
the current key has been in use for an interval equal to the
ZSK lifetime, hence:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret = Tact + Lzsk</t>
</list>
</t>
<t>This point in time is the retire time (Tret) of key N;
after this the key is said to be retired. (This time is also
the point at which the successor key becomes active.) </t>
<t>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 resolver caches. (It is
possible that a 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:</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 (as
described above) the propagation delay, required to
guarantee that the updated zone information has reached all
slave servers, and TTLsig is the TTL of the RRSIG
records.</t>
<t>(It should be noted that an upper limit on the retire
interval is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = Lsig + Dskw</t>
</list>
</t>
<t>where Lsig is the lifetime of a signature (i.e. the
interval between the time the signature was created and the
signature end time), and Dskw is the clock skew - the
maximum difference in time between the server and a
validating resolver. The reasoning here is that whatever
happens, a key only has to be available while any signatures
created with it are valid. Wherever a signature record is
held - published in the zone and/or held in a resolver cache
- it won't be valid for longer than Lsig after it was
created. The Dskw term is present to account for the fact
that the signature end time is an absolute time rather than
interval, and systems may not agree exactly about the
time.)</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 = Tret + Iret</t>
</list>
</t>
<t>...at which point the key is said to be dead.</t>
<t>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:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</t>
</list>
</t>
<t>...at which time the key is said to be removed.</t>
</section>
<section title="Double-Signature Method">
<t>In the Double-Signature method, both the new key and
signatures created using it are introduced at the same
time. After a period during which this information
propagates to validating resolver caches, the old key and
signature are removed. The time line for the method is shown
below:</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| |5| |6|
| | | | | |
Key N | |<-------Lzsk------>|<-----Iret----->| |
| | | | | |
Key N+1 | | | |<----------Lzsk------- - -
| | | | | |
Tgen Tact Tret Tdea Trem
---- Time ---->
]]>
</artwork>
</figure>
<t>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 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.</t>
<t>Event 2: key N is added to the DNSKEY RRset and is
immediately used to sign the zone; existing signatures in
the zone are not removed. This is the active time (Tact) and
the key is said to be active.</t>
<t>Event 3: at some time later, the predecessor key (key
N-1) and its signatures can be withdrawn from the zone. (The
timing of key removal is discussed further in the
description of event 5.) </t>
<t>Event 4: the successor key (key N+1) is introduced into
the zone and starts being used to sign RRsets. The successor
is key is now active and the current key (key N) is said to
be retired. This time is the retire time of the key (Tret);
it is also the active time of the successor key
(TactS). </t>
<t>
<list hangIndent="10" style="empty">
<t>Tret = Tact + Lzsk</t>
</list>
</t>
<t>Event 5: before key N can be withdrawn from the zone, all
RRsets that need to be signed must have been signed by the
successor key (as a result, all these RRsets are now signed
twice, once by key N and once by its successor) and the
information must have reached all validating resolvers that
may have RRsets from this zone cached. </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 time taken to sign the zone with
the new key and Dprp is the propagation delay. The final
term is the period to wait for old key and signature data to
expire from caches. After 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 = Tret + Iret</t>
</list>
</t>
<t>Event 6: at some later time key N and its signatures can
be removed from the zone. This is the removal time Trem,
given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</t>
</list>
</t>
</section>
<section title="Double-RRSIG Method">
<t>As noted above, "Double-Signature" is simultaneous
rollover of both signature and key. The time line for a
pure Double-Signature ZSK rollover (the Double-RRSIG method)
- where new signatures are introduced, the key changed, and
finally the old signatures removed - is shown below:</t>
<figure align="center" anchor="doublerrsig_zsk_rollover"
title="Timeline for a Double-Signature ZSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1||2| |3| |4||5| |6||7| |8||9| |10| |11|
| | | | | | | | | | |
Key N | |<-Dsgn->| | |<-----------Lzsk-------->|<-Iret->| |
| |<---IpubG-->| |<-IpubK->| | | | | |
| | | | | | | | | | |
Key N+1 | | | | | | |<-IpubG->| | | |
| | | | | | | | | | |
Tgen Tpub Trdy Tact TpubS TrdyS Tret Tdea Trem
---- Time ---->
]]>
</artwork>
</figure>
<t>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 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.</t>
<t>Event 2: key N is used to sign the zone but existing
signatures are retained. Although the new ZSK is not
published in the zone at this point, for analogy with the
other ZSK rollover methods and because this is the first
time that key information is visible (albeit indirectly
through the created signatures) this time is called the
publish time (Tpub).</t>
<t>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
existing key and once by the (still-absent) key N.</t>
<t>Event 4: there is now a delay while the this information
reaches all validating resolvers that may have RRsets from
the zone cached. This interval is given by the
expression:</t>
<t>
<list hangIndent="10" style="empty">
<t>Dprp + TTLsig</t>
</list>
</t>
<t>...comprising the delay for the information to propagate
through the nameserver infrastructure plus the time taken
for signature information to expire from caches.</t>
<t>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.</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy = Tpub + IpubG</t>
</list>
</t>
<t>where</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubG = Dsgn + Dprp + TTLsig</t>
</list>
</t>
<t>Event 5: at some later time the predecessor key is
removed and the key N added to the DNSKEY RRset. As all the
RRs have signatures created by the old and new keys, the
records can still be authenticated. This time is the active
time (Tact) and the key is now said to be active.</t>
<t>Event 6: After IpubK - the publication interval of the
key - the newly added DNSKEY RRset has propagated through to
all validating resolvers. At this point the old signatures
can be removed from the zone. IpubK is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubK = Dprp + TTLkey</t>
</list>
</t>
<t>Event 7: as before, at some later time 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 so that key N can be replaced after it has been
active for its scheduled lifetime. This occurs at TpubS (the
publication time of the successor), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>TpubS <= Tact + Lzsk - IpubG</t>
</list>
</t>
<t>Event 8: the signatures have propagated through the zone
and the new key could be added to the zone. This time is the
ready time of the successor (TrdyS).</t>
<t>
<list hangIndent="10" style="empty">
<t>TrdyS = TpubS + IpubG</t>
</list>
</t>
<t>... where IpubG is as defined above.</t>
<t>Event 9: at some later time key N is removed from the
zone and the successor key added. This is the retire time
of the key (Tret).</t>
<t>Event 10: 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 occurs is the
dead time (Tdea), given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea = Tret + Iret</t>
</list>
</t>
<t>... where Iret is the retire interval, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = IpubK</t>
</list>
</t>
<t>Event 11: At some later time the signatures can be
removed from the zone. Although the key has is not longer in
the zone, this is information associated with it and so the
time can be regarded as the key's remove time (Trem), given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</t>
</list>
</t>
</section>
</section>
<section title="Key-Signing Key Rollover Timelines" anchor="ksk">
<section title="Double-Signature Method">
<t>The Double-Signature method (also knows as the
double-DNSKEY method) involves introducing the new KSK to
the zone and waiting until its presence has been registered
by all validating resolvers. At this point, the DS record in
the parent is changed. Once that change has propagated to
all validating resolvers, the old KSK is removed.</t>
<t> The timing diagram for such a rollover is:</t>
<figure align="center" anchor="double_dnskey_ksk_rollover"
title="Timeline for a Double-Signature KSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4| |5| |6|
| | | | | |
Key N | |<-Ipub->|<--->|<-Dreg->|<---------Lksk--- - -
| | | | | |
Key N+1 | | | | | |
| | | | | |
Tgen Tpub Trdy Tsub Tact
---- Time ---->
(continued...)
|7| |8| |9| |10| |11| |12|
| | | | | |
Key N - - -------------Lksk------->|<-Iret->| |
| | | | | |
Key N+1 |<-Ipub->|<--->|<-Dreg->|<--------Lksk----- - -
| | | | | |
TpubS TrdyS TsubS Tret Tdea Trem
---- Time (cont) ---->
]]>
</artwork>
</figure>
<t>Event 1: key N is generated at time Tgen. As before,
although there is no reason why the key cannot be generated
immediately prior to publication, some implementations may
find it convenient to create a central pool of keys and draw
from it. For this reason, it is again shown as a separate
event.</t>
<t>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.</t>
<t>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 from the zone 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 (Ipub) and, for
the second or subsequent KSKs in the zone, is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = Dprp + TTLkey</t>
</list>
</t>
<t>... where Dprp is the propagation delay for the zone and
TTLkey the TTL for the DNSKEY RRset. The time at which this
occurs is the key's ready time, Trdy, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy = Tpub + Ipub</t>
</list>
</t>
<t>Event 4: at some later time, the DS RR corresponding to
the new KSK is submitted to the parent zone for
publication. This time is the submission time, Tsub. </t>
<t>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, it is the active time of the key:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact = Tsub + Dreg</t>
</list>
</t>
<t>... 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
of the organisational overhead of transferring a
record.)</t>
<t>Event 6: at some time later, all validating resolvers
that have the DS RRset cached will have a copy that includes
the new DS record. For the second or subsequent DS records,
this interval is given by the expression:</t>
<t>
<list hangIndent="10" style="empty">
<t>DprpP + TTLds</t>
</list>
</t>
<t>... where DprpP is the propagation delay in the parent
zone and TTLds the TTL assigned to DS records in that
zone. </t>
<t>In the case of the first DS record for the zone in
question, the expression is slightly different because it is
not information about a DS RRset that may be cached, it is
information about its absence. In this case, the interval
is:</t>
<t>
<list hangIndent="10" style="empty">
<t>DprpP + IngcP</t>
</list>
</t>
<t>where IngcP is the negative cache interval from the
zone's SOA record, calculated according to <xref
target="RFC2308"/> as the minimum of the TTL of the parent
SOA record itself (TTLsoaP), and the "minimum" field in the
record's parameters (SOAminP), i.e.</t>
<t>
<list hangIndent="10" style="empty">
<t>IngcP = min(TTLsoaP, SOAminP)</t>
</list>
</t>
<t>Event 7: 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
introduced into the zone and is used to sign the DNSKEY
RRset. (As before, this means that the DNSKEY RRset is
signed by both the current and successor KSK.) This is the
publication time of the successor key, TpubS.</t>
<t>Event 8: after an interval Ipub, the successor key
becomes ready (in that all validating resolvers that have a
copy of the DNSKEY RRset have a copy of this key). This is
the successor ready time, TrdyS.</t>
<t>Event 9: at the successor submission time (TsubS), the DS
record corresponding to the successor key is submitted to
the parent zone.</t>
<t>Event 10: 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:</t>
<t>The relationships between these times are:</t>
<t>
<list hangIndent="10" style="empty">
<t>TpubS <= Tact + Lksk - Dreg - Ipub</t>
<t>Tret = Tact + Lksk</t>
</list>
</t>
<t>... where Lksk is the scheduled lifetime of the KSK.</t>
<t>Event 11: key N must remain in the zone until any
validators that have the DS RRset cached have a copy of the
DS RRset 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.</t>
<t>As the key is no longer used for anything, it can also be
said to be dead, in which case: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea = Tret + Iret</t>
</list>
</t>
<t>Event 12: at some later time, key N is removed from the
zone (at the remove time Trem); the key is now said to be
removed.</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</t>
</list>
</t>
</section>
<section title="Double-DS Method">
<t>The Double-DS method is the reverse of the
Double-Signature method is that it is the DS record that is
pre-published (in the parent), and not the DNSKEY.</t>
<t>The timeline for the key rollover is shown below: </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| |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 ---->
]]>
</artwork>
</figure>
<t>Event 1: key N is generated at time Tgen. As before,
although there is no reason why the key cannot be generated
immediately prior to publication, some implementations may
find it convenient to create a central pool of keys and draw
from it. For this reason, it is again shown as a separate
event.</t>
<t>Event 2: the DS record corresponding to key N is
submitted for publication in the parent zone. This time is
the submission time (Tsub).</t>
<t>Event 3: after the registration delay, Dreg, the DS
record is published in the parent zone. This is the
publication time Tpub, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tpub = Tsub + Dreg</t>
</list>
</t>
<t>Event 4: at some later time, any validating resolver that
has copies of the DS RRset in its cache 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:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy = Tpub + IpubP</t>
</list>
</t>
<t>IpubP is the parent publication interval 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 in the parent
zone and TTLds the TTL assigned to DS records in that
zone. </t>
<t>Event 5: at some later time, the key rollover takes
place. The predecessor key is withdrawn from the DNSKEY
RRset and the new key (key N) introduced and used to sign
the RRset.</t>
<t>As both DS records have been in the parent zone long
enough to ensure that they are in the cache of any
validating resolvers that have the DS RRset cached, the zone
can be authenticated throughout the rollover - either the
resolver has a copy of the DNSKEY RRset (and associated
RRSIGs) authenticated by the predecessor key, or it has a
copy of the updated RRset authenticated with the new
key.</t>
<t>This time is the key's active time (Tact) and at this
point the key is said to be active.</t>
<t>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 validating resolver that has
DS records in its cache will 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:</t>
<t>
<list hangIndent="10" style="empty">
<t>TsubS <= Tact + Lksk - IpubP - Dreg</t>
</list>
</t>
<t>... where Lksk is the lifetime of the KSK.</t>
<t> Event 7: the successor key (key N+1) enters the ready
state i.e. its DS record is now in the caches of all
validating resolvers that have the parent DS RRset
cached. (This is the ready time of the successor,
TrdyS.)</t>
<t> Event 8: when the current key has been active for its
lifetime (Lksk), the current key is removed from the DNSKEY
RRset and the successor key added; the RRset is then signed
with the successor key. This point is the retire time of the
key, Tret, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret = Tact + Lksk</t>
</list>
</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. This is called the dead time, Tdea, and is
given by: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea = Tret + Iret</t>
</list>
</t>
<t> ... where Iret is the retire interval, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = Dprp + TTLkey</t>
</list>
</t>
<t>As before, this term includes the time taken to propagate
the RRset change through the master-slave hierarchy and the
time take 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. This is the removal time (Trem), given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</t>
</list>
</t>
</section>
<section title="Double-RRset Method">
<t>In the Double-RRset method, both the DS and DNSKEY
records are changed at the same time, so for a period the
zone can be authenticated with either key. The advantage of
this method is its applicability in cases where zone
management policy requires overlap of authentication keys
during a roll.</t>
<t>The timeline for this rollover is shown below: </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| |6| |7|
| | | | | | |
Key N | |<-Dreg->|<-----Lksk----->|<-Iret->| |
| | | | | | |
Key N+1 | | | |<-Dreg->|<-----Lksk-- - -
| | | | | | |
Tgen Tpub Tact TpubS Tret Tdea Trem
---- Time ---->
]]>
</artwork>
</figure>
<t>Event 1: key N is created at time Tgen and thereby
immediately becomes generated. As before, although there is
no reason why the key cannot be generated immediately prior
to publication, some implementations may find it convenient
to create a central pool of keys and draw from it. For this
reason, it is again shown as a separate event.</t>
<t>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.</t>
<t>Event 3: after Dreg, the registration delay, the DS
record is published in the parent zone. At this point, the
zones have all the information needed for a validating
resolver to authenticate the zone, although the information
may not yet have reached all validating resolver
caches. This time is the active time (Tact) and the key is
said to be active.</t>
<t>
<list hangIndent="10" style="empty">
<t>Tact = Tpub + Dreg</t>
</list>
</t>
<t>Event 4: at some point we need to give thought to key
replacement. The successor key 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 given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>TpubS <= Tact + Lksk - Dreg</t>
</list>
</t>
<t>... where Lksk is the lifetime of the KSK.</t>
<t> Event 5: the successor key's DS record appears in the
parent zone and the successor key becomes active. At this
point, the current key becomes retired. This occurs at Tret,
given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret = Tact + Lksk</t>
</list>
</t>
<t>Event 6: the current DNSKEY and DS record must be
retained in the zones until any any validating resolver that
has cached the DNSKEY and/or DS RRsets will have a copy of
the data for the successor key. At this point the current
key information is dead, as any validating resolver can
perform authentication using the successor key. This is the
dead time, Tdea, given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tdea = Tret + Iret</t>
</list>
</t>
<t>... where Iret is the retire interval. This depends on
how long both the successor DNSKEY and DS records take to
propagate through the nameserver infrastructure and thence
into validator caches. These delays are the publication
intervals of the child and parent zones respectively, so a
suitable expression for Iret is:</t>
<t>
<list hangIndent="10" style="empty">
<t>Iret = max(IpubP, IpubC)</t>
</list>
</t>
<t>IpubC is the publication interval of the DNSKEY in the
child zone, IpubP that of the DS record in the parent.</t>
<t>The child term comprises two parts - the time taken for
the introduction of the DNSKEY record to be propagated to
the downstream secondary servers (= DprpC, the child
propagation delay) and the time taken for information about
the DNSKEY RRset to expire from the validating resolver
cache, i.e.</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + TTLkey</t>
</list>
</t>
<t>TTLkey is the TTL for a DNSKEY record in the child
zone. The parent term is similar:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubP = DprpP + TTLds</t>
</list>
</t>
<t>DprpP the propagation delay in the parent zone and TTLds
the TTL for a DS record in the parent zone.</t>
<t>Event 7: at some later time, the DNSKEY record can be
removed from the child zone and a request can be made to
remove the DS record from the parent zone. This is the
removal time, Trem and is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trem >= Tdea</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. The Double-Signature and Double-RRset
methods can be adapted to include <xref target="RFC5011"/>
recommendations so that the rollover will also be signalled
to validating resolvers with configured trust anchors. (The
recommendations are not suitable for the Double-DS
method. Introducing the new key early and retaining the old
key after use effectively converts it into a form of
Double-RRset.)</t>
<section title="Addition of KSK">
<t>When the new key is introduced, the publication
interval (Ipub) in the Double-Signature method should also
be subject to the condition:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub >= max(30 days, TTLkey)</t>
</list>
</t>
<t>... where the right had side of the expression is the
add hold-down time defined in section 2.4.1 of <xref
target="RFC5011"/>.</t>
<t>In the Double-RRSIG method, the key should not be
regarded as being active until the add hold-down time has
passed. In other words, the following condition should be
enforced: </t>
<t>
<list hangIndent="10" style="empty">
<t>Tact >= Tpub + max(30 days, TTLkey)</t>
</list>
</t>
<t>(Effectively, this means extending the lifetime of the
key by an appropriate amount.)</t>
</section>
<section title="Removal of KSK">
<t>The timeline for the removal of the key in both methods
is modified by introducing a new state, "revoked". When
the key reaches the end of the retire period, 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:</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 when convenient.</t>
</section>
</section>
<section title="Introduction of First KSK">
<t>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 the validating resolver to declare
the zone to be bogus. </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 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
important to not configure trust anchors in validating
resolvers until the DNSKEY RRset has had sufficient time to
propagate. In both cases, this time is the trust anchor
availability time (Ttaa) given by: </t>
<t>
<list hangIndent="10" style="empty">
<t>Ttaa >= Tpub + IpubC</t>
</list>
</t>
<t>where</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + TTLkeyC</t>
</list>
</t>
<t>or</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + IngcC</t>
</list>
</t>
<t>The first expression applies if there was previously a
DNSKEY RRset in the child zone, the expression for IpubC
including the TTLkeyC term to account for the time taken for
that RRset to expire from caches. (It is possible that the
zone was signed but that the trust anchor had not been
submitted to the parent.)</t>
<t>If the introduction of the KSK caused the appearance of
the first DNSKEY RRset in the child zone, the second
expression applies in which the TTLkeyC term is replaced by
Ingc to allow for the effect of negative caching.</t>
<t>As before, IngcC is the negative cache interval from the
child zone's SOA record, calculated according to <xref
target="RFC2308"/> as the minimum of the TTL of the SOA
record itself (TTLsoaC), and the "minimum" field in the
record's parameters (SOAminC), i.e.</t>
<t>
<list hangIndent="10" style="empty">
<t>IngcC = min(TTLsoaC, SOAminC)</t>
</list>
</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 zone or successor keys could be introduced
as soon as possible after a key becomes active. Either way
results in an additional ZSK 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, something that could have a performance
impact in large zones.) </t>
<t> A standby key can also be used with the Double-Signature and
Double-DS methods of rolling a KSK. (The idea of a standby key
in the Double-RRset effectively means having two active keys.)
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
DNSKEY should also be used to sign the DNSKEY RRset. As the
RRset and its signatures travel together, merely adding the
DNSKEY does not provide the desired time saving; to be used in a
rollover requires that the DNSKEY RRset be signed with the
standby key, and this introduces a delay whilst the RRset and
its signatures propagate to the caches of validating
resolvers. There is no time advantage over introducing a new
DNSKEY and signing the RRset with it at the same time.) </t>
<t>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 introduced as a permanent standby, 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) states that "There MUST
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
thinking about 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).</t>
<t>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 algorithm. Algorithm
rollovers will require a separate document.</t>
<t>The reader is therefore reminded that DNSSEC is as of
publication in early stages of deployment, and best practices
will likely change in the near term.</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 stand-by 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>
<section title="Change History">
<t>
<list style="symbols">
<t>draft-ietf-dnsop-dnssec-key-timing-00 <vspace/>
* Added section on limitation of scope.</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>
</middle>
<back>
<references title="Normative References">
<!--?rfc
include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
<!-- &RFC2119; --> &RFC2308; &RFC4033; &RFC4034; &RFC4035; &RFC5011; </references>
<references title="Informative References">
<!--?rfc
include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC4641; </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><INST></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="SOA">parameter related to SOA RR</t>
<t hangText="T">a point in time</t>
<t hangText="TTL">TTL of a record</t>
</list>
</t>
<t>T and I are self-explanatory. D, and L are also 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.
An "L" interval (lifetime) is chosen by the zone manager and is a feature of policy. A "D"
interval (delay) is a feature of the process, probably outside control of the zone manager.
SOA and TTL are used just because they are common terms.</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">active</t>
<t hangText="ngc">negative cache</t>
<t hangText="pub">publication</t>
</list>
</t>
<t>Finally, <INST> is a capital letter that distinguishes between the same
variable applying to different instances of an object and is one of:</t>
<t>
<list hangIndent="10" style="hanging">
<t hangText="C">child</t>
<t hangText="G">signature</t>
<t hangText="K">key</t>
<t hangText="P">parent</t>
<t hangText="S">successor</t>
</list>
</t>
<t>The list of variables used in the text is:</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. 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.</t>
<t hangText="Dskw">Clock skew. The maximum difference in time between the signing system
and the resolver.</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="Ingc">Negative cache interval.</t>
<t hangText="IngcP">Negative cache interval of the child zone.</t>
<t hangText="IngcP">Negative cache interval of the parent zone.</t>
<t hangText="Ipub">Publication interval. The amount of time that must elapse after the
publication of a key before it can be considered to have entered the ready state.</t>
<t hangText="IpubC">Publication interval in the child zone.</t>
<t hangText="IpubG">Publication interval for the signature.</t>
<t hangText="IpubK">Publication interval for the key.</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 key enters
the retire state for any signatures created with it 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="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.</t>
<t hangText="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.</t>
<t hangText="Lsig">Lifetime of a signature: the difference in time between the signature's
expiration time and the time at which the signature was created. (Note that this is not
the difference between the signature's expiration and inception times: the latter is
usually set a small amount of time before the signature is created to allow for clock
skew between the signing system and the validating resolver.)</t>
<t hangText="SOAmin">Value of the "minimum" field from an SOA record.</t>
<t hangText="SOAminC">Value of the "minimum" field from an SOA record in the child zone.</t>
<t hangText="SOAminP">Value of the "minimum" field from an SOA record in the parent zone.</t>
<t hangText="Tact">Active time of the key; the time at which the key is regarded as the
principal key for the zone.</t>
<t hangText="TactS">Active time of the successor key.</t>
<t hangText="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.</t>
<t hangText="Tgen">Generate time of a key. The time that a key is created.</t>
<t hangText="Tpub">Publish time of a key. The time that a key appears in a zone for the
first time.</t>
<t hangText="TpubS">Publish time of the successor key.</t>
<t hangText="Trem">Removal time of a key. The time at which a key is removed from the
zone.</t>
<t hangText="Tret">Retire time of a key. The time at which a successor key starts being
used to sign the zone.</t>
<t hangText="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.) </t>
<t hangText="TrdyS">Ready time of a successor key.</t>
<t hangText="Tsub">Submit time - the time at which the DS record of a KSK is submitted to
the parent.</t>
<t hangText="TsubS">Submit time of the successor key.</t>
<t hangText="TTLds">Time to live of a DS record (in the parent zone).</t>
<t hangText="TTLkey">Time to live of a DNSKEY record.</t>
<t hangText="TTLkeyC">Time to live of a DNSKEY record in the child zone.</t>
<t hangText="TTLsoa">Time to live of a SOA record.</t>
<t hangText="TTLsoaC">Time to live of a SOA record in the child zone.</t>
<t hangText="TTLsoaP">Time to live of a SOA record in the parent zone.</t>
<t hangText="TTLsig">Time to live of an RRSIG record.</t>
<t hangText="Ttaa">Trust anchor availability time. The time at which a trust anchor record
can be made available when a KSK is first introduced into a zone.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:49:53 |