One document matched: draft-morris-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 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-morris-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>Nominet</organization>
<address>
<postal>
<street>Minerva House, Edmund Halley Road</street>
<city>Oxford</city>
<code>OX4 4DQ</code>
<region/>
<country>UK</country>
</postal>
<phone>+44 1865 332211</phone>
<email>stephen@nominet.org.uk</email>
</address>
</author>
<author fullname="Johan Ihren" initials="J." surname="Ihren">
<organization>Autonomica</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/>
<address>
<postal>
<street>Stables 4 Suite 10, Howbery Park</street>
<city>Wallingford</city>
<code>OX10 8BA</code>
<region/>
<country>UK</country>
</postal>
<phone/>
<email>jad@jadickinson.co.uk</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 timlines for the key rollover and explicitly
identifies the relationships between the various parameters affecting the process. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<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 reasons. In order to implement a key rollover, the keys need to
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>Key and signature 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
validator may try to validate a signature retrieved from a cache with a key obtained
separately.</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>
<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>
</list>
</t>
<t>Management policy, e.g. how long a key is used for, also needs to be taken into account.
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. In other words, although key management
logic enforces policy, it may not enforce it strictly. </t>
<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 in this document 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="Types of Key Rollover">
<t> As noted in the introduction, client resolvers may cache both key and signature RRsets.
This means that when validating a signature record (or passing both RRsets to a client who
has issued a query with the CD bit set), an RRSIG just read from an authoritative server may
be paired with a cached DNSKEY or vice-versa. For the validation to be successful, the
DNSKEY and RRSIG must be consistent.</t>
<t> Key rollover - the replacement of the key use to sign the zone with another - involves
changing the contents of the DNSKEY RRset and re- signing the zone (so changing the RRSIG
records). In order for a RR to be validated, at least one RRSIG in the associated signature
RRset must be able to be validated by one of the keys in the DNSKEY RRset. To ensure
uninterrupted security, the aim must be to ensure that this condition is true at all stages
during the rollover process.</t>
<t>Two ways to achieve this goal are the pre-publication method and the double signature
method.</t>
<section title="Pre-Publication Method">
<t>In pre-publication, 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 resolvers contain both keys. At that point,
the zone can be signed 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 will have a copy of the DNSKEY RRset containing both the old and new keys.</t>
<t>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,
the old key can be removed from the DNSKEY RRset because there will be no signatures
anywhere created using it. </t>
</section>
<section title="Double-Signature Method">
<t>Double-signature, as the name implies, 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 and RRSIG RRsets allows at least one signature to be validated.</t>
<t>Once the signing process is complete and enough time has elapsed to allow all old DNSKEY
and RRSIG RRsets to expire from caches, the old key and signatures can be removed from the
zone. As before, during this period any combination of DNSKEY and RRSIG RRsets will allow
validation of at least one signature.</t>
</section>
<section title="Comparison of Rollover Methods">
<t>Of the two methods, double-signature is the simplest conceptually - introduce the new key
and new signatures, then (roughly) 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. This
affects both the overall size of the zone and the size of the responses.</t>
<t>Pre-publication is more complex - introduce the new key, one TTL later sign the records,
and one TTL after that remove the old key. However, the amount of DNSSEC data is kept to a
minimum, hence reducing the impact on performance. </t>
</section>
<section title="Timing Considerations">
<t>The rest of this paper describes the timing considerations related to the rolling of
zone-signing keys (ZSKs) and key-signing keys (KSKs). Owing to the increase in the amount
of DNSSEC data in the double-signature method, the pre-publication approach is preferred
for rollover of ZSKs. However, in the case of KSK rollovers, the size increase is
negligible and hence the complexity of pre-publication is not justified.</t>
<t>While this combination is the most common choice of rollover logic, there is nothing to
preclude other combinations should the situation demand it. The rest of this document
describes ZSK and KSK rollover timelines for the common case.</t>
</section>
</section>
<section title="Zone-Signing Keys" anchor="zsk">
<section title="Key Timeline" anchor="zsk_timeline">
<t>The following diagram shows the time line of a particular ZSK (zone-signing key) and its
replacement by its successor. 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="zsk_timeline_figure" title="Timeline for a 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 key
N 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>The 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 take 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 validators, 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 can 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
activation time (Tact) and after this, the key is said to be in the active state.</t>
<t>Event 5: while this key is active, thought must be given to its successor. 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 lives for slightly more or
less than Lzsk. </t>
<t>Event 6: while the current ZSK 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 validator. 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 expire 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>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>...and the key is said to be in the removed state.</t>
</section>
<section title="Key States">
<t>An alternative way of considering the key timeline is to regard the key as moving through
a set of states, the state transitions being determined by time. The state transition
diagram is linear and is shown in <xref target="zsk_key_states"/>:</t>
<figure align="center" anchor="zsk_key_states" title="ZSK State Diagram.">
<preamble/>
<artwork align="center">
<![CDATA[
+-----------+ +-----------+ +-----------+
Start ---->| Generated |----->| Published |----->| Ready |
Tgen +-----------+ Tpub +-----------+ Trdy +-----------+
|
+-----------+ |
+------------| Active |<-----------+
| Tret +-----------+ Tact
V
+-----------+ +-----------+ +-----------+
| Retired |----->| Dead |----->| Removed |
+-----------+ Tdea +-----------+ Trem +-----------+
]]>
</artwork>
</figure>
<t> The states are:</t>
<t>
<list style="hanging" hangIndent="12">
<t hangText="Generated">The key has been created.</t>
<t hangText="Published">The DNSKEY record is published in the zone, but resolvers may
have earlier versions of the DNSKEY RRset in their cache.</t>
<t hangText="Ready">The key has been published for long enough to guarantee that all
cached versions of the zone's DNSKEY RRset contain this key.</t>
<t hangText="Active">The key is in the zone and is being used to sign RRsets.</t>
<t hangText="Retired">The key is in the zone but is no longer being used to sign RRsets.
However, there may still be RRSIG records in caches that were created with this key.</t>
<t hangText="Dead">The key is published in the zone but there are no RRSIGs in existence
created with this key.</t>
<t hangText="Removed">The key has been removed from the zone.</t>
</list>
</t>
</section>
<section title="Stand-By Zone-Signing Keys" anchor="stand_by_zsks">
<t>Although ZSKs will usually be rolled according to some regular schedule, there may be
occasions when an emergency ZSK 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 at least one stand-by ZSK in this state at all times will minimise
delay. </t>
<section title="Stand-By Key Scheduling" anchor="emergency_key_replacement">
<t>One way to achieve this is to regard successor keys as stand-by keys for emergency
rollovers and to introduce them in the zone as early as possible. A modification of
<xref target="zsk_timeline_figure"/> illustrates this:</t>
<figure align="center" anchor="zsk_timeline_figure_emergency"
title="Timeline showing stand-by key replacement.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4|
| | | |
Key N - - - -----Lzsk---------->| |
| | | |
Key N+1 - --------------------->|<----Lzsk----->|
| | | |
Key N+2 |<-Ipub->|<---------------------->|<--Lzsk-- - -
| | | |
---- Time ---->
]]>
</artwork>
</figure>
<t>In this figure, it is assumed that key N is initially in the active state and that key
N+1 is in the ready state. Key N+1 is the successor to key N but is regarded as the
stand-by key for an emergency re-signing until the time comes to use it to sign the
zone.</t>
<t>Event 1: At least Ipub before key N's retire time, key N+2 is published in the zone.</t>
<t>Event 2: key N+2 moves into the ready state.</t>
<t>Event 3: key N is retired and key N+1 becomes active (as described in <xref
target="zsk_timeline"/>, events 7 - 9). Key N+2 is now regarded as
the stand-by key.</t>
<t>Event 4: key N+1 is retired and key N+2 becomes the current key. By this time, key N+3
will have been published and be in the ready state.</t>
<t> The above illustrates one way of handling stand-by keys for emergency use. An equally
valid alternative would be to have a permanent stand-by key. In this scheme, a key is
published in the zone but, unless it needs to be used in an emergency, is never used to
sign it. Instead, active keys are replaced by their successors as shown in <xref
target="zsk_timeline_figure"/>. </t>
</section>
<section title="Number of Stand-By Keys">
<t> An emergency key rollover could be required at any time. Referring back to <xref
target="zsk_timeline_figure_emergency"/>, should an emergency rollover be required
between events 2 and 3, the sequence would happen as previously described: there is a
already key (key N+2) ready to take over as the stand-by key when the current stand-by
key becomes active. In the worst case though, it may be required that the system run
without an stand-by key for a while. For example, if a key rollover was required between
events 3 and 4 in <xref target="zsk_timeline_figure_emergency"/>, the timeline would
look like: </t>
<figure align="center" anchor="zsk_timeline_figure_emergency2"
title="Timeline showing emergency key rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|3a| |3b|
| |
Key N+1 - ---Lzsk--->| |
| |
Key N+2 - ---------->|<----------Lzsk---- - -
| |
Key N+3 |<-Ipub->|<-------- - -
| |
---- Time ---->
]]>
</artwork>
</figure>
<t>(The interval shown above lies between events 3 and 4 in <xref
target="zsk_timeline_figure_emergency"/>, the events being labelled 3a and 3b to
highlight this.)</t>
<t>Here it is assumed that key N+1 is initially in the active state and that the single
stand-by key (N+2) is in the ready state. It is well before the active key's retire
time, so there are only these two ZSKs in the zone. The events are:</t>
<t>Event 3a: an emergency ZSK rollover is required. Key N+1 is retired and key N+2 becomes
active. At this time, key N+3 (which will ultimately become the new stand-by key) is
published in the zone.</t>
<t>Event 3b: key N+3 moves into the ready state, after which it can be used to replace key
N+1 should the need arise.</t>
<t> Between events 3a and 3b however, only the active key (key N+2) can be used to sign
the zone. If a second emergency arises in this interval, the active key cannot be
replaced: key rollover must wait until the new stand-by key (N+3) becomes ready. Of
course, this can be mitigated by having a number of stand-by keys available, but how
many is a matter of policy; there is a need to weigh the likelihood of a key compromise
against the number of keys required. </t>
</section>
</section>
</section>
<section title="Key-Signing Keys">
<section title="Introduction">
<t> There are three significant differences between key-signing keys (KSKs) and ZSKs: </t>
<t>
<list style="numbers">
<t>In the ZSK case the issue for the validator 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 and the signature travel together. Instead, the issue is to ensure
that the KSK is trusted. <vspace blankLines="1"/> Trust in the KSK is either due to
the existence of a DS record in the parent (which is itsef trusted), or the KSK being
explicitly configured as a trust anchor for the validator. Hence the additional two
differences:</t>
<t>A KSK rollover algorithm may need to involve the parent zone in the addition and
removal of DS records.</t>
<t>KSKs may be configured as so-called "trust anchors" in validating resolvers.</t>
</list>
</t>
<t>These differences have the following implications for KSK rollovers:</t>
<t>
<list style="numbers">
<t>The rollover logic must ensure that validators are able to validate the DNSKEY RRset
throughout the rollover process - either through updates to the chain of trust from
the parent zone or through updates to the trust anchor configuration.</t>
<t>Timings are not wholly within the control of the zone manager, in that the time taken
to publish the DS records depends on the policies and procedures of the parent zone. A
consequence of this is that the interdependence of the parent DS and child DNSKEY
records means that when a new key is introduced, for a period downstream validators
might have inconsistent data, i.e. the DS record without the DNSKEY record or
vice-versa. Although this is valid state according to <xref target="RFC4035"/>, the
information cannot be used for validation until the validator has both components.</t>
<t>Securely removing such KSKs from the zone requires a mechanism for communicating this
information to any validators that may have the KSK configured as a trust-anchor. The
typical method would be by publishing the revoked key as described in <xref
target="RFC5011"/>.</t>
</list>
</t>
<t>There are some differences in the sequence of events between the cases of a zone where a
KSK is authenticated via a DS record in the parent zone and one where it is authenticated
by a trust anchor configured into a validator. These will be highlighted as
appropriate.</t>
</section>
<section title="Parent Zone Considerations">
<t>If (as is the usual case) the parent and child zones are managed by different entities,
the timing of some of the steps in the KSK rollover operation may be subject to
uncertainty.</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.</t>
<t>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>
</section>
<section title="Rollover Strategies">
<t>When the parent zone is secured, there are several different ways to roll a KSK whilst
ensuring that the zones do not go insecure or bogus in the process: </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 DNSKEY 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 validator caches, the old key is removed from the DNSKEY
RRset.</t>
<t>Double DS: the new DS record is published. After waiting for this change to propagate
into the caches of all validators, 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 validator 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 then the new DS
(for this KSK). With "Double DS" it is the other way around. Finally, Double RRset does
both updates more or less in parallel.</t>
<t>Of the three methods, the double RRset method is preferred because:</t>
<t>
<list style="symbols">
<t>It allows the rollover to be done in the shortest time.</t>
<t>It can support policies that require a period of running with old and new KSKs
simultaneously.</t>
</list>
</t>
</section>
<section title="Key Timeline">
<t>The timeline for the key rollover is shown below: </t>
<figure align="center" anchor="ksk_timeline_figure" title="Timeline for a KSK rollover.">
<preamble/>
<artwork align="center">
<![CDATA[
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N | |<-Ipub->|<-->|<-------Lksk------->|<-Iret->|
| | | | | | | |
Key N+1 | | | | |<-Ipub->|<--->|<---Lksk-- - -
| | | | | | | |
Tgen Tpub Trdy Tact TpubS TrdyS Tret Trem
---- Time ---->
]]>
</artwork>
</figure>
<t>Event 1: key N is generated at time Tgen and enters the generate state. As before,
although there is no reason why the key cannot be generated immediately prior to
publication, some implementations may find its 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 this time the corresponding DS record is made available. If the
parent zone is secure, this means submitting the DS record to the parent zone for
publication; if not, it is distributed by some mechanism to allow validators to configure
it as a trust anchor. This time is the publish time (Tpub) and the KSK is said to be in
the published state.</t>
<t>Event 3: after some time (the publication interval, Ipub), any validator that has copies
of the DNSKEY and/or DS RRsets in its cache will have a copy of the data for key N. This
point is the ready time and is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Trdy = Tpub + Ipub</t>
</list>
</t>
<t>Regarding the associated DS record, there are now two cases to consider, where the parent
is signed and where the parent is not signed:</t>
<t>Event 3 (parent signed): In the case of the KSK, the publication interval depends on the
publication interval of both the DNSKEY record and the DS record. These are independent,
so a suitable expression for Ipub is:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = max(IpubC, IpubP)</t>
</list>
</t>
<t>IpubC is the publication interval in the child zone and IpubP that of the parent.</t>
<t>The child term comprises two parts - the time taken for the introduction of the DNSKEY
record to be registered on the downstream secondary servers (= DprpC, the child
propagation delay) and the time taken for information about the DNSKEY RRset to expire
from the validator cache, i.e.</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubC = DprpC + TTLkeyC</t>
</list>
</t>
<t>(TTLkeyC is the TTL for a DNSKEY record in the child zone.)</t>
<t>The parent term is similar, but also includes the time taken for the DS record to be
included in the parent zone after the request has been made. In other words:</t>
<t>
<list hangIndent="10" style="empty">
<t>IpubP = Dreg + DprpP + TTLds</t>
</list>
</t>
<t>Dreg is the registration delay, which is the time taken between the submission of the DS
record to the parent zone and its publication in the zone. DprpP the propagation delay in
the parent zone and TTLds the TTL for a DS record.</t>
<t>Throughout the introduction of the two RRs, the zone can be validated by by the existing
KSK and DS record. However, there are special considerations regarding the first KSK in a
zone, and these are discussed below.</t>
<t>Event 3 (parent not signed): if the parent is not signed then there is no parent
publication interval (theoretically the DS record could be configured in a validator
immediately it is made available), in which case the minimumn value of the publication
interval is given by:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub = IpubC</t>
</list>
</t>
<t>Event 3 (common): In both cases, if the management policy is to support <xref
target="RFC5011"/>, there is also the additional condition that the new key needs to be
published for at least as long as the RFC5011 add hold-down time, defined in that document
as "30 days or the expiration time of the original TTL of the first trust point DNSKEY
RRSet that contained the new key, whichever is greater".</t>
<t>This can be expressed as the condition:</t>
<t>
<list hangIndent="10" style="empty">
<t>Ipub >= max(30 days, TTLkey)</t>
</list>
</t>
<t>At Trdy, as the key has already been used to sign the DNSKEY RRset, the key is also
active in that all other KSKs could be withdrawn from the zone at this point and the zone
would still be valid. However, while a predecessor key is active, it is convenient to
regard the successor key as merely being ready.</t>
<t>Event 4: at some later time, the predecessor key is withdrawn from the zone and, in the
absence of any emergency keys, key N becomes the only KSK for the zone. The key is said to
be active, and this time is the active time (Tact).</t>
<t>Event 5: as with the ZSK, at some point we need to give thought to key replacement. The
successor key must be introduced into the zone at a time such that when the current key is
withdrawn, any validator that has key information (DNSKEY and/or DS records) in its cache
will have data about the successor key.</t>
<t>As before, this interval is the publication interval, Ipub. Denoting the publication time
of the successor key as TpubS, we get:</t>
<t>
<list hangIndent="10" style="empty">
<t>TpubS <= Tact + Lksk - Ipub</t>
</list>
</t>
<t>... where Lksk is the lifetime of the KSK.</t>
<t> Event 6: the successor key (key N+1) enters the ready state. This occurs at TrdyS, given
by:</t>
<t>
<list hangIndent="10" style="empty">
<t>TrdyS = TpubS + Ipub</t>
</list>
</t>
<t>Event 7: at some time after that a decision will be made to retire the current key (key
N). This will be when the current key has been active for its lifetime (Lksk). At this
point, the retire time, the successor key becomes active and the current key is said to be
retired:</t>
<t>
<list hangIndent="10" style="empty">
<t>Tret = Tact + Lksk</t>
</list>
</t>
<t>(... with the obvious condition that Tret >= TrdyS.)</t>
<t>If the management policy is to support <xref target="RFC5011"/>, the retired key should
now have the revoke bit set and be included in the DNSKEY RRset. the revoked key should
also be used to sign it.</t>
<t>Event 8: at some later time, the DNSKEY record can be removed from the child zone. If
there is a secure parent, 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 = Tret + Iret</t>
</list>
</t>
<t>where, as before, Iret is the retire interval. This will be zero unless <xref
target="RFC5011"/> is being followed, in which case Iret will be equal to the RFC5011
remove hold-down time value of 30 days.</t>
<t>Notes:</t>
<t>
<list style="numbers">
<t>In the case of a ZSK, as pre-publication is the method of choice, only one key at a
time is used to sign the zone. Therefore, when the active ZSK is retired, there may be
copies of signatures created using it in the caches of downstream validators. For this
reason, a copy of the ZSK has to be kept in the zone until all cached signatures have
expired. <vspace blankLines="1"/> With a KSK - where double RRset is the method of
choice - both the active key and the successor key sign the DNSKEY RRset. By the time
the successor becomes active, any validator with the DNSKEY RRset in its cache has a
copy of the successor key. Therefore as soon as the active key is retired, it can be
removed from the zone - there is no retire interval (unless <xref target="RFC5011"/>
is being followed) or dead time (although for completeness, and in analogy with the
ZSK, a dead time could be defined by Tdea = Trem).</t>
<t>There is an additional consideration when introducing a KSK into a zone for the first
time, and that is that no validator can be in a position where it can access the trust
anchor before the KSK appears in the zone. To do so will cause the validator to
declare the zone to be bogus. </t>
</list>
</t>
<t>The second point 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 validator 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 validators 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. 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 one to allow for the effect of negative caching.</t>
</section>
<section title="Key States">
<t>The key states for a KSK during the rollover are identical to those in <xref
target="zsk_key_states"/>.</t>
</section>
<section title="Stand-By Key-Signing Keys">
<t>In the same way that additional ZSKs are kept in a ready state in the zone to act as
emergency keys, additional KSKs need to be available in the ready state for the same
reason. The number of stand-by keys kept available is a matter of key management policy,
and the logic for the introduction of stand-by keys into the zone follows the same
reasoning as that given in <xref target="stand_by_zsks"/> on the introduction of
stand-by ZSKs. </t>
</section>
</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 changes - there is no relationship between the keys of different
algorithms. This means that they can be rolled independently of one another. (Indeed, the
keys for each algorithm could, if desired, have different TTLs.) 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="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 and remove
hold-down times. It should be emphasised 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 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-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/> * Restucture 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 Hones 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
Hones). <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>
<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="L">lifetime: calculated interval set by the zone manager</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 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="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="DprpP">Propagation delay in the parent zone.</t>
<t hangText="Dreg">Registration delay. As a parent zone are often managed by a different
organisation to the one under consideration, 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="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="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 validator caches.</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 validator.)</t>
<t hangText="SOAmin">Value of the "minimum" field from an SOA record.</t>
<t hangText="Tact">Active time of the key. For a ZSK, the time that they key is first used
to sign the zone. For a KSK, the time at which this key is regarded as being the
principal KSK for the zone.</t>
<t hangText="Tdea">Dead time of a key. Applicable only to ZSKs, this is the time at which
any record signatures held in validator 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 a
validators that have key information from this zone cached have a copy of this key in
their cache. (In the case of KSKs, should the validators 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="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="TTLsig">Time to live of an RRSIG record.</t>
<t hangText="Ttsa">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 11:53:23 |