One document matched: draft-mekking-dnsop-dnssec-key-timing-bis-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902" category="std" docName="draft-mekking-dnsop-dnssec-key-timing-bis-00">
<front>
<title abbrev="DNSSEC Key Timing Considerations Bis"> DNSSEC Key Timing Considerations Follow-Up </title>
<author fullname="Matthijs Mekking" initials="W.M." surname="Mekking">
<organization> NLnet Labs </organization>
<address>
<postal>
<street>Science Park 140</street>
<code>1098 XG</code>
<city>Amsterdam</city>
<country>The Netherlands</country>
</postal>
<email> matthijs@nlnetlabs.nl </email>
</address>
</author>
<date month="February" year="2011"/>
<area> Internet Area </area>
<workgroup> Domain Name System Operations </workgroup>
<keyword>DNS</keyword>
<keyword>DNSSEC</keyword>
<keyword>key</keyword>
<keyword>rollover</keyword>
<abstract>
<t>
This document describes issues surrounding the timing of events in enforcing key policy within DNSSEC.
It presents timelines for various key rollovers and changes into the policy with respect to the key signing scheme.
It explicitly identifies the relationships between the various parameters affecting the process.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>
A zone is managed according to a given security policy.
Such a policy may enforce DNSSEC keys to be used and for how long.
When enforcing a lifetime on DNSSEC keys, key rollovers must to take place.
In addition, changes in the policy may trigger certain key rollover events.
Key rollovers are time critical, multiple steps processes.
This document describes issues surrounding the timing of events in the rolling of DNSSEC keys.
</t>
<t>
[MM: Editorarial comments are indicated by square brackets and editor initials]
</t>
<section title="Key Rollover Considerations" anchor="considerations">
<t>
A key is used with a purpose:
An operational decision has been made to secure the zone with DNSSEC.
That decision leads to a key being created, published in the zone and used for signing.
Policy may enforce a lifetime on keys.
As a result, current active keys need to be replaced with new keys.
The new key becomes active, while the current key is retired.
The keys need to be introcuded into and removed from the zone at the appropriate times.
Considerations that must be taken into account are:
</t>
<t>
<list style='symbols'>
<t>
Speed:
A rollover should occur as fast and simple as possible.
However, DNSSEC records are not only held at the authoritative nameserver, they are also cached at client resolvers.
The data on these systems can be interlinked, meaning a validating may try to validate a signature retrieved from a cache with a key obtained separately.
The rollover process needs to happen in such a way that at all times through the rollover the information is consistent.
</t>
<t>
Size of the zone and the DNS response:
A rollover can be speed up by introducing the DNSSEC records prematurely.
However, adding arbitrary signatures increases the size of your zone and DNS responses significantly.
To keep the sizes of the zone and responses as small as possible, you might want to consider to introduce the DNSSEC records only when they are required,
For the same reason, dead keys and signatures must be removed periodically.
</t>
<t>
Size of the DNSKEY RRset and the priming response:
You can choose to keep the size of the DNSKEY RRset to a minimum, to make priming responses smaller in size.
The larger the packet, the more resolvers may have problems retrieving the response.
Other responses may have more signatures, since the initial size is relatively small.
The DNSKEY RRset is usually already quite large and should not grow too much anymore.
</t>
<t>
Interactions with the Parent:
A KSK sometimes needs its corresponding DS record to be published at the parent zone, while its predecessor needs to remove its DS record from the parent zone.
Such a request requires additional operational work and can be a sufficient delay.
Ideally, the interactions with the parent is kept to a minimum.
</t>
</list>
</t>
<section title="Key Goals" anchor="goals">
<t>
We have identified three different goals for a key:
</t>
<t>
<list style='symbols'>
<t>Activate key: Make validating resolvers use the key's associated information to perform authentication.</t>
<t>Remove key: Make validating resolvers forget about the key's associated information.</t>
<t>Stand-by key: Pre-publish information for this key to speed up a future (unscheduled) rollover.</t>
</list>
</t>
<t>
Each key rollover and change in key signing scheme can now be described by one or more goals that are put on a key.
</t>
</section>
</section>
<section title="Terminology" anchor="terminology">
<t>
The terminology used in this document is as defined in <xref target="RFC4033"/> and <xref target="RFC5011"/>.
</t>
</section>
</section>
<section title="Key Definitions" anchor="definitions">
<section title="Key Types" anchor="types">
<t>
Keys can be used to authenticate information within the zone.
Such keys are said to be ZSKs.
In addition, keys can be used to authenticate the DNSKEY RRset in the zone.
These keys are said to be KSKs.
Keys can be marked to be ZSK and KSK at the same time, for example in a Single Type Signing Scheme (STSS).
</t>
<t>
Despite that ZSK and KSK only describe the usage of a key, the terms are often used for identifiying a key.
Thus when we talk about a ZSK, we actually mean that the key is used as ZSK.
In the same spirt, a KSK is a key that is used as KSK.
</t>
<t>
DNSSEC recognises the classification of keys with its SEP bit set and not set.
Usually if a key is used as KSK, the SEP bit is set.
However, <xref target="dnssec-bis">draft-ietf-dnsext-dnssec-bis-updates</xref> says that a SEP bit setting has no effect on how a DNSKEY may be used.
Policy determines whether the bit should be set, depending on the key's usage.
</t>
</section>
<section title="Key States Unraveled" anchor="unraveled">
<t>
We use unraveled key states to seperately represent the key and its associated information.
There can be up to three pieces of key associated information:
the public key (in DNSKEY format), its created signatures (the RRSIG records) and the secured delegation (the corresponding DS record).
The state of the piece of information is defined by 'RRtype State'.
</t>
<t>
Key conditions are essentially what are called key states in <xref target="key-timing">draft-ietf-dnsop-dnssec-key-timing</xref>.
A key can have multiple conditions at the same time.
</t>
<t>
A piece of information may exist in up to two places:
it can be present in the corresponding zone and it may live in resolver caches.
This is true for every piece of associated information.
Therefore, all of the three pieces of information follow the same state diagram:
</t>
<t>
Generated --> Introduced --> Propagated --> Withdrawn --> Dead.
</t>
<t>
<list style="hanging">
<t hangText="Generated: ">
The information has been generated, but is not available in the zone.
In this state, no resolvers are able to fetch this information. <vspace blankLines="0" />
- The key condition is said to be Generated, if no information has passed the Introduced state yet.
</t>
<t hangText="Introduced: ">
The information is introduced and, as a result, may be available in the zone.
In this state, there may be resolvers that fetch this information. <vspace blankLines="0" />
- The key condition is said to be Published if it has its DNSKEY state in Introduced. <vspace blankLines="0" />
- The key condition is said to be Active if it has its RRSIG state in Introduced (for ZSKs). <vspace blankLines="0" />
- The key condition is said to be Submitted, or ActiveDS, if it has its DS state in Introduced (for KSKs).
</t>
<t hangText="Propagated: ">
The information is available in the zone and enough time has passed to have it propagated into all resolver caches.
As a result, all resolvers fetch this information from cache of from the authoritative name server. <vspace blankLines="0" />
- The key condition is said to be Known if it has its DNSKEY state in Propagated. <vspace blankLines="0" />
- The key condition is said to be Safe if it has its RRSIG state in Propagated (for ZSKs). <vspace blankLines="0" />
- The key condition is said to be SafeDS if it has its DS state in Propagated (for KSKs).
</t>
<t hangText="Withdrawn: ">
The information is being withdrawn from the zone, but may still be available in the zone.
In this state, the information can still live in resolver caches. <vspace blankLines="0" />
- The key condition is said to be Removed if it has its DNSKEY state in Withdrawn. <vspace blankLines="0" />
- The key condition is said to be Retired if it has its RRSIG state in Withdrawn (for ZSKs). <vspace blankLines="0" />
- The key condition is said to be RetiredDS if it has its DS state in Withdrawn (for KSKs).
</t>
<t hangText="Dead: ">
The information is not available in the zone anymore and enough time has passed to have it expire from all resolver caches. <vspace blankLines="0" />
- The key condition is said to be Forgotten if it has its DNSKEY state in Dead. <vspace blankLines="0" />
- The key condition is said to be Expired if it has its RRSIG state in Dead (for ZSKs). <vspace blankLines="0" />
- The key condition is said to be ExpiredDS if it has its DS state in Dead (for KSKs).
</t>
</list>
</t>
<t>
A key state can now be represented as the triplet (DNSKEY State, RRSIG State, DS State).
For example:
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Introduced, DS Generated)
</t>
<t>
tells us that key Kc is published in the zone and all the resolvers that have a copy of the DNSKEY RRset, have one that includes Kc.
In other words, Kc is said to be Known.
In addition, the key is Active as it is being used for signing RRsets: RRSIG records made with Kc have been introduced in the zone.
However, there may still be some resolver caches that are unaware of these signatures.
Finally, the corresponding DS record is said to be Generated and has thus not yet been submitted to the parent.
</t>
<t>
For convenience, we can represent a ZSK as a tuple (DNSKEY State, RRSIG State), because the DS record is only used with KSKs.
And we can represent a KSK as a tuple (DNSKEY State, DS State), because the RRSIG state only refers to ZSKs.
The RRSIG record over the DNSKEY RRset should be published at the same time when the corresponding DNSKEY record is published.
Therefore, both records will propagate and expire at the same time from resolver caches.
</t>
</section>
<section title="Delay Timings" anchor="timings">
<t>
For every change we make in the zone, we have to take into account several delays.
</t>
<t>
<list style="hanging">
<t hangText="Software Delay (Dsfw): ">
The time it takes for the software to introduce the new information in the zone.
This delay can vary alot depending on the information that needs to be introduced.
One can imagine that the software needs more time to sign a complete zone than when it pre-publishes a DNSKEY record.
[MM: Dsfw maps to Dsgn from the key-timing draft]
</t>
<t hangText="Propagation Delay (Dprp): ">
The time it takes for any change introduced at the master to replicate to all slave servers.
</t>
<t hangText="TTL Delay (Dttl): ">
The time it takes to expire the previous information from the resolver caches.
This delay depends on what RRsets need to expire from the caches.
If not explicitly mentioned otherwise, Dttl is considered the maximum TTL of the information that needs to expire from caches.
Otherwise, Dttl(RRtype) shows which specific RRsets need to expire.
[MM: TTL terminology in key-timing draft: TTLds, TTLkey, TTLkeyC, TTLsoa, TTLsoaC, TTLsoaP, TTLsig)]
</t>
<t hangText="Registration Delay to the Parent (Dreg): ">
The time it takes to get the DS record to be placed into the parent zone, after it is submitted.
</t>
<t hangText="Propagation Delay of the Parent (DprpP): ">
The time it takes for any change introduced at the parent master to replicate to all parent slave servers.
</t>
</list>
</t>
<t>
Despite these delays may vary for the different rollover methods, we can identify the propagation delay to the caches as:
</t>
<t>
DcacheZ = Dsfw + Dprp + Dttl <vspace blankLines="0" />
DcacheK = Dsfw + Dprp + Dttl(DNSKEY) <vspace blankLines="0" />
DcacheP = Dreg + DprpP + Dttl(DS)
</t>
<t>
where DcacheZ is the propagation delay to the caches for information published in our zone,
DcacheK is the propagation delay to the caches for our DNSKEY RRset and
DcacheP is the propagation delay for information published in our parent zone.
</t>
</section>
</section>
<section title="Key Rollovers" anchor="rollovers">
<t>
There are many different key rollover methods. In <xref target="considerations"/>,
we have seen that there are several properties to prefer one method over the other.
Though there are many different type of key rollovers, all methods share the same goal.
There is a current key (Kc) that needs to become Forgotten-Retired and a successor key (Ks) that needs to become Known-Safe.
</t>
<section title="ZSK Rollovers" anchor="zsk-rollovers">
<t>
The two most common rollover methods for ZSKs are Double-Signature and Pre-Publication.
Both are described in <xref target="RFC4641">RFC4641</xref>.
<xref target="key-timing">draft-ietf-dnsop-dnssec-key-timing</xref> also introduces ZSK Double-RRSIG rollover.
Double-Signature is the fastest way to rollover a ZSK.
Pre-Publication minimizes the number of signatures over the RRsets in the zone and responses.
Double-RRSIG keeps the size of the DNSKEY RRset to a minimum.
</t>
<section title="Double-Signature">
<t>
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, 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.
</t>
<t>
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-Signature is the fastest way to rollover to a new key, since all new information is published right away.
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>
Only when Ks is said to be Known, e.g. the DNSKEY record of Ks is known to all validating resolvers, we can remove the signatures made with Kc.
And only when we can ensure that all validators only use the information of Ks for authentication, we can remove the DNSKEY record for Kc.
In other words, Ks needs to be Known and Safe, before we can remove Kc.
Thus, we first have to introduce all new information into the zone.
Once all has been propagated, we can withdraw all information of Kc from the zone.
</t>
<figure>
<preamble>The timeline diagram is shown below:</preamble>
<artwork alt='Timeline Diagram of ZSK Double-Signature Rollover'>
|1| |2| |3| |4| |5|
Kc | | | | |
- RRSIG |----|-------|----|DcacheZ|
- DNSKEY |----|-------|----|DcacheK|
| | | | |
Trem Tfor
Tret Texp
Ks | | | | |
- RRSIG | |DcacheZ|----|-------|---
- DNSKEY | |DcacheK|----|-------|---
| | | | |
Tgen Tpub Tkno
Tact Tsaf
</artwork>
<postamble>Figure: ZSK Double-Signature Rollover.</postamble>
</figure>
<t>
Event 1:
Key Ks is generated at the generate time (Tgen).
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
Key Ks is added to the DNSKEY RRset and is immediately used to sign the zone; existing signatures in the zone are not removed.
This is Ks' publish time (Tpub) and Ks is said to be Published.
It is also Ks' active time (Tact), the time when Ks is said to be Active.
Because the Double-Signature rollover is in place, we now temporarily have two active keys.
</t>
<t>
Tpub(Ks) >= Tgen(Ks), Tact(Ks) == Tpub(Ks)
</t>
<t>
S(Ks) = (DNSKEY Introduced, RRSIG Introduced) <vspace blankLines="0" />
C(ks) = Published Active
</t>
<t>
Event 3:
The information for Ks must be published long enough to ensure that the information have reached all validating resolvers that may have RRsets
from this zone cached.
At the point in time that the DNSKEY RRset including Ks has been propagated and Ks is said to be Known (Tkno).
At the point in time that the other RRsets including a signature of Ks have been propagated (Tsaf), Ks is said to be Safe.
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK <vspace blankLines="0" />
Tsaf(Ks) >= Tact(Ks) + DcacheZ <vspace blankLines="0" />
</t>
<t>
S(Ks) = (DNSKEY Propagated, RRSIG Propagated) <vspace blankLines="0" />
C(ks) = Known Safe
</t>
<t>
Note that we could already retire Kc, i.e. stop signing with Kc, after DcacheK.
It does not matter if not all signatures of Ks have been Propagated, since the resolver can validate RRsets with both Kc and Ks.
If the validator fetches a RRset from the cache, it uses the DNSKEY of Kc for validation.
Otherwise, it can use the DNSKEY of Ks.
</t>
<t>
Event 4:
Once we have a successor key that is said to be Propagated, we can retire Kc.
This is Kc' retire time (Tret) and Kc is said to be Retired.
And once we have a successor key that is said to be Safe, we can remove Kc.
Therefore, it is also Kc' removal time (Trem), the time that Kc is said to be Removed.
</t>
<t>
Tret(Kc) >= Tkno(Ks) <vspace blankLines="0" />
Trem(Kc) >= MAX(Tsaf(Ks), TsafDS(Ks))
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, RRSIG Withdrawn) <vspace blankLines="0" />
C(kc) = Removed Retired
</t>
<t>
Event 5:
From the perspective of the authoritative server, the rollover is complete.
After some delay, Kc and its signatures have expired from the caches.
This delay is the maximum of DcacheZ, DcacheK.
This is Tfor, the time that the key is said to be Forgotten and Texp, the time that the key is said to be Expired.
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcacheK <vspace blankLines="0" />
Texp(Kc) >= Tret(Kc) + DcacheZ
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired
</t>
</section>
<section title="Pre-Publication">
<t>
With 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 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 can be removed.
During the re-signing process 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.
</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, 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>
Pre-Publication is more complex than Double-Signature - introduce the new key, approximately one TTL later sign the records,
and approximately one TTL after that remove the old key.
It also takes more time than the Double-Signature method.
The delay is because we don't want to publish signatures of both keys at the same time.
As an advantage, the amount of DNSSEC data is kept to a minimum which reduces the impact on performance.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of ZSK Pre-Publication Rollover'>
|1| |2| |3| |4| |5| |6| |7|
Kc | | | | | | |
- RRSIG |----|-------|----|DcacheZ| | |
- DNSKEY |----|-------|----|-------|----|DcacheK|
| | | | | | |
Tret Texp Trem Tfor
Ks | | | | | | |
- RRSIG | | | |DcacheZ|----|-------|---
- DNSKEY | |DcacheK|----|-------|----|-------|---
| | | | | | |
Tgen Tpub Tkno Tact Tsaf
</artwork>
<postamble>Figure: ZSK Pre-Publication Rollover.</postamble>
</figure>
<t>
Event 1:
Key Ks is generated at the generate time (Tgen).
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
The DNSKEY record of Ks is put into the zone, i.e. it is added to the DNSKEY RRset which is then re-signed with the current KSK.
The time at which this occurs is Ks' 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>
Tpub(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Introduced, RRSIG Generated) <vspace blankLines="0" />
C(Ks) = Published
</t>
<t>
Event 3:
Before Ks can be used,
the DNSKEY record for Ks must be published for long enough (DcacheK) to guarantee that any resolver that has a copy of the DNSKEY RRset also includes this key.
In other words, that any prior cached information about the DNSKEY RRset has expired.
After this delay, the key is said to be Known and could be used to sign records.
The time at which this event occurs is Tkno, which is given by:
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK
</t>
<t>
S(Ks) = (DNSKEY Propagated, RRSIG Generated) <vspace blankLines="0" />
C(Ks) = Known
</t>
<t>
Event 4:
At some point in time, the decision is made to actually 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.
This point in time is Ks' active time (Tact), the time that Ks is said to be Active.
It is also Kc' retire time (Tret), the time that Kc is said to be Retired.
</t>
<t>
Tact(Ks) >= Tkno(Ks), Tret(Kc) == Tact(Ks)
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Withdrawn) <vspace blankLines="0" />
C(Kc) = Known Retired <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Introduced) <vspace blankLines="0" />
C(Ks) = Known Active <vspace blankLines="0" />
</t>
<t>
Event 5:
Kc needs to be retained in the zone whilst any RRSIG records created by the retired key are still published in the zone or held in resolver caches.
In other words, Kc should be retained in the zone until all RRSIG records created by Ks have been propagated.
This time is Ks' safe time (Tsaf), the time that Ks is considered to be Safe.
Consequently, at the same time Kc is considered to be Expired.
</t>
<t>
Tsaf(Ks) >= Tact(Ks) + DcacheZ
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Dead) <vspace blankLines="0" />
C(Kc) = Known Expired <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Propagated) <vspace blankLines="0" />
C(Ks) = Known Safe
</t>
<t>
Event 6:
When all new signatures have been propagated, Kc can be removed from the zone and the DNSKEY RRset re-signed with the current KSK.
This time is Kc' removal time (Trem), the time that Kc is considered to be Removed.
</t>
<t>
Trem(Kc) >= Tsaf(Ks)
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, RRSIG Dead) <vspace blankLines="0" />
C(Kc) = Removed Expired
</t>
<t>
Event 7:
From the perspective of the authoritative server, the rollover is complete.
After some delay, The DNSKEY record for Kc has expired from the caches.
This is Tfor, and the key is said to be Forgotten.
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcacheK
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired
</t>
</section>
<section title="Double-RRSIG">
<t>
This involves introducing the new signatures first, while existing signatures are being retained.
This state of affairs remains in place for long enough to ensure that all RRsets cached in client validating resolvers contain two signatures.
The DNSKEY RR can now be switched.
For the period of time before the predecessor key has been expired from all caches,
it does not matter if the validator uses the cached key or the successor key that is in the zone.
Both corresponding signatures can be retrieved from the cache or from the name server.
</t>
<t>
Once the signing process is complete and enough time has elapsed to allow all old information to expire from caches,
the old 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 is also more complex than Double-Signature - first introducing the signatures, then switch the key and finally remove the olds signatures.
It also takes more time than the Double-Signature method.
The delay is because we cannot publish the public data of both keys at the same time.
As an advantage, the DNSKEY RRset is kept to a minimum which reduces the impact on priming performance.
</t>
<figure>
<preamble>The timeline diagram is shown below:</preamble>
<artwork alt='Timeline Diagram of ZSK Double-RRSIG Rollover'>
|1| |2| |3| |4| |5| |6| |7|
Kc | | | | | | |
- RRSIG |----|-------|----|DcacheK| | |
- DNSKEY |----|-------|----|-------|----|DcacheZ|
| | | | | | |
Trem Tfor Tret Texp
Ks | | | | | | |
- RRSIG | |DcacheZ|----|-------|----|-------|---
- DNSKEY | | | |DcacheK|----|-------|---
| | | | | | |
Tgen Tact Tsaf Tpub Tkno
</artwork>
<postamble>Figure: ZSK Double-RRSIG Rollover.</postamble>
</figure>
<t>
Event 1:
Key Ks is generated at the generate time (Tgen).
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
The zone is signed with Ks but existing signatures are retained.
The DNSKEY RR for Ks remains unpublished.
The time at which this occurs is Ks' active time (Tact), and the key is now said to be Active.
</t>
<t>
Tact(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Introduced) <vspace blankLines="0" />
C(Ks) = Active
</t>
<t>
Event 3:
Before we can switch the DNSKEY from Kc to Ks,
the signatures of Ks must be published for long enough (DcacheZ) to guarantee that any resolver that has a copy of any RRset, also has both signatures.
In other words, that any cached information is double signed.
After this delay, the key is said to be Safe.
The time at which this event occurs is Tsaf, which is given by:
</t>
<t>
Tsaf(Ks) >= Tact(Ks) + DcacheZ
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Propagated) <vspace blankLines="0" />
C(Ks) = Safe
</t>
<t>
Event 4:
At some point in time, the decision is made to publish Ks.
This point in time is Ks' publish time (Tpub), the time that Ks is said to be Published.
At the same time, the DNSKEY RR for Kc is removed from the zone, and Kc is said to be Removed.
</t>
<t>
Tpub(Ks) >= Tsaf(Ks), Trem(Kc) == Tpub(Ks)
</t>
<t>
S(Kc) = (DNSKEY Removed, RRSIG Propagated) <vspace blankLines="0" />
C(Kc) = Removed Safe <vspace blankLines="0" />
S(Ks) = (DNSKEY Introduced, RRSIG Propagated) <vspace blankLines="0" />
C(Ks) = Published Safe <vspace blankLines="0" />
</t>
<t>
Event 5:
The signatures of Kc need to be retained in the zone until the DNSKEY RR has expired from all resolver caches.
When this happens, Ks is said to be Known (Tkno) and Kc is said to be Forgotten (Tfor).
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcacheK <vspace blankLines="0" />
Tkno(Ks) >= Tpub(Ks) + DcacheK
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Propagated) <vspace blankLines="0" />
C(Kc) = Forgotten Safe <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Propagated) <vspace blankLines="0" />
C(Ks) = Known Safe
</t>
<t>
Event 6:
The signatures of Kc can be removed when the DNSKEY RR for Ks has been propagated.
This time is Kc' retire time (Tret), the time that Kc is considered to be Retired.
</t>
<t>
Tret(Kc) >= Tsaf(Ks)
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Withdrawn) <vspace blankLines="0" />
C(Kc) = Forgotten Retired
</t>
<t>
Event 7:
From the perspective of the authoritative server, the rollover is complete.
After some delay, all signatures of Kc have expired from the caches.
This is Texp, and the key is said to be Expired.
</t>
<t>
Texp(Kc) >= Tret(Kc) + DcacheZ
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired
</t>
</section>
</section>
<section title="KSK Rollovers" anchor="ksk-rollovers">
<t>
The most common rollover method for KSKs is Double-Signature, described in <xref target="RFC4641">RFC4641</xref>.
Two more methods are identified in <xref target="key-timing">draft-ietf-dnsop-dnssec-key-timing</xref>: Double-DS and Double-RRset.
Double-RRset is the fastest way to rollover a KSK, while Double-Signature minimizes the number of required interactions to the parent,
and Double-DS keeps your DNSKEY RRset as small as possible.
</t>
<t>
Note that with these type of rollovers, we do not have to worry whether the information within the zone is authentic.
We assume that there exists one or more ZSKs in the DNSKEY RRset that takes care of this during the rollover.
</t>
<section title="Double-RRset">
<t>
With 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>
<t>
Only when Ks is said to be Known, e.g. the DNSKEY record of Ks is known to all validating resolvers, we can remove the DS record of Kc.
And only when can ensure that all validators can use the DS record for Ks to build the secure chain of trust, we can remove the DNSKEY record of Kc.
In other words, Ks needs to be Known and SafeDS.
Thus, we first have to introduce all new information into the zone.
Once all has been propagated, we can withdraw all information of Kc from the zone.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of KSK Double-RRset Rollover'>
|1| |2| |3| |4| |5|
Kc | | | | |
- DNSKEY |----|-------|-----|DcacheK|
- DS |----|-------|-----|DcacheP|
| | | | |
Trem Tfor
TretDS TexpDS
Ks | | | | |
- DNSKEY | |DcacheK|-----|-------|---
- DS | |DcacheP|-----|-------|---
| | | | |
Tgen Tpub Tkno
TactDS TsafDS
</artwork>
<postamble>Figure: KSK Double-RRset Rollover.</postamble>
</figure>
<t>
Event 1:
Ks is generated at time Tgen.
</t>
<t>
S(Ks) = (DNSKEY Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
Ks is introduced into the zone; it is added to the DNSKEY RRset, which is then signed by all currently active KSKs (including Kc and Ks).
In addition, the DS record is submitted to the parent.
This is Ks' publish time (Tpub), the time that Ks is said to be Published.
It is also Ks' submit time (TactDS), the time that the DS record for Ks is Submitted (ActiveDS).
</t>
<t>
Tpub(ks) >= Tgen(Ks), TactDS(Ks) == Tpub(Ks)
</t>
<t>
S(Ks) = (DNSKEY Introduced, DS Introduced) <vspace blankLines="0" />
C(ks) = Published ActiveDS
</t>
<t>
After the registration delay, the DS is published in the parent.
</t>
<t>
Event 3:
The information for Ks must be published long enough to ensure that the information have reached all validating resolvers that may have the DNSKEY or DS RRset
from this zone cached.
At the point in time that the DNSKEY RRset including Ks has been propagated (Tkno), Ks is said to be Known.
At the point in time that the DS RRset of Ks has been propagated (Tsaf), Ks is said to be SafeDS.
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK, TsafDS(Ks) >= TactDS(Ks) + DcacheP
</t>
<t>
S(Ks) = (DNSKEY Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known SafeDS
</t>
<t>
Note that we could already send the request to the parent to withdraw the DS record of Kc after DcacheK.
It does not matter if the DS record for Ks has not yet been propagated, since the resolver can authenticate the DNSKEY RRset with both Kc and Ks.
If the validator fetches a DS RRset from the cache, it uses Kc.
Otherwise, it can use Ks.
</t>
<t>
Event 4:
Once we have a successor key that is said to be Known, we can withdraw the DS record for Kc.
This is Kc' retire time (Tret), the time that Kc is said to be RetiredDS.
If Ks is also said to be SafeDS, we no longer need to retain Kc in the zone.
It is also Kc' removal time (Trem), the time that Kc is said to be Removed.
</t>
<t>
TretDS(Kc) >= Tkno(ks) <vspace blankLines="0" />
Trem(Kc) >= MAX(TsafDS(Ks), Tkno(Ks))
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, DS Withdrawn) <vspace blankLines="0" />
C(Kc) = Removed RetiredDS
</t>
<t>
Event 5:
From the perspective of the authoritative server, the rollover is complete.
After some delay, Kc and its DS have also expired from the caches.
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcachK <vspace blankLines="0" />
TexpDS(Kc) >= TretDS(Kc) + DcacheP
</t>
<t>
S(Kc) = (DNSKEY Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired
</t>
</section>
<section title="Double-Signature">
<t>
With Double-Signature, the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key.
After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed.
After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.
</t>
<t>
If you want to minimize the number of interactions to the parent, this rollover method is preferred over the Double-RRset method.
As a consequence, you have to wait with submitting the DS record of Ks, until it is safe to withdraw the DS record of Kc.
</t>
<figure>
<preamble>The timing diagram for such a rollover is:</preamble>
<artwork alt='Timeline Diagram of KSK Double-Signature Rollover'>
|1| |2| |3| |4| |5| |6| |7|
Kc | | | | | | |
- DNSKEY |----|-------|-----|-------|------|DcacheK|
- DS |----|-------|-----|DcacheP| | |
| | | | | | |
TretDS TexpDS Trem Tfor
Ks | | | | | | |
- DNSKEY | |DcacheK|-----|-------|------|-------|---
- DS | | | |DcacheP|------|-------|---
| | | | | | |
Tgen Tpub Tkno TactDS TsafDS
</artwork>
<postamble>Figure: KSK Double-Signature Rollover.</postamble>
</figure>
<t>
Event 1:
Ks is generated at time Tgen.
</t>
<t>
S(Ks) = (DNSKEY Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
Ks is introduced into the zone; it is added to the DNSKEY RRset, which is then signed by Ks and all currently actice KSKs (including Kc).
This is the publication time (Tpub), the time that Ks is said to be Published.
</t>
<t>
Tpub(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Introduced, DS Generated) <vspace blankLines="0" />
C(Ks) = Published
</t>
<t>
Event 3:
Before we can submit the corresponding DS,
the DNSKEY record for Ks must be published for long enough (DcacheK) to guarantee that any resolver that has a copy of the DNSKEY RRset also includes this key.
In other words, that any prior cached information about the DNSKEY RRset has expired.
This time is Tkno and Ks is said to be Known.
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK
</t>
<t>
S(Ks) = (DNSKEY Propagated, DS Generated) <vspace blankLines="0" />
C(Ks) = Known
</t>
<t>
Event 4:
At some later time, the DS RR corresponding to Ks is submitted to the parent zone for publication.
In addition, the request has been made to remove the DS RR corresponding to Kc from the parent zone.
This time is Ks' submit time (TactDS), the time that Ks is considered to be Submitted.
It is also Kc' retire time (TretDS), the time that Kc is considered to be RetiredDS.
</t>
<t>
TactDS(Ks) >= Tkno(Ks) <vspace blankLines="0" />
TretDS(kc) == TactDS(Kc)
</t>
<t>
S(Kc) = (DNSKEY Propagated, DS Withdrawn) <vspace blankLines="0" />
C(Ks) = Known RetiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, DS Introduced) <vspace blankLines="0" />
C(Ks) = Known ActiveDS
</t>
<t>
After the registration delay, the DS is published in the parent.
</t>
<t>
Event 5:
At some time later, all validating resolvers that have the DS RRset cached will have a a copy that includes the new DS record.
This is Ks' safe time (TsafDS), the time that the new KSK is said to be SafeDS. Consequently, Kc is said to be ExpiredDS (TexpDS).
</t>
<t>
TsafDS(Ks) >= TactDS(Ks) + DcacheP <vspace blankLines="0" />
TexpDS(Kc) >= TretDS(Kc) + DcacheP
</t>
<t>
S(Kc) = (DNSKEY Propagated, DS Dead) <vspace blankLines="0" />
C(kc) = Known ExpiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known SafeDS
</t>
<t>
Event 6:
When the new DS record has been propagated, the DNSKEY record of Kc can be removed from the zone.
This is Kc' removal time (Trem), the time that Kc is said to be Removed.
</t>
<t>
Trem(Kc) >= TsafDS(Ks)
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, DS Dead) <vspace blankLines="0" />
C(Kc) = Removed ExpiredDS
</t>
<t>
Event 7:
From the perspective of the authoritative server, the rollover is complete.
After some delay, The DNSKEY record for Kc has also expired from the caches.
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcacheK
</t>
<t>
S(Kc) = (DNSKEY Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Forgotten ExpiredDS
</t>
</section>
<section title="Double-DS">
<t>
In this case, first 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 waiting another interval, during which the old DNSKEY RRset expires from caches, the old DS record is removed.
</t>
<t>
If you want to keep the size of the DNSKEY RRset to a minimum, this rollover method is preferred over Double-RRset.
It does require the additional administrative overhead of two interactions with the parent to roll a KSK.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of KSK Double-DS Rollover'>
|1| |2| |3| |4| |5| |6| |7|
Kc | | | | | | |
- DNSKEY |----|-------|-------|DcacheK| | |
- DS |----|-------|-------|-------|-----|DcacheP|
| | | | | | |
Trem Tfor TretDS TexpDS
Ks | | | | | | |
- DNSKEY | | | |DcacheK|-----|-------|---
- DS | |DcacheP|-------|-------|-----|-------|---
| | | | | | |
Tgen TactDS TsafDS Tpub Tkno
</artwork>
<postamble>Figure: KSK Double-DS Rollover.</postamble>
</figure>
<t>
Event 1:
Ks is generated at time Tgen.
</t>
<t>
S(Ks) = (DNSKEY Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
Before we introduce the new key Ks into the zone, we are going to submit the new DS.
We can do that, because there exists a valid chain of trust for the same algorithm (Kc).
This time is Ks' submit time (TactDS), the time that the DS record for Ks was submitted and is said to be ActiveDS.
</t>
<t>
TactDS(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Generated, DS Introduced) <vspace blankLines="0" />
C(Kc) = ActiveDS
</t>
<t>
After some delay, the DS becomes available in the parent zone.
</t>
<t>
Event 3:
Some time later, the new DS RRset has been propagated.
This is Ks' safe time (TsafDS), the time that Ks is said to be SafeDS.
</t>
<t>
TsafDS(Ks) >= TactDS(Ks) + DcacheP
</t>
<t>
S(Ks) = (DNSKEY Generated, DS Propagated) <vspace blankLines="0" />
C(Ks) = SafeDS
</t>
<t>
Event 4:
Because there are now two trust anchors a resolver can use, we can switch the KSK in the DNSKEY RRset.
We stop signing with Kc and sign the DNSKEY RRset with Ks.
This time is Ks' publish time (Tpub), the time that Ks is said to be Published.
It is also Kc' removal time (Trem), the time that Kc is said to be Removed.
</t>
<t>
Tpub(Ks) >= TsafDS(Ks) <vspace blankLines="0" />
Trem(Kc) == Tpub(Ks)
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, DS Propagated) <vspace blankLines="0" />
C(Kc) = Removed SafeDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Introduced, DS Propagated) <vspace blankLines="0" />
C(Ks) = Published SafeDS
</t>
<t>
Event 5:
We have to wait before Kc has been expired from the caches, before we can withdraw the DS record of Kc.
When the DNSKEY RRset that includes Kc has been expired, Kc is said to be forgotten and Ks is said to be Known.
This happens at Ks' known time, given by:
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK <vspace blankLines="0" />
Tfor(Kc) == Tkno(Ks)
</t>
<t>
S(Kc) = (DNSKEY Dead, DS Propagated) <vspace blankLines="0" />
C(Kc) = Forgotten SafeDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known SafeDS
</t>
<t>
Event 6:
Now that we have a key Ks that is said to be Propagated and SafeDS, we are ready to withdraw the DS for Kc.
We call this Kc' retire time (TretDS), the time that we don't need a secure delegation for Kc anymore.
</t>
<t>
TretDS(Kc) >= Tkno(Ks)
</t>
<t>
S(Kc) = (DNSKEY Dead, DS Withdrawn) <vspace blankLines="0" />
C(Kc) = Forgotten RetiredDS
</t>
<t>
Event 7:
From the perspective of the authoritative server, the rollover is complete.
After some delay, The DS record for Kc has expired from the caches.
This is Texp, given by:
</t>
<t>
Texp(Kc) >= Tret(Kc) + DcacheP
</t>
<t>
S(Kc) = (DNSKEY Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Forgotten ExpiredDS
</t>
</section>
<section title="Interaction with Configured Trust Anchors">
<t>
Zone managers may want to take into account the possibility that some validating resolvers may have their KSK
configured as a trust anchor directly, as described in <xref target="RFC5011"/>.
This influences the value of DcacheK, the time to guarantee that any resolver that has a copy of the newest DNSKEY RRset.
</t>
<section title="Adding a KSK">
<t>
When the new key is introduced, the delay DcacheK between Tpub and Tkno is also subject to the condition:
</t>
<t>
DcacheK' = MAX(DcacheK, 2 * (queryInterval + x * retryTime) + c)
</t>
<t>
The right hand side of this expression is two times the Active Refresh time defined in section 2.3 in <xref target="RFC5011"/>.
This ensures that the successor key is at least seen twice by 5011-enabled validators.
The parameter x is the maximum number of retries that is taken as a safety margin, in case an Active Refresh fails.
The parameter c is a constant that can be taken as an additional safety margin.
</t>
<t>
Most probably, this delays the time when a key is said to be Known.
</t>
</section>
<section title="Removing a KSK">
<t>
When the current key is ready to be removed from the zone, it is instead said to be Revoked.
The REVOKE bit is said and the key is published for DcacheK' time:
</t>
<t>
DcacheK' = MAX(DcacheK, (queryInterval + x * retryTime) + c)
</t>
<t>
The right hand side of this expression is the Active Refresh time defined in section 2.3 in <xref target="RFC5011">RFC5011</xref>.
This ensures that the revoked key is at least seen once by 5011-enabled validators.
</t>
<t>
After that delay, we can guarantee that every 5011-enabled resolver has seen the revoked key and it may be removed from the zone.
Another DcacheK delay, the key has fully expired from all the resolver caches.
</t>
</section>
</section>
</section>
<section title="Rollovers in a Single Type Signing Scheme" anchor="stss-rollovers">
<t>
In situations where you use a Single Type Signing Scheme, you can combine one of the ZSK rollover methods with one of the KSK rollover methods.
However, not all combinations are possible.
The KSK Double-DS rollover is only suitable for combining with the ZSK Double-RRSIG rollover, because both keep the DNSKEY RRset to a minimum size.
The other ZSK rollovers require a period where both the current key and its successor are being served at the same time.
</t>
<t>
The KSK Double-RRset method is suitable with both the other ZSK rollover methods, but does not gain any advantages when combined with the ZSK Pre-Publication method.
Therefore, we can leave that combination out.
The KSK Double-Signature method is suitable with both the ZSK Double-Signature and the ZSK Pre-Publication method.
</t>
<t>
To conclude, we can identify four different rollover methods for the Single Type Signing Scheme.
</t>
<section title="Double-RRset">
<t>
This is a combination of the ZSK Double-Signature rollover and the KSK Double-RRset rollover.
The new KSK is added to the DNSKEY RRset, and all RRsets are 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 all zone RRsets to expire from validating resolver caches, the old DNSKEY and DS record are removed.
</t>
<t>
Double-RRset is the fastest way to replace keys in a Single Type Signing Scheme.
However, it does have a lot of disadvantages of -
it requires two signatures and two keys during the period of the rollover, as well as two interactions with the parent.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of STSS Double-RRset Rollover'>
|1| |2| |3| |4| |5|
Kc | | | | |
- RRSIG |----|-------|-----|DcacheZ|
- DNSKEY |----|-------|-----|DcacheK|
- DS |----|-------|-----|DcacheP|
| | | | |
Trem Tfor
Tret Texp
TretDS TexpDS
Ks | | | | |
- RRSIG | |DcacheZ|-----|-------|---
- DNSKEY | |DcacheK|-----|-------|---
- DS | |DcacheP|-----|-------|---
| | | | |
Tgen Tpub Tkno
Tact Tsaf
TactDS TsafDS
</artwork>
<postamble>Figure: STSS Double-RRset Rollover.</postamble>
</figure>
<t>
The rollover method is almost the same as that of the KSK Double-RRset rollover, except we now have to take DcacheZ into account.
</t>
</section>
<section title="Double-Signature">
<t>
This is a combination of the ZSK Double-Signature rollover and the KSK Double-Signature rollover.
The new key is added to the DNSKEY RRset and all RRsets are then signed with both the old and new key.
After waiting for the old RRsets 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 DNSKEY RRset,
and all RRsets are signed with the new key only.
</t>
<t>
This rollover minimizes the number of interactions with the parent zone.
However, for the period of the rollover all RRsets are still signed with two keys, so increasing the size of the zone and the size of the response.
</t>
<figure>
<preamble>The timing diagram for such a rollover is:</preamble>
<artwork alt='Timeline Diagram of STSS Double-Signature Rollover'>
|1| |2| |3| |4| |5| |6| |7|
Kc | | | | | | |
- RRSIG |----|-------|-----|-------|------|DcacheZ|
- DNSKEY |----|-------|-----|-------|------|DcacheK|
- DS |----|-------|-----|DcacheP| | |
| | | | | | |
TretDS TexpDS Trem Tfor
Tret Texp
Ks | | | | | | |
- RRSIG | |DcacheZ|-----|-------|------|-------|---
- DNSKEY | |DcacheK|-----|-------|------|-------|---
- DS | | | |DcacheP|------|-------|---
| | | | | | |
Tgen Tpub Tkno TactDS TsafDS
Tact Tsaf
</artwork>
<postamble>Figure: STSS Double-Signature Rollover.</postamble>
</figure>
<t>
The rollover diagram is almost the same as that of the KSK Double-Signature rollover, except we now have to take DcacheZ into account.
</t>
</section>
<section title="Pre-Publication">
<t>
This is a combination of the ZSK Pre-Publication rollover and the KSK Double-Signature rollover and requires only one interaction with the parent.
In addition, your non-DNSKEY RRsets require only one signature during the rollover.
If speed is not an issue, this rollover method is considered to be the best practice in a Single Type Signing Scheme environment.
</t>
<t>
The new key is added to the DNSKEY RRset and the DNSKEY RRset is then signed with both the old and new key.
Other RRsets will only be signed with the old key.
Only after the DS has been switched, the signatures of other RRsets are replaced with that of the new key.
After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset, and is signed with the new key only.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of STSS Pre-Publication Rollover'>
|1| |2| |3| |4| |5| |6| |7| |8| |9|
Kc | | | | | | | | |
- RRSIG |----|-------|-----|-------|-------|DcacheZ| | |
- DNSKEY |----|-------|-----|-------|-------|-------|----|DcacheK|
- DS |----|-------|-----|DcacheP| | | | |
| | | | | | | | |
TretDS TexpDS Tret Texp Trem Tfor
Ks | | | | | | | | |
- RRSIG | | | | | |DcacheZ|----|-------|
- DNSKEY | |DcacheK|-----|-------|-------|-------|----|-------|
- DS | | | |DcacheP|-------|-------|----|-------|
| | | | | | | | |
Tgen Tpub Tkno TactDS TsafDS Tact Tsaf
</artwork>
<postamble>Figure: STSS Pre-Publication Rollover.</postamble>
</figure>
<t>
Event 1:
Key Ks is generated at the generate time (Tgen).
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
The DNSKEY record of Ks is put into the zone, i.e. it is added to the DNSKEY RRset which is then re-signed with the Ks and all other current KSKs (including Kc).
The time at which this occurs is Ks' publication time (Tpub), and the key is now said to be Published.
Note that the key is not yet used to sign other RRsets.
</t>
<t>
Tpub(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Introduced, RRSIG Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Published
</t>
<t>
Event 3:
Before we can switch the DS,
the DNSKEY record for Ks must be published for long enough (DcacheK) to guarantee that any resolver that has a copy of the DNSKEY RRset also includes this key.
After this delay, the key is said to be Known and the DS record may be submitted.
The time at which this event occurs is Ks' known time (Tkno), which is given by:
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK
</t>
<t>
S(Ks) = (DNSKEY Propagated, RRSIG Generated, DS Generated) <vspace blankLines="0" />
C(ks) = Known
</t>
<t>
Event 4:
The time that the DS record of Ks is submitted is at Ks' submit time (TactDS).
Ks is said to be ActiveDS.
At the same time, the DS record of Kc is withdrawn (TretDS) and Kc is said to be RetiredDS.
</t>
<t>
TactDS(Ks) >= Tkno(Ks)
TretDS(Kc) == TactDS(Ks)
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Propagated, DS Withdrawn) <vspace blankLines="0" />
C(Kc) = Known Safe RetiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Generated, DS Introduced) <vspace blankLines="0" />
C(Ks) = Known ActiveDS
</t>
<t>
Some time later, the new DS RRset is published at the parent.
</t>
<t>
Event 5:
Some time later, we can guarantee that all validating resolvers use the DS RRset that includes a copy of the DS record of DS.
At this time, Ks' safe time (TsafDS), Ks is said to be SafeDS.
But we still use Kc as ZSK.
</t>
<t>
TsafDS(Ks) >= TactDS(Ks) + DcacheP <vspace blankLines="0" />
TexpDS(Kc) >= TretDS(Kc) + DcacheP
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Propagated, DS Dead) <vspace blankLines="0" />
C(kc) = Known Safe ExpiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Generated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known SafeDS
</t>
<t>
Event 6:
At some point in time, the decision is made to actually 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.
This point in time is Ks' active time (Tact), the time that Ks is said to be Active.
It is also Kc' retire time (Tret), the time that Kc is said to be Retired.
</t>
<t>
Tact(Ks) >= TsafDS(Ks) <vspace blankLines="0" />
Tret(Kc) == Tact(Ks)
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Withdrawn, DS Dead)) <vspace blankLines="0" />
C(Kc) = Known Retired ExpiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Introduced, DS Propagated)) <vspace blankLines="0" />
C(Ks) = Known Active SafeDS
</t>
<t>
Event 7:
Kc needs to be retained in the zone whilst any RRSIG records created by the retired key are still published in the zone or held in resolver caches.
In other words, Kc should be retained in the zone until all RRSIG records created by Ks have been propagated.
This time is Ks' safe time (Tsaf), the time that Ks is considered to be Safe, and Kc' expiration time (Texp), the time that Kc is considered to be Expired.
</t>
<t>
Tsaf(Ks) >= Tact(Ks) + DcacheZ <vspace blankLines="0" />
Texp(Kc) == Tsaf(Ks)
</t>
<t>
S(Kc) = (DNSKEY Propagated, RRSIG Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Known Expired ExpiredDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known Safe SafeDS
</t>
<t>
Event 8:
When all new signatures have been propagated, Kc can be removed from the zone and the DNSKEY RRset re-signed with the current KSK.
This time is Kc' removal time (Trem), the time that Kc is considered to be Removed.
</t>
<t>
Trem(Kc) >= Tsaf(Ks)
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, RRSIG Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Removed Expired ExpiredDS
</t>
<t>
Event 9:
From the perspective of the authoritative server, the rollover is complete.
After some delay, The DNSKEY record for Kc has expired from the caches.
This is Tfor, the time that the key is said to be Forgotten.
</t>
<t>
Tfor(Kc) >= Trem(Kc) + DcacheK
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired ExpiredDS
</t>
</section>
<section title="Double-DS">
<t>
This is a combination of the ZSK Double-RRSIG rollover and the KSK Double-DS rollover.
This keeps your DNSKEY RRset to a minimum size, but at the cost of double signatures in your zone and double DS at the parent.
</t>
<t>
The new signatures are added to the zone and the new DS is submitted.
Once all signatures and the DS record have been propagated, the DNSKEY is switched.
After waiting a further interval for this switch to be reflected in caches, the old signatures are removed and the old DS is withdrawn from the parent zone.
</t>
<figure>
<preamble>The timeline diagram looks like this:</preamble>
<artwork alt='Timeline Diagram of STSS Double-DS Rollover'>
|1| |2| |3| |4| |5| |6| |7| |8| |9|
Kc | | | | | | | | |
- RRSIG |----|-------|-----|-------|-------|DcacheZ| | |
- DNSKEY |----|-------|-----|-------|-------|-------|----|DcacheK|
- DS |----|-------|-----|DcacheP| | | | |
| | | | | | | | |
TretDS TexpDS Tret Texp Trem Tfor
Ks | | | | | | | | |
- RRSIG | | | | | |DcacheZ|----|-------|
- DNSKEY | |DcacheK|-----|-------|-------|-------|----|-------|
- DS | | | |DcacheP|-------|-------|----|-------|
| | | | | | | | |
Tgen Tpub Tkno TactDS TsafDS Tact Tsaf
</artwork>
<postamble>Figure: STSS Double-DS Rollover.</postamble>
</figure>
<t>
Event 1:
Key Ks is generated at the generate time (Tgen).
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Generated, DS Generated) <vspace blankLines="0" />
C(Ks) = Generated
</t>
<t>
Event 2:
Before we introduce the new key Ks into the zone, we are going to add the new signatures and submit the new DS.
This time is Ks' active time (Tact), the time that Ks is said to be Active.
It is also Ks' submit time (TactDS), the time that the DS record for Ks was submitted and is said to be ActiveDS.
</t>
<t>
Tact(Ks) >= Tgen(Ks) <vspace blankLines="0" />
TactDS(Ks) >= Tgen(Ks)
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Introduced, DS Introduced) <vspace blankLines="0" />
C(Kc) = Active ActiveDS
</t>
<t>
After some delay, the DS becomes available in the parent zone.
</t>
<t>
Event 3:
Some time later, the new signatures and the new DS RRset have been propagated.
This is Ks' safe time (Tsaf, TsafDS), the time that Ks is said to be Safe and SafeDS.
</t>
<t>
Tsaf(Ks) >= Tact(Ks) + DcacheZ <vspace blankLines="0" />
TsafDS(Ks) >= TactDS(Ks) + DcacheP
</t>
<t>
S(Ks) = (DNSKEY Generated, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Safe SafeDS
</t>
<t>
Event 4:
Because there are now two trust anchors a resolver can use, we can switch the KSK in the DNSKEY RRset.
This time is Ks' publish time (Tpub), the time that Ks is said to be Published.
It is also Kc' removal time (Trem), the time that Kc is removed from the zone.
</t>
<t>
Tpub(Ks) >= MAX(TsafDS(Ks), Tsaf(Ks)) <vspace blankLines="0" />
Trem(Kc) == Tpub(Ks)
</t>
<t>
S(Kc) = (DNSKEY Withdrawn, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Kc) = Removed Safe SafeDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Introduced, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Published Safe SafeDS
</t>
<t>
Event 5:
We have to wait before the signatures of Kc and its corresponding DS record have been expired from the caches, before we can withdraw the DNSKEY record of Kc.
When the DNSKEY RRset that includes Kc has been expired, Ks is said to be Known and Kc is said to be Removed.
This happens at Ks' known time, given by:
</t>
<t>
Tkno(Ks) >= Tpub(Ks) + DcacheK, Trem(Kc) == Tkno(Ks)
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Kc) = Forgotten Safe SafeDS <vspace blankLines="0" />
S(Ks) = (DNSKEY Propagated, RRSIG Propagated, DS Propagated) <vspace blankLines="0" />
C(Ks) = Known Safe SafeDS
</t>
<t>
Event 6:
Now that we have a key Ks that is said to be Propagated and SafeDS, we are ready to withdraw the signatures and DS for Kc.
We call this Kc' retire time (Tret, TretDS), the time Kc is said to be Retired and RetiredDS.
</t>
<t>
Tret(Kc) >= Tkno(Ks) <vspace blankLines="0" />
TretDS(Kc) >= Tkno(Ks)
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Withdrawn, DS Withdrawn) <vspace blankLines="0" />
C(Kc) = Forgotten Retired RetiredDS
</t>
<t>
Event 7:
From the perspective of the authoritative server, the rollover is complete.
After some delay, The signatures of Kc and its corresponding DS record have expired from the caches.
</t>
<t>
Texp(Kc) >= Tret(Kc) + DcacheZ <vspace blankLines="0" />
TexpDS(Kc) >= TretDS(Kc) + DcacheP
</t>
<t>
S(Kc) = (DNSKEY Dead, RRSIG Dead, DS Dead) <vspace blankLines="0" />
C(Kc) = Forgotten Expired ExpiredDS
</t>
</section>
</section>
<section title="Stand-by Keys" anchor="standby">
<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 ready to sign the zone, having at least one additional key (a stand-by key) in this state at all times will minimise delay.
</t>
<t>
In the case of a ZSK, a stand-by key only makes sense with the Pre-Publication method, since with the Double-Signature and Double-RRSIG methods,
the stand-by key would be used for signing.
The goal is to make the stand-by key Known.
This goal is reached at Tkno, step 3 in the Pre-Publication method timeline diagram.
</t>
<t>
A successor key must always be published soon enough so that the key lifetime of the predecessor key does not exceed.
That means that the successor ZSK Ks must at latest be published DcacheK delay before the lifetime of the predecessor ZSK kc has reached:
</t>
<t>
Tpub(Ks) <= Tact(Kc) + Lzsk - DcacheK
</t>
<t>
Here, Lzsk is the lifetime of ZSKs according to policy.
</t>
<t>
In the case of a KSK, a stand-by key only makes sense with the Double-DS method, since in the other cases, the key would be needed to sign the DNSKEY RRset.
The goal is to get the stand-by key in the SafeDS condition.
This goal is reached at TsafDS, step 3 in the Double-DS method timeline diagram.
</t>
<t>
The DS record for the successor KSK Ks should be propagated to the caches before the key lifetime of the predecessor KSK Kc exceeds:
</t>
<t>
TactDS(Ks) <= Tact(Kc) + Lksk - DcacheP
</t>
<t>
Here, Lksk is the lifetime of KSKs according to policy.
</t>
<t>
Because a stand-by KSK only makes sense with the Double-DS method, stand-by keys in a STSS is not applicable.
This is because the Double-DS method is not easy integratable with one of the ZSK rollover methods.
</t>
</section>
</section>
<section title="Policy rollover" anchor="policy">
<t>
Besides your scheduled and unscheduled key rollovers, changes in policy may occur.
The initial transition is enabling DNSSEC. The counterpart, disabling DNSSEC, is also possible.
Two other policy changes we have encountered are are algorithm rollover and changing signing schemes.
</t>
<section title="Enabling DNSSEC" anchor="enabling">
<t>
When a zone makes the transition from going insecure to secure, the initial set of keys safely need to be introduced into the zone.
The goals of this event is to make a ZSK (Kz) and a KSK (Kk) both Known and Safe.
</t>
<t>
One must take into account that resolver caches may hold unsigned RRsets.
Therefore, validating resolvers should not know about the initial DNSKEY RRset before all unsigned RRsets have been expired from the caches.
This means that the zone must be fully signed, before the DS associated with the initial KSK is published.
Only if you are afraid that a key scraper fetches your DNSKEY RRset too soon,
you should wait with publishing your DNSKEY RRset until enough time has elapsed for all unsigned RRsets to expire from all resolver caches.
The ZSK and KSK can be the same key, for example in a Single Type Signing Scheme.
</t>
<t>
<figure>
<preamble>The timeline diagram is shown below:</preamble>
<artwork alt='Timeline Diagram of Enabling DNSSEC'>
|1| |2| |3| |4| |5|
Kz | | | | |
- RRSIG | |DcacheZ|------|-------|---
- DNSKEY | |DcacheK|------|-------|---
| | | | |
Tgen Tpub Tkno
Tact Tsaf
Kk | | | | |
- DNSKEY | |DcacheK|------|-------|---
- DS | | | |DcacheP|---
| | | | |
Tgen Tpub Tkno TactDS TsafDS
</artwork>
<postamble>Figure: Enabling DNSSEC.</postamble>
</figure>
</t>
<t>
Event 1:
Kk and Kz are generated.
We call this Tgen, the time that the keys were Generated (note that Tgen for Kk could be different that Tgen for Kz).
</t>
<t>
S(Kk) = (DNSKEY Generated, DS Generated) <vspace blankLines="0" />
C(Kk) = Generated <vspace blankLines="0" />
S(Kz) = (DNSKEY Generated, RRSIG Generated) <vspace blankLines="0" />
C(Kk) = Generated
</t>
<t>
Event 2:
The keys are put into the zone and are immediately used for signing.
Because there exists no pointer to the fact that our zone is DNSSEC enabled, the DNSKEY and RRSIG records may be introduced at the same time.
This is the publish time (Tpub), the time that the keys are Published.
It is also Kz' active time (Tact), the time that Kz is said to be Active.
</t>
<t>
Tpub(Kk) >= Tgen(Kk) <vspace blankLines="0" />
Tpub(Kz) >= Tgen(Kz) <vspace blankLines="0" />
Tact(Kz) == Tpub(Kz)
</t>
<t>
S(Kk) = (DNSKEY Introduced, DS Generated) <vspace blankLines="0" />
C(Kk) = Published <vspace blankLines="0" />
S(Kz) = (DNSKEY Introduced, RRSIG Introduced) <vspace blankLines="0" />
C(Kz) = Published Active
</t>
<t>
Event 3:
Before we can submit the DS record, Kz must be considered Known and Safe.
Once that has happened, we are done for the ZSK.
This time is Kz' known time (Tkno).
</t>
<t>
Tkno(Kk) >= Tpub(Kk) + DcacheP <vspace blankLines="0" />
Tkno(Kk) == Tkno(Kz) <vspace blankLines="0" />
Tsaf(Kz) >= Tact(Kz) + DcacheZ
</t>
<t>
S(Kk) = (DNSKEY Propagated, DS Generated) <vspace blankLines="0" />
C(Kk) = Known <vspace blankLines="0" />
S(Kz) = (DNSKEY Propagated, RRSIG Propagated) <vspace blankLines="0" />
C(Kz) = Known Safe
</t>
<t>
Because this is the first DNSKEY for this zone, the Dttl for the DNSKEY RRset is Ingc, the negative cache interval from the zone's SOA record,
calculated according to <xref target="RFC2308">RFC2308</xref> as the minimum of the TTL of the SOA record itself and the MINIMUM field in the record's parameters:
</t>
<t>
Ingc = min(TTL(SOA), MINIMUM)
</t>
<t>
Event 4:
Once we are sure of the fact that the DNSKEY RRset and all RRSIG records have reached the caches, we may submit the DS to the parent.
We call this TactDS, the time that the DS has been submitted to the parent.
</t>
<t>
TactDS(Kk) >= Tkno(Kk)
</t>
<t>
S(Kk) = (DNSKEY Propagated, DS Introduced) <vspace blankLines="0" />
C(Kk) = Known ActiveDS
</t>
<t>
Event 5:
Some time later, the DS has been published in the parent zone.
Some more time later, all resolvers that have a copy of the DS RRset have one that includes the DS record of Kk.
</t>
<t>
TsafDS(Kk) >= TactDS(Kk) + DcacheP
</t>
<t>
S(Kk) = (DNSKEY Propagated, DS Propagated) <vspace blankLines="0" />
C(Kk) = Known SafeDS
</t>
<t>
Because this is the first DS for this zone, the Dttl for the DS RRset is Ingc, for the same reason as in step 3 for the DNSKEY RRset.
</t>
</section>
<section title="Disabling DNSSEC" anchor="disabling">
<t>
When a zone decides for whatever reason to go back to the Insecure status, the set of keys safely need to be removed from the zone.
We assume that there is a KSK (Kk) and a ZSK (Kz) that are Known and Safe.
The goals of this event is to make Kk and Kz both Forgotten and Expired.
</t>
<t>
<figure>
<preamble>The timeline diagram is shown below:</preamble>
<artwork alt='Timeline Diagram of Disabling DNSSEC'>
|0| |1| |3| |4| |5|
Kz | | | | |
- RRSIG |----|-------|------|DcacheZ|
- DNSKEY |----|-------|------|DcacheK|
| | | | |
Trem Tfor
Tret Texp
Kk | | | | |
- DNSKEY |----|-------|------|DcacheK|
- DS |----|DcacheP| | |
| | | | |
TretDS TexpDS Trem Tfor
</artwork>
<postamble>Figure: Disabling DNSSEC.</postamble>
</figure>
</t>
<t>
Event 1:
The DS record of Kk needs to be withdrawn.
This time is Kk' retire time (TretDS), the time that Kk is said to be RetiredDS.
</t>
<t>
S(Kk) = (DNSKEY Propagated, DS Withdrawn) <vspace blankLines="0" />
C(Kk) = Known RetiredDS <vspace blankLines="0" />
</t>
<t>
Event 2:
We have to wait until the DS record of Kk has expired from all resolver caches.
This time is Kk' expire time (TexpDS), the time that Kk is said to be ExpiredDS.
</t>
<t>
TexpDS(Kk) >= TretDS(Kk) + DcacheP
</t>
<t>
S(Kk) = (DNSKEY Propagated, DS Dead) <vspace blankLines="0" />
C(Kk) = Known ExpiredDS <vspace blankLines="0" />
</t>
<t>
Event 3:
Now that we can guarantee that no secure chain of trust to Kk exist anymore, we can retire the ZSK and withdraw both keys.
This time is Trem, the time that the keys are removed from the zone.
</t>
<t>
Trem(Kk) >= TexpDS(Kk) <vspace blankLines="0" />
Trem(Kz) == Trem(Kk) <vspace blankLines="0" />
Tret(Kz) == Trem(kz)
</t>
<t>
S(Kk) = (DNSKEY Withdrawn, DS Dead) <vspace blankLines="0" />
C(Kk) = Removed ExpiredDS <vspace blankLines="0" />
S(Kz) = (DNSKEY Withdrawn, RRSIG Withdrawn) <vspace blankLines="0" />
C(Kz) = Removed Retired
</t>
<t>
Event 4:
After some delay, all information about the keys have expired from the caches.
</t>
<t>
Tfor(Kk) >= Trem(Kk) + DcacheK <vspace blankLines="0" />
Tfor(Kz) == Tfor(Kk) <vspace blankLines="0" />
Texp(Kz) >= Tret(Kz) + DcacheZ
</t>
<t>
S(Kk) = (DNSKEY Dead, DS Dead) <vspace blankLines="0" />
C(Kk) = Forgotten ExpiredDS <vspace blankLines="0" />
S(Kz) = (DNSKEY Dead, RRSIG Dead) <vspace blankLines="0" />
C(Kz) = Forgotten Expired
</t>
</section>
<section title="Algorithm Rollover" anchor="algo-rollover">
<t>
When changing algorithms, you can either add, remove or replace an algorithm.
Adding and removing an algorithm follow the same timings as enabling and disabling DNSSEC.
Replacing an algorithm can be done with a STSS Double-Signature rollover or a KSK and ZSK Double-Signature Rollover at the same time.
[MM: This needs more text, but I am awaiting the discussion about algorithm rollover and how to interpret section 2.2 of RFC 4035]
</t>
</section>
<section title="KSK-ZSK Split or Single Type Signing Scheme" anchor="split-rollover">
<t>
When changing signing schemes, you should follow the timelines of the most restricting signing scheme.
The STSS signing scheme makes some rollover combinations unsuitable, thus it can be considered the most restricted signing scheme.
In the case of moving to a KSK-ZSK Split, Ks is used as the successor key in the STSS rollover methods, and it now reflects both the successor ZSK and KSK.
In the case of moving away from a KSK-ZSK Split, Kc is used as the predecessor key in the STSS rollover methods, and it now reflects both the predecessor
ZSK and KSK.
[MM: This could perhaps also use more explanation.]
</t>
</section>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
This memo includes no request to IANA.
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>
This document does not introduce any new security issues beyond those already discussed in <xref target="RFC4033">RFC4033</xref>,
<xref target="RFC4034">RFC4034</xref>. <xref target="RFC4035">RFC4035</xref> and <xref target="RFC5011">RFC5011</xref>.
</t>
</section>
<section title="Acknowledgements" anchor="acknnowledgements">
<t>
Special acknowledgments and gratitude go out to Stephen Morris, Johan Ihren and John Dickinson, the authors of
<xref target="key-timing">the key-timing draft</xref>. Significant parts of the text is taken from that document.
Especially <xref target="zsk-rollovers"/> and <xref target="ksk-rollovers"/> are largely copied and
adjusted to the new introduced terminology from this document.
</t>
<t>
I also want to acknowledge Yuri Schaeffer, who brought to my attention the idea of key goals (<xref target="goals"/>)
and whose discussions helped to shape this document.
</t>
</section>
<section title="Changes with key-timing draft">
<t>
This document builds further on <xref target="key-timing">draft-ietf-dnsop-dnssec-key-timing</xref>.
The most important changes with respect to that document are:
</t>
<t>
- Introduced the concept of Rollover Considerations (Speed vs Size vs Interactions), that causes
the existence of different key rollover scenarios.
</t>
<t>
- Introduced the concept of Key Goals.
</t>
<t>
- Key States are unraveled to represent the status of each piece of information seperately.
Provides more flexibility. Used for combining rollover methods in a Single Type Singing Scheme.
</t>
<t>
- What were Key States in the key-timing draft, are now called Key Conditions.
A key can have more than one condition.
</t>
<t>
- Four new Key Conditions are introduced: Known, Safe, Forgotten and Expired, to represent whether information about the key exist in resolver caches.
The key conditions Ready and Dead are deprecated.
</t>
<t>
- Timelines for STSS Rollovers.
</t>
<t>
- Timelines for enabling and disabling DNSSEC.
</t>
<t>
- Text about policy rollover, such as algorithm rollover and changing signing schemes.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.4641" ?>
</references>
<references title="Normative References">
<?rfc include="reference.RFC.2308" ?>
<?rfc include="reference.RFC.4033" ?>
<?rfc include="reference.RFC.4034" ?>
<?rfc include="reference.RFC.4035" ?>
<?rfc include="reference.RFC.5011" ?>
<reference anchor='key-timing'>
<front>
<title>DNSSEC Key Timing Considerations</title>
<author initials='S.' surname='Morris' fullname='S. Morris'>
<organization/>
</author>
<author initials='J.' surname='Ihren' fullname='J. Ihren'>
<organization/>
</author>
<author initials='J.' surname='Dickinson' fullname='J. Dickinson'>
<organization/>
</author>
<date year='2010' month='July'/>
</front>
</reference>
<reference anchor='dnssec-bis'>
<front>
<title>Clarifications and Implementation Notes for DNSSECbis</title>
<author initials='S.' surname='Weiler' fullname='S. Weiler'>
<organization/>
</author>
<author initials='D.' surname='Blacka' fullname='D. Blacka'>
<organization/>
</author>
<date year='2010' month='November'/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:34:43 |