Internet Engineering Task Force S. Morris
Internet-Draft Nominet
Intended status: Informational J. Ihren
Expires: August 21, 2009 Autonomica
J. Dickinson
February 17, 2009
DNSSEC Key Timing Considerations
draft-morris-dnsop-dnssec-key-timing-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Morris, et al. Expires August 21, 2009 [Page 1]
Internet-Draft DNSSEC Key Timing Considerations February 2009
Abstract
RFC 4641 gives a detailed overview of the operational considerations
involved in running a DNSSEC-secured zone, including key rollovers.
This document expands on the previous work, and discusses timing
considerations in greater depth. It explicitly identifies the
relationships between the various time parameters, and gives a
suggested algorithm for key rollover in a DNSSEC-secured zone.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Zone-Signing Keys . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Emergency Zone-Signing Keys . . . . . . . . . . . . . . . 7
2.2.1. Emergency Key Replacement . . . . . . . . . . . . . . 7
2.2.2. Emergency Key Use . . . . . . . . . . . . . . . . . . 8
2.3. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Actual and Estimated Times . . . . . . . . . . . . . . 9
2.3.2. Practical Timing Considerations . . . . . . . . . . . 9
2.3.3. ZSK Management Procedure . . . . . . . . . . . . . . . 10
3. Key-Signing Keys . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Key Timeline . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Emergency Key-Signing Keys . . . . . . . . . . . . . . . . 15
3.3. Key Rollover . . . . . . . . . . . . . . . . . . . . . . . 15
3.4. Key Rollover Logic . . . . . . . . . . . . . . . . . . . . 15
3.4.1. Actual and Estimated Times . . . . . . . . . . . . . . 15
3.4.2. Practical Timing Considerations . . . . . . . . . . . 16
3.4.3. KSK Management Procedure . . . . . . . . . . . . . . . 16
4. Running the Key Management Procedures . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. List of Symbols . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Morris, et al. Expires August 21, 2009 [Page 2]
Internet-Draft DNSSEC Key Timing Considerations February 2009
1. Introduction
When a zone is secured with DNSSEC, [RFC4641] recommends that the
keys used to sign the zone are periodically replaced (or "rolled
over"). In order to implement this recommendation, the keys need to
be managed in order to allow them to be introduced into and removed
from the zone at the appropriate times. Considerations that must be
taken into account are:
o Key and signature records are not only held at the authoritative
nameserver; they are also cached at client resolvers. The data on
these can be interlinked, e.g. a validator may try to validate a
signature retrieved from a cache with a key obtained separately.
o To allow for emergency re-signing, additional keys (over and above
those used to sign the zone) need to be present.
o 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), stale key records must be periodically removed. (For
the same reason, the number of emergency keys in the zone should
be restricted to the minimum required to support the key
management policy.)
o Zone "boot-strapping" events, where a zone is signed for the first
time, can be common in configurations where a large number of
zones are being served. Procedures should be able to cope with
the introduction of keys into the zone for the first time as well
as "steady-state", where the records are being replaced as part of
normal zone maintenance.
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.
1.1. Terminology
The terminology used in this document is as defined in [RFC4033] and
[RFC4641].
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Morris, et al. Expires August 21, 2009 [Page 3]
Internet-Draft DNSSEC Key Timing Considerations February 2009
document are to be interpreted as described in [RFC2119].
2. Zone-Signing Keys
2.1. Key Timeline
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.
|1| |2| |3| |4| |5| |6| |7| |8| |9|
| | | | | | | | |
Key N | |<-Ip->|<--->|<-------Lz------->|<-It->|<--->|
| | | | | | | | |
Key N+1 | | | | |<-Ip->|<--->|<--------Lz-- - -
| | | | | | | | |
Tg Tp Tr Ta Tps Tt Td Tm
---- Time ---->
Timeline for a ZSK rollover.
Figure 1
Event 1: key N is generated at the generate time (Tg). 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 generated but not published are said to be in
the generate state.
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. Note that key N is not yet used to sign records. The
time at which this occurs is the key's publication time (Tp), and the
key is now in the published state.
Event 3: before it can be used, the key must stay in the published
state 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 record: in other words, that any
Morris, et al. Expires August 21, 2009 [Page 4]
Internet-Draft DNSSEC Key Timing Considerations February 2009
prior cached information about the DNSKEY RRset has expired.
The interval is the publication interval (Ip) and, for the second or
subsequent keys in the zone, is given by:
Ip = TTLkey + Dp
Here, TTLkey is the time-to-live (TTL) for the DNSKEY records in the
zone. The other term is Dp (the propagation delay), which is
included because of the finite time taken for any change introduced
at the master to replicate to all slave servers. The delay depends
on the depth of the master-slave hierarchy.
In the case of the first key in the zone, Ip is slightly different
because it is not information about a DNSKEY RRset that may be cached
at downstream validators, it is information about its absence. In
this case:
Ip = C + Dp
where C is the negative cache time from the zone's SOA record,
calculated as described in [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.
C = min(TTLsoa, SOAmin)
The two expressions for Ip may be conveniently combined as:
Ip = max(TTLkey, C) + Dp
After a delay of Ip, the key is in the ready state and can be used to
sign records. The time at which this event occurs is the key's ready
time (Tr), which is given by:
Tr = Tp + Ip
Event 4: at some later time, the key is used to sign the zone. This
point is the activation time (Ta) and after this, the key is said to
be in the active state.
Event 5: while this key is active, thought must be given to its
successor. As with the introduction of the present key into the
zone, the successor key will need to be published at least Ip before
it is used. Denoting the publication time of the successor key by
Tps, then:
Morris, et al. Expires August 21, 2009 [Page 5]
Internet-Draft DNSSEC Key Timing Considerations February 2009
Tps <= Ta + Lz - Ip
Here, Lz is the length of time for which a ZSK will be used (the ZSK
lifetime). It should be noted that unlike the publication interval,
Lz is not determined by timing logic, but by key management policy.
Lz 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 Lz.
Event 6: while the present ZSK is still active, its successor moves
into the ready state. From this time onwards, it could be used to
sign the zone.
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:
Tt = Ta + Lz
This point in time is the retire time (Tt) 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.)
Event 8: the retired key needs to be retained in the zone whilst any
resolvers still have RRSIG records in their cache that were created
using the key. (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 (It) given by:
It = TTLsig + Dp
TTLsig is the TTL of the RRSIG records and Dp the propagation delay,
the latter being included in the equation for the same reason as
given in the description of event 3. Once this time has passed, the
key can be considered dead. This time is the dead time (Td), given
by:
Td = Tt + It
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 (Tm), given by:
Morris, et al. Expires August 21, 2009 [Page 6]
Internet-Draft DNSSEC Key Timing Considerations February 2009
Tm >= Td
2.2. Emergency Zone-Signing Keys
Although ZSKs will usually be generated according to some regular
schedule, there may be occasions when an emergency ZSK rollover is
required, e.g. if a key is suspected of being compromised. The aim
of the emergency key rollover is to allow the zone to be re-signed
with the new key as soon as possible. As a key must be in the ready
state to sign the zone, it may be advisable to have at least one
spare ZSK in that state at all times.
2.2.1. Emergency Key Replacement
One way to handle this is to regard successor keys as emergency keys,
and to introduce them in the zone as early as possible. A
modification of Figure 1 illustrates this:
|1| |2| |3| |4|
| | | |
Key N - - - -- Lz ------------->| |
| | | |
Key N+1 - --------------------->|<-----Lz------>|
| | | |
Key N+2 |<--Ip-->|<---------------------->|<--Lz-- - -
| | | |
---- Time ---->
Timeline showing emergency key replacement.
Figure 2
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 emergency key until the
time comes to use it to sign the zone.
Event 1: At least Ip (publication interval) before key N's retire
time, key N+2 is published in the zone.
Event 2: key N+2 moves into the ready state.
Event 3: key N is retired and key N+1 becomes active (as described in
figure 1, events 7 - 9). Key N+2 is now regarded as the emergency
Morris, et al. Expires August 21, 2009 [Page 7]
Internet-Draft DNSSEC Key Timing Considerations February 2009
key.
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.)
The above illustrates one way of handling emergency keys. An equally
valid alternative would be to have a permanent emergency key. In
this scheme, a key is published in the zone as an emergency key:
unless it needs to be used in an emergency, it is never used to sign
the zone. Instead, active keys are replaced by their successors as
shown in Figure 1.
2.2.2. Emergency Key Use
An emergency key rollover could be required at any time. Referring
back to Figure 2, 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 emergency
key when the current emergency key becomes active. In the worst case
though, it may be required that the system run without an emergency
key for a while. For example, if a key rollover was required between
events 3 and 4 in Figure 2, the timeline would look like:
|3a| |3b|
| |
Key N+1 - --- Lz --->| |
| |
Key N+2 - ---------->|<----------Lz----- - -
| |
Key N+3 |<--Ip-->|<-------- - -
| |
---- Time ---->
Timeline showing emergency key rollover.
Figure 3
In the above figure, the interval shown lies between events 3 and 4
in Figure 2, the events being labelled 3a and 3b to highlight this.
Here it is assumed that key N+1 is initially in the active state and
that the single emergency key (N+2) is in the ready state. It is
well before the active key's retire time, so there are only these two
Morris, et al. Expires August 21, 2009 [Page 8]
Internet-Draft DNSSEC Key Timing Considerations February 2009
ZSKs in the zone. The events are:
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 emergency key) is published in the zone.
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.
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 emergency key (N+3) becomes ready. Of course, this can
be mitigated by having a number of emergency 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.
2.3. Key Rollover Logic
2.3.1. Actual and Estimated Times
In the above discussions, mention has been made of a number of
significant times in the life of a key, e.g. publication time,
activation time etc. At any particular time, the key is in one and
only one state. The time at which it entered that state (and the
time at which it entered all past states) are actual times. All
future times are estimated times. For example, although the retire
time of an active key is "activation time + key lifetime", until the
key actually makes the transition into the retired state (by no
longer being used to sign the zone), the retire time is only an
estimate of the retire time: it may change depending on events.
2.3.2. Practical Timing Considerations
Section Section 2.1 gave the theoretical timings for the entry of the
ZSK to different states. The most critical transitions are between
the publish and ready states, and between the retired and dead
states. In both cases, a premature transition could lead to
signatures not being validated.
Adding a safety margin is therefore prudent. Such a margin takes in
to account small uncertainties in timings as well as providing the
implementation with robustness. The former could be due to factors
such as the clocks on the server and validator running at slightly
different rates so leading to a discrepancy in the calculation of
intervals (interval skew). Adding robustness is just good management
practice: the calculations above show when the key should be in the
ready state - a safety margin provides increased certainty that all
Morris, et al. Expires August 21, 2009 [Page 9]
Internet-Draft DNSSEC Key Timing Considerations February 2009
parties agree that this is the case.
In practical terms, adding a safety margin means replacing Ip and It
in the equations above by Ip' and It' where:
Ip' = Ip + Sp
It' = It + St
Sp is the publish safety margin and St the retire safety margin. At
minimum they should be of the order of a few seconds to account for
the interval skew; in practice, they are likely to be much greater,
of the order of TTLsig.
2.3.3. ZSK Management Procedure
The following section describes the procedure for maintaining ZSKs.
It handles key rollover - both scheduled and emergency - as well as
flagging which keys should be published in preparation for use in
signing the zone.
The following is assumed:
1. Information about keys is held in some data store. The
information includes the state of each key and the times
associated with each state change for each key.
2. There is only one active ZSK at any one time.
3. The procedure is run on a regular basis (at intervals of Ir) that
depends on the interval between events in the timeline in
Figure 1. (This is discussed further below.)
In the following discussion, "now()" is the time at which the
procedure is run. Also defined is Nze as the number of emergency
ZKSs required to be able to immediately roll at any time for
emergency reasons. A likely value is:
Nze = 1
1. For all keys in the data store, calculate the estimated time of
entering the next stage using the relationships described above.
2. If this procedure is being run as part of an emergency rollover,
set the estimated retirement time for the active key(s) as now().
(In this way, an emergency key rollover requires no special
processing: it is merely the early retirement of the active key.)
Morris, et al. Expires August 21, 2009 [Page 10]
Internet-Draft DNSSEC Key Timing Considerations February 2009
3. For each retired key, if now() >= Td, mark the key as dead. (Or
remove it from the data store. Either way, this key is no longer
of use and will never be used again.)
4. For each published key, if now() >= Tr, mark the key as ready.
5. If now() is within (Ip + Ir) of the estimated retire time of the
active key (Ir being the interval between runs of the procedure)
AND the number of keys in the publish and ready states combined
is less than (1 + Nze), move a number of keys equal to the
difference between these two values from the generate state into
the publish state. (This step ensures that when the active key
is retired, there is a key to replace it as well as the desired
number of emergency keys in the ready state.)
The term Ir appears here because to avoid a policy violation
(i.e. a delay in retiring the active key) this action must occur
at least Ip before the estimated retire time of the key. As the
procedure is run at intervals, the only way to guarantee this is
to add a margin equal to the run interval.
6. If now() is earlier than the retire time of the active key, exit.
(Note "earlier"; if an emergency rollover is taking place, the
retirement time of the active key will be equal to now() due to
the processing of step 2.)
7. Check whether there are keys in the ready state. If not, the
currently active key cannot be retired and the procedure will
have to wait until one or more keys become ready. In this case,
exit the procedure.
8. Mark the active key as retired.
9. Mark one of the ready keys as active.
After this procedure, all keys in the publish, ready, active and
retire states should be published in the zone. The active key should
be used to sign the zone.
3. Key-Signing Keys
3.1. Key Timeline
There are three significant differences between key-signing keys
(KSKs) and ZSKs:
Morris, et al. Expires August 21, 2009 [Page 11]
Internet-Draft DNSSEC Key Timing Considerations February 2009
1. KSKs only sign the DNSKEY RRset. This means that, unlike ZSKs,
it is feasible to use multiple KSKs to sign the zone without
generating a excessive amount of signature data.
2. They have to involve the parent zone in the addition and removal
of DS records.
3. KSKs may be configured as so-called "trust anchors" in validating
resolvers. Whether or not a KSK is used as a trust anchor and
how to transport the KSK to the validator in a secure way is
outside the scope of this document.
The first difference has led to the preferred method for handling KSK
rollover [RFC4641] being that of double-signature: the DNSKEY RRset
is signed by both the new key and the old key and the associated DS
records for both published in the parent zone. After a suitable
interval, the records for the old key are removed. This is the
scheme described in the timeline below.
The second difference means that timings are not wholly within the
control of the zone manager, in that the time take to publish the DS
records depends on the policies and procedures of the parent zone. A
further ramification is that the independence of the parent DS and
child DNSKEY records means that 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 [RFC4035], the
information cannot be used for validation until the validator has
both components.
|1| |2| |3| |4| |5| |6| |7| |8|
| | | | | | | |
Key N | |<-Ip->|<-->|<-------Lk------->|<------>|
| | | | | | | |
Key N+1 | | | | |<-Ip->|<--->|<---Lk--- - -
| | | | | | | |
Tg Tp Tr Ta Tps Tt Tm
---- Time ---->
Timeline for a KSK rollover.
Figure 4
Event 1: key N is generated at time Tg and enters the generate state.
As before, although there is no reason why the key cannot be
Morris, et al. Expires August 21, 2009 [Page 12]
Internet-Draft DNSSEC Key Timing Considerations February 2009
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.
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 also submitted to the parent zone for
publication. This time is the publish time (Tp) and the KSK is said
to be in the published state.
Event 3: after some time (the publication interval, Ip), 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:
Tr = Tp + Ip
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 of one another, so a suitable expression for Ip
is:
Ip = max(Ipc, Ipp)
Ipc is the publication interval in the child zone and Ipp that of the
parent.
The child term comprises two parts - the time taken for the
introduction of the DNSKEY record to be registered on the downstream
slave servers (= Dpc, the child propagation delay) and the time taken
for information about the DNSKEY RRset to expire from the validator
cache, i.e.
Ipc = max(TTLkeyc, Cc) + Dpc
(TTLkeyc is the TTL for a DNSKEY record in the child zone and Cc the
negative cache time in that zone. The max() function occurs to
combine the separate expressions for the first and subsequent key in
a zone, as described in event 3 in section Section 2.1.)
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:
Ipp = Dr + max(TTLdsp, Cp) + Dpp
(TTLdsp is the TTL for a DS record in the parent zone, Cp the
negative cache time in that zone, Dpp the propagation delay. Dr is
Morris, et al. Expires August 21, 2009 [Page 13]
Internet-Draft DNSSEC Key Timing Considerations February 2009
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.)
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.
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 (Ta)
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.
As before, this interval is the publication interval, Ip. Denoting
the publication time of the successor key as Tps, we get:
Tps <= Ta + Lk - Ip
Event 6: the successor key (key N+1) enters the ready state.
Event 7: at some time 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 (Lk). At this point, the retire time, the successor key
becomes active and the current key is said to be retired:
Tt = Ta + Lk
Event 8: at some later time, the DNSKEY record can be removed from
the child zone and a request made to remove the DS record from the
parent zone. This is the removal time, Tm and is given by:
Tm >= Tt
Note the differences to a ZSK. In the case of a ZSK, 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 haver expired.
With a KSK, both the active key and the successor key sign the DNSKEY
Morris, et al. Expires August 21, 2009 [Page 14]
Internet-Draft DNSSEC Key Timing Considerations February 2009
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 or dead time. (Although
for completeness, and in analogy with the ZSK, a dead time could be
defined by Td = Tm.)
3.2. Emergency Key-Signing Keys
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 emergency keys
kept available is a matter of key management policy, and the logic
for the introduction of emergency keys into the zone is the same as
that given in Section 2.2.1.
3.3. Key Rollover
By definition, KSK rollovers have to involve the parent zone. If (as
is the usual case) the parent zone is managed by a different entity
then the timing of some of the steps in the KSK rollover operation
may be subject to uncertainty. In the above analysis, this has been
represented above by the DS registration delay (Dr); in practice,
confirmation needs to be sought that the step has successfully
completed.
It is important to note however, that this does not preclude the
development of key rollover logic similar to that described in
Section 2.3.3 for the ZSKs. 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 waiting for the parent to respond, in addition to any
interval 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.
3.4. Key Rollover Logic
3.4.1. Actual and Estimated Times
Time stamps for KSK rollovers exhibit the same behaviour as for ZSK
rollovers in that all times are estimates until after the event to
which they refer has occurred.
Morris, et al. Expires August 21, 2009 [Page 15]
Internet-Draft DNSSEC Key Timing Considerations February 2009
3.4.2. Practical Timing Considerations
For reasons given in section Section 2.3.2, it is prudent to include
a safety margin in the initial publication interval used in any
practical implementation of KSK timing, i.e. in the equations above
replace Ip by Ip' where:
Ip' = Ip + Sp
As before, Sp is the publication safety interval, with a minimum
value of the order of seconds, but a realistic value of the order of
TTLsig.
3.4.3. KSK Management Procedure
The following section describes the procedure for maintaining KSKs in
a zone. It handles key rollover - both scheduled and emergency - as
well as flagging which keys should be published in preparation for
use in signing the zone. The procedure is largely similar to that
used for ZSKs.
As before, it is assumed that data about keys is held in some key
management store, that the procedure is run on a regular basis and
that "now()" is the time at which the procedure is run. Also defined
is Nke as the number of emergency KSKs required to be able to
immediately roll at any time for emergency reasons. A likely value
is:
Nke = 1
1. For all keys in the data store, calculate the estimated time of
entering the next stage using the relationships described above.
2. If this procedure is being run as part of an emergency rollover,
set the estimated retirement time for the active key as now().
(In this way, an emergency key rollover requires no special
processing: it is merely the early retirement of the active key.)
3. For each published key, if now() >= Tr, mark the key as ready.
4. If now() is within (Ip + Ir) of the estimated retire time of the
active key (where Ir is the interval between runs of the
procedure) AND the number of keys in the publish and ready states
combined is less than (1 + Nke), move a number of keys equal to
the difference between these two values from the generate state
into the publish state. (This step ensures that when the active
key is retired, there are keys available to take over from it.)
Morris, et al. Expires August 21, 2009 [Page 16]
Internet-Draft DNSSEC Key Timing Considerations February 2009
The term Ir appears here because to avoid a policy violation
(i.e. a delay in retiring the active key) this action must occur
at least Ip before the estimated retire time of the key. As the
procedure is run at intervals, the only way to guarantee this is
to add a margin equal to the run interval.
5. If now() is earlier than the retire time of the current key, exit
the procedure. (Note "earlier"; if an emergency rollover is
taking place, the retirement time of the active key will be equal
to now() due to the processing of step 2.)
6. Check whether there are keys in the ready state. If not, the
currently active key cannot be retired and the procedure will
have to wait until one or more keys become ready. In this case,
exit the procedure.
7. Check that the DS record of the successor key is available from
the parent zone. (The check may be made in a variety of ways,
including querying one of or all of the parent nameservers, or
just querying the server furthest down the chain of parent
nameservers.) If the record is not available, exit the
procedure.
The key that will replace the active key is in the ready state.
However, the entry to the ready state is based on the assumption
that the DS record has been published after a time Dr. But that
is only an assumption, and relies on the behaviour of the parent
zone operator. To be safe, a check is made that the DS record
has propagated through the parent's server network. If it
hasn't, there may have been some breakdown in communication with
the parent zone.
8. Mark the active key as retired.
9. Mark the successor key as active.
After this procedure, all keys in the publish, ready and active
states should be published in the zone. Retired keys may be removed
from the zone when convenient.
4. Running the Key Management Procedures
The preceding sections outlined procedures to be used to manage KSKs
and ZSKs. One way to use these procedures is to run them only when a
significant event occurs. In other words, when a procedure
completes, calculate the time at which the next event will occur and
run it again at that time.
Morris, et al. Expires August 21, 2009 [Page 17]
Internet-Draft DNSSEC Key Timing Considerations February 2009
In practice though (and what has been assumed in the management
procedures outlined above), it will be easier to run them on a
regular basis. This has two implications:
1. Depending on the frequency of running the procedure, in many
cases the result will be a no-op; the set of keys to be published
in the zone will be unchanged from the last time it is run.
2. Policy will not be enforced exactly, e.g. the a key may remain
active longer that the key lifetime because the procedure is not
run until some time after the retire time of the active key is
reached.
Neither of these objections is fatal. In the first case, it will be
easy to detect that a key set is unchanged and so prevent a needless
update. The latter case is dealt with by reducing the run interval
to the point at which the maximum delay in making a transition
between the states of keys is acceptable.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This document does not introduce any new security issues beyond those
already discussed in [RFC4033], [RFC4034] and [RFC4035].
7. Acknowledgements
The authors gratefully acknowledge help and contributions from Roy
Arends and Wouter Wijngaards.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
Morris, et al. Expires August 21, 2009 [Page 18]
Internet-Draft DNSSEC Key Timing Considerations February 2009
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, September 2006.
Appendix A. List of Symbols
The following symbols have been used in the text:
C Negative cache time.
Cc Negative cache time in the child zone.
Cp Negative cache time in the parent zone.
Dp Propagation delay. The amount of time for a change made at
a master nameserver to propagate to all the slave
nameservers.
Dpc Propagation delay in the child zone.
Dpp Propagation delay in the parent zone.
Dr Registration delay, the time between submission of a DS
record to the parent zone and its publication in the zone.
Ip 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.
Ip' Publication interval taking into account a safety margin.
Ipc Publication interval for the child zone.
Ipp Publication interval for the parent zone.
Ir Run interval. The time between successive runs of the key
rollover procedure.
Morris, et al. Expires August 21, 2009 [Page 19]
Internet-Draft DNSSEC Key Timing Considerations February 2009
It 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.
It' Retire interval taking into account a safety margin.
Lk 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.
Lz 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.
Nke Number of emergency KSKs in a zone.
Nze Number of emergency ZSKs in a zone.
SOAmin The value of the "minimum" parameter in the zone's SOA
record.
Sp Publish safety margin. An interval of time used to
guarantee that a key is truly in the ready state.
St Retire safety margin. An interval of time used to
guarantee that a key is truly in the dead state.
Ta 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.
Td 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.
Tg Generate time of a key. The time that a key is created.
Tm Removal time of a key. The time at which a key is removed
from the zone.
Tp Publish time of a key. The time that a key appears in a
zone for the first time.
Morris, et al. Expires August 21, 2009 [Page 20]
Internet-Draft DNSSEC Key Timing Considerations February 2009
Tps Publish time of the successor key.
Tr 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.)
Tt Retire time of a key. The time at which a successor key
starts being used to sign the zone.
TTLdsp Time to live of a DS record in the parent zone.
TTLkey Time to live of a DNSKEY record.
TTLkeyc Time to live of a DNSKEY record in the child zone.
TTLsoa Time to live of a SOA record.
TTLsig Time to live of a RRSIG record.
Authors' Addresses
Stephen Morris
Nominet
Minerva House, Edmund Halley Road
Oxford, OX4 4DQ
UK
Phone: +44 1865 332211
Email: stephen@nominet.org.uk
Johan Ihren
Autonomica
Bellmansgatan 30
Stockholm, SE-118 47
Sweden
Phone: +46 8615 8573
Email: johani@autonomica.se
Morris, et al. Expires August 21, 2009 [Page 21]
Internet-Draft DNSSEC Key Timing Considerations February 2009
John Dickinson
6 Nelson Close
Wallingford, OX10 0LG
UK
Phone:
Email: jad@jadickinson.co.uk
Morris, et al. Expires August 21, 2009 [Page 22]