< draft-ietf-dnsop-rfc5011-security-considerations-07.txt   draft-ietf-dnsop-rfc5011-security-considerations-08.txt >
dnsop W. Hardaker dnsop W. Hardaker
Internet-Draft USC/ISI Internet-Draft USC/ISI
Updates: 7583 (if approved) W. Kumari Updates: 7583 (if approved) W. Kumari
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: April 21, 2018 October 18, 2017 Expires: June 2, 2018 November 29, 2017
Security Considerations for RFC5011 Publishers Security Considerations for RFC5011 Publishers
draft-ietf-dnsop-rfc5011-security-considerations-07 draft-ietf-dnsop-rfc5011-security-considerations-08
Abstract Abstract
This document extends the RFC5011 rollover strategy with timing This document extends the RFC5011 rollover strategy with timing
advice that must be followed in order to maintain security. advice that must be followed in order to maintain security.
Specifically, this document describes the math behind the minimum Specifically, this document describes the math behind the minimum
time-length that a DNS zone publisher must wait before signing time-length that a DNS zone publisher must wait before signing
exclusively with recently added DNSKEYs. It contains much math and exclusively with recently added DNSKEYs. It contains much math and
complicated equations, but the summary is that the key rollover / complicated equations, but the summary is that the key rollover /
revocation time is much longer than intuition would suggest. If you revocation time is much longer than intuition would suggest. If you
are not both publishing a DNSSEC trust anchor, and using RFC5011 to are not both publishing a DNSSEC DNSKEY, and using RFC5011 to
update that trust anchor, you probably don't need to read this advertise this DNSKEY as a new Secure Entry Point key for use as a
document. trust anchor, you probably don't need to read this document.
This document also describes the minimum time-length that a DNS zone This document also describes the minimum time-length that a DNS zone
publisher must wait after publishing a revoked DNSKEY before assuming publisher must wait after publishing a revoked DNSKEY before assuming
that all active RFC5011 resolvers should have seen the revocation- that all active RFC5011 resolvers should have seen the revocation-
marked key and removed it from their list of trust anchors. marked key and removed it from their list of trust anchors.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2018. This Internet-Draft will expire on June 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document History and Motivation . . . . . . . . . . . . . 3 1.1. Document History and Motivation . . . . . . . . . . . . . 3
1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3 1.2. Safely Rolling the Root Zone's KSK in 2017/2018 . . . . . 3
1.3. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timing Associated with RFC5011 Processing . . . . . . . . . . 5 4. Timing Associated with RFC5011 Processing . . . . . . . . . . 5
4.1. Timing Associated with Publication . . . . . . . . . . . 5 4.1. Timing Associated with Publication . . . . . . . . . . . 5
4.2. Timing Associated with Revocation . . . . . . . . . . . . 5 4.2. Timing Associated with Revocation . . . . . . . . . . . . 6
5. Denial of Service Attack Considerations . . . . . . . . . . . 6 5. Denial of Service Attack Walkthrough . . . . . . . . . . . . 6
5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 6
5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 7
6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8 6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 9
6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8 6.1. Equation Components . . . . . . . . . . . . . . . . . . . 9
6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 8 6.1.1. addHoldDownTime . . . . . . . . . . . . . . . . . . . 9
6.1.2. sigExpirationTime . . . . . . . . . . . . . . . . . . 9 6.1.2. sigExpirationTimeRemaining . . . . . . . . . . . . . 9
6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 9 6.1.3. activeRefresh . . . . . . . . . . . . . . . . . . . . 9
6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9 6.1.4. activeRefreshOffset . . . . . . . . . . . . . . . . . 9
6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 9 6.1.5. safetyMargin . . . . . . . . . . . . . . . . . . . . 10
6.1.6. Fully expanded equation . . . . . . . . . . . . . . . 10 6.2. Timing Requirements For Adding a New KSK . . . . . . . . 11
6.1.7. Timing Constraint Summary . . . . . . . . . . . . . . 10 6.2.1. Wait Timer Based Calculation . . . . . . . . . . . . 11
6.1.8. Additional Considerations . . . . . . . . . . . . . . 11 6.2.2. Wall-Clock Based Calculation . . . . . . . . . . . . 12
6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 11 6.2.3. Timing Constraint Summary . . . . . . . . . . . . . . 12
6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 12 6.2.4. Additional Considerations for RFC7583 . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6.2.5. Example Scenario Calculations . . . . . . . . . . . . 13
8. Operational Considerations . . . . . . . . . . . . . . . . . 12 6.3. Timing Requirements For Revoking an Old KSK . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.3.1. Wait Timer Based Calculation . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6.3.2. Wall-Clock Based Calculation . . . . . . . . . . . . 14
11. Normative References . . . . . . . . . . . . . . . . . . . . 13 6.3.3. Additional Considerations for RFC7583 . . . . . . . . 15
Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 14 6.3.4. Example Scenario Calculations . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Operational Considerations . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC5011] defines a mechanism by which DNSSEC validators can update [RFC5011] defines a mechanism by which DNSSEC validators can update
their list of trust anchors when they've seen a new key published in their list of trust anchors when they've seen a new key published in
a zone. However, RFC5011 [intentionally] provides no guidance to the a zone or revoke a properly marked key from a trust anchor list.
However, RFC5011 [intentionally] provides no guidance to the
publishers of DNSKEYs about how long they must wait before switching publishers of DNSKEYs about how long they must wait before switching
to exclusively using recently published keys for signing records, or to exclusively using recently published keys for signing records, or
how long they must wait before ceasing publication of a revoked key. how long they must wait before ceasing publication of a revoked key.
Because of this lack of guidance, zone publishers may derive Because of this lack of guidance, zone publishers may derive
incorrect assumptions about safe usage of the RFC5011 DNSKEY incorrect assumptions about safe usage of the RFC5011 DNSKEY
advertising, rolling and revocation process. This document describes advertising, rolling and revocation process. This document describes
the minimum security requirements from a publisher's point of view the minimum security requirements from a publisher's point of view
and is intended to complement the guidance offered in RFC5011 (which and is intended to complement the guidance offered in RFC5011 (which
is written to provide timing guidance solely to a Validating is written to provide timing guidance solely to a Validating
Resolver's point of view). Resolver's point of view).
1.1. Document History and Motivation 1.1. Document History and Motivation
To verify this lack of understanding is wide-spread, the authors To verify this lack of understanding is wide-spread, the authors
reached out to 5 DNSSEC experts to ask them how long they thought reached out to 5 DNSSEC experts to ask them how long they thought
they must wait before signing a zone exclusively with a new KSK they must wait before signing a zone exclusively with a new KSK
[RFC4033] that was being introduced according to the 5011 process. [RFC4033] that was being introduced according to the 5011 process.
All 5 experts answered with an insecure value, and we determined that All 5 experts answered with an insecure value, and we determined that
this lack of operational guidance is causing security concerns today this lack of operational guidance might cause security concerns in
and wrote this companion document to RFC5011. We hope that this deployment and wrote this companion document to RFC5011. We hope
document will rectify this understanding and provide better guidance that this document will rectify this understanding and provide better
to zone publishers that wish to make use of the RFC5011 rollover guidance to zone publishers that wish to make use of the RFC5011
process. rollover process.
1.2. Safely Rolling the Root Zone's KSK in 2017/2018 1.2. Safely Rolling the Root Zone's KSK in 2017/2018
One important note about ICANN's [currently upcoming] 2017/2018 KSK One important note about ICANN's (currently in process) 2017/2018 KSK
rollover plan for the root zone: the timing values chosen for rolling rollover plan for the root zone: the timing values chosen for rolling
the KSK in the root zone appear completely safe, and are not affected the KSK in the root zone appear completely safe, and are not affected
by the timing concerns introduced by this draft by the timing concerns introduced by this draft
1.3. Requirements notation 1.3. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Background 2. Background
The RFC5011 process describes a process by which a RFC5011 Validating The RFC5011 process describes a process by which a RFC5011 Resolver
Resolver may accept a newly published KSK as a trust anchor for may accept a newly published KSK as a trust anchor for validating
validating future DNSSEC signed records. It also describes the future DNSSEC signed records. It also describes the process for
process for publicly revoking a published KSK. This document publicly revoking a published KSK. This document augments that
augments that information with additional constraints, from the information with additional constraints, from the DNSKEY publication
DNSKEY publication and revocation's points of view. Note that this and revocation's points of view. Note that this document does not
document does not define any other operational guidance or define any other operational guidance or recommendations about the
recommendations about the RFC5011 process and restricts itself to RFC5011 process and restricts itself to solely the security and
solely the security and operational ramifications of switching to operational ramifications of switching to exclusively using recently
exclusively using recently added keys or removing a revoked keys too added keys or removing a revoked keys too soon.
soon.
Failure of a DNSKEY publisher to follow the minimum recommendations Failure of a DNSKEY publisher to follow the minimum recommendations
associated with this draft will result in potential denial-of-service associated with this draft can result in potential denial-of-service
attack opportunities against validating resolvers. Failure of a attack opportunities against validating resolvers. Failure of a
DNSKEY publisher to publish a revoked key for a long enough period of DNSKEY publisher to publish a revoked key for a long enough period of
time may result in RFC5011 Validating Resolvers leaving that key in time may result in RFC5011 Resolvers leaving that key in their trust
their trust anchor storage beyond the key's expected lifetime. anchor storage beyond the key's expected lifetime.
3. Terminology 3. Terminology
Trust Anchor Publisher The entity responsible for publishing a SEP Publisher The entity responsible for publishing a DNSKEY (with
DNSKEY that can be used as a trust anchor. the Secure Entry Point (SEP) bit set) that can be used as a trust
anchor.
Zone Signer The owner of a zone intending to publish a new Key- Zone Signer The owner of a zone intending to publish a new Key-
Signing-Key (KSK) that will become a trust anchor by validators Signing-Key (KSK) that may become a trust anchor for validators
following the RFC5011 process. following the RFC5011 process.
RFC5011 Validating Resolver A DNSSEC Validating Resolver that is RFC5011 Resolver A DNSSEC Resolver that is using the RFC5011
using the RFC5011 processes to track and update trust anchors. processes to track and update trust anchors.
Sometimes referred to as a "RFC5011 Resolver"
Attacker An entity intent on foiling the RFC5011 Validator's ability Attacker An entity intent on foiling the RFC5011 Resolver's ability
to successfully adopt the Zone Signer's new DNSKEY as a new trust to successfully adopt the Zone Signer's new DNSKEY as a new trust
anchor or to prevent the RFC5011 Validator from removing an old anchor or to prevent the RFC5011 Resolver from removing an old
DNSKEY from its list of trust anchors. DNSKEY from its list of trust anchors.
sigExpirationTime The amount of time remaining before the latest lastSigExpirationTime The latest value of any RRSIG Signature
RRSIG's Signature Expiration time is reached. Note that for Expiration field (which is a date and time) that has signed the
organizations pre-creating signatures this time may be fairly previous DNSKEY RRset before a new DNSKEY is introduced to a
lengthy unless they can be significantly assured their signatures publish DNSKEY RRset, or the DNSKEY RRset of a DNSKEY that is to
can not be replayed at a later date. sigExpirationTime will be revoked. Note that for organizations pre-creating signatures
fundamentally be the RRSIG's Signature Expiration time minus the this time may be fairly far in the future unless they can be
RRSIG's Signature Inception time when the signature is created. significantly assured that none of their pre-generated signatures
can be replayed at a later date.
sigExpirationTime The amount of time between the DNSKEY RRSIG's
Signature Inception field and the Signature Expiration field.
sigExpirationTimeRemaining The amount of time remaining before
latestSigExpirationTime is reached.
Also see Section 2 of [RFC4033] and [RFC7719] for additional Also see Section 2 of [RFC4033] and [RFC7719] for additional
terminology. terminology.
4. Timing Associated with RFC5011 Processing 4. Timing Associated with RFC5011 Processing
These sections define a high-level overview of [RFC5011] processing. These sections define a high-level overview of [RFC5011] processing.
These steps are not sufficient for proper RFC5011 implementation, but These steps are not sufficient for proper RFC5011 implementation, but
provide enough background for the reader to follow the discussion in provide enough background for the reader to follow the discussion in
this document. Readers need to fully understand [RFC5011] as well to this document. Readers need to fully understand [RFC5011] as well to
fully comprehend the importance of this document. fully comprehend the content and importance of this document.
4.1. Timing Associated with Publication 4.1. Timing Associated with Publication
RFC5011's process of safely publishing a new key and then making use RFC5011's process of safely publishing a new DNSKEY and then assuming
of that key falls into a number of high-level steps to be performed RFC5011 Resolvers have adopted it for trust falls into a number of
by the Trust Anchor Publisher. This document discusses the following high-level steps to be performed by the SEP Publisher. This document
scenario, which the principle way RFC5011 is currently being used discusses the following scenario, which the principle way RFC5011 is
(even though Section 6 of RFC5011 suggests having a stand-by key currently being used (even though Section 6 of RFC5011 suggests
available): having a stand-by key available):
1. Publish a new DNSKEY in the zone, but continue to sign the zone 1. Publish a new DNSKEY in a zone, but continue to sign the zone
with the old one. with the old one.
2. Wait a period of time. 2. Wait a period of time.
3. Begin to exclusively use recently published DNSKEYs to sign the 3. Begin to exclusively use recently published DNSKEYs to sign the
appropriate resource records. appropriate resource records.
This document discusses step 2 of the above process. Some This document discusses the time required to wait during step 2 of
interpretations of RFC5011 have erroneously determined that the wait the above process. Some interpretations of RFC5011 have erroneously
time is equal to RFC5011's "hold down time". Section 5 describes an determined that the wait time is equal to RFC5011's "hold down time".
attack based on this (common) erroneous belief, which can result in a Section 5 describes an attack based on this (common) erroneous
denial of service attack against the zone. belief, which can result in a denial of service attack against the
zone.
4.2. Timing Associated with Revocation 4.2. Timing Associated with Revocation
RFC5011's process of advertising that an old key is to be revoked RFC5011's process of advertising that an old key is to be revoked
from RFC5011 validating resolvers falls into a number of high-level from RFC5011 Resolvers falls into a number of high-level steps:
steps:
1. Set the revoke bit on the DNSKEY to be revoked. 1. Set the revoke bit on the DNSKEY to be revoked.
2. Sign the revoked DNSKEY with itself. 2. Sign the revoked DNSKEY with itself.
3. Wait a period of time. 3. Wait a period of time.
4. Remove the revoked key from the zone. 4. Remove the revoked key from the zone.
This document discusses step 3 of the above process. Some This document discusses the time required to wait in step 3 of the
interpretations of RFC5011 have erroneously determined that the wait above process. Some interpretations of RFC5011 have erroneously
time is equal to RFC5011's "hold down time". This document describes determined that the wait time is equal to RFC5011's "hold down time".
an attack based on this (common) erroneous belief, which results in a This document describes an attack based on this (common) erroneous
revoked DNSKEY potentially remaining as a trust anchor in a RFC5011 belief, which results in a revoked DNSKEY potentially remaining as a
validating resolver long past its expected usage. trust anchor in a RFC5011 Resolver long past its expected usage.
5. Denial of Service Attack Considerations 5. Denial of Service Attack Walkthrough
If an attacker is able to provide a RFC5011 Validating Resolver with This section serves as an illustrative example of the problem being
past responses, such as when it is in-path or able to perform any discussed in this document. Note that in order to keep the example
number of cache poisoning attacks, the attacker may be able to leave simple enough to understand, some simplifications were made (such as
compliant RFC5011-Validating Resolvers without an appropriate DNSKEY by not creating a set of pre-signed RRSIGs and by not using values
trust anchor. This scenario will remain until an administrator that result in the addHoldDownTime not being evenly divisible by the
manually fixes the situation. activeRefresh value); the mathematical formulas in Section 6,
however, are complete.
If an attacker is able to provide a RFC5011 Resolver with past
responses, such as when it is in-path or able to perform any number
of cache poisoning attacks, the attacker may be able to leave
compliant RFC5011 Resolvers without an appropriate DNSKEY trust
anchor. This scenario will remain until an administrator manually
fixes the situation.
The time-line below illustrates this situation. The time-line below illustrates this situation.
5.1. Enumerated Attack Example 5.1. Enumerated Attack Example
The following example settings are used in the example scenario The following example settings are used in the example scenario
within this section: within this section:
TTL (all records) 1 day TTL (all records) 1 day
skipping to change at page 6, line 27 skipping to change at page 7, line 4
The time-line below illustrates this situation. The time-line below illustrates this situation.
5.1. Enumerated Attack Example 5.1. Enumerated Attack Example
The following example settings are used in the example scenario The following example settings are used in the example scenario
within this section: within this section:
TTL (all records) 1 day TTL (all records) 1 day
sigExpirationTime 10 days sigExpirationTime 10 days
Zone resigned every 1 day Zone resigned every 1 day
Given these settings, the sequence of events in Section 5.1.1 depicts Given these settings, the sequence of events in Section 5.1.1 depicts
how a Trust Anchor Publisher that waits for only the RFC5011 hold how a SEP Publisher that waits for only the RFC5011 hold time timer
time timer length of 30 days subjects its users to a potential Denial length of 30 days subjects its users to a potential Denial of Service
of Service attack. The timing schedule listed below is based on a attack. The timing schedule listed below is based on a SEP Publisher
Trust Anchor Publisher publishing a new Key Signing Key (KSK), with publishing a new Key Signing Key (KSK), with the intent that it will
the intent that it will later become a trust anchor. We label this later be used as a trust anchor. We label this publication time as
publication time as "T+0". All numbers in this sequence refer to "T+0". All numbers in this sequence refer to days before and after
days before and after this initial publication event. Thus, T-1 is this initial publication event. Thus, T-1 is the day before the
the day before the introduction of the new key, and T+15 is the 15th introduction of the new key, and T+15 is the 15th day after the key
day after the key was introduced into the fictitious zone being was introduced into the fictitious zone being discussed.
discussed.
In this dialog, we consider two keys within the example zone: In this dialog, we consider two keys within the example zone:
K_old An older KSK and Trust Anchor being replaced. K_old: An older KSK and Trust Anchor being replaced.
K_new A new KSK being transitioned into active use and expected to K_new: A new KSK being transitioned into active use and expected to
become a Trust Anchor via the RFC5011 process. become a Trust Anchor via the RFC5011 automated trust anchor
update process.
5.1.1. Attack Timing Breakdown 5.1.1. Attack Timing Breakdown
The steps shows an attack that foils the adoption of a new DNSKEY by The steps shows an attack that foils the adoption of a new DNSKEY by
a 5011 Validating Resolver when the Trust Anchor Publisher that a 5011 Resolver when the SEP Publisher that starts signing and
starts signing and publishing with the new DNSKEY too quickly. publishing with the new DNSKEY too quickly.
T-1 The K_old based RRSIGs are being published by the Zone Signer. T-1 The K_old based RRSIGs are being published by the Zone Signer.
[It may also be signing ZSKs as well, but they are not relevant to [It may also be signing ZSKs as well, but they are not relevant to
this event so we will not talk further about them; we are only this event so we will not talk further about them; we are only
considering the RRSIGs that cover the DNSKEYs in this document.] considering the RRSIGs that cover the DNSKEYs in this document.]
The Attacker queries for, retrieves and caches this DNSKEY set and The Attacker queries for, retrieves and caches this DNSKEY set and
corresponding RRSIG signatures. Note that for simplicity we corresponding RRSIG signatures.
assume the signer is not pre-signing and creating "valid in the
future" signature sets that may be stolen and replayed even later.
T+0 The Zone Signer adds K_new to their zone and signs the zone's T+0 The Zone Signer adds K_new to their zone and signs the zone's
key set with K_old. The RFC5011 Validator (later to be under key set with K_old. The RFC5011 Resolver (later to be under
attack) retrieves this new key set and corresponding RRSIGs and attack) retrieves this new key set and corresponding RRSIGs and
notices the publication of K_new. The RFC5011 Validator starts notices the publication of K_new. The RFC5011 Resolver starts the
the (30-day) hold-down timer for K_new. [Note that in a more (30-day) hold-down timer for K_new. [Note that in a more real-
real-world scenario there will likely be a further delay between world scenario there will likely be a further delay between the
the point where the Zone Signer publishes a new RRSIG and the point where the Zone Signer publishes a new RRSIG and the RFC5011
RFC5011 Validator notices its publication; though not shown in Resolver notices its publication; though not shown in this
this example, this delay is accounted for in the final solution example, this delay is accounted for in the equation in Section 6
below] below]
T+5 The RFC5011 Validator queries for the zone's keyset per the T+5 The RFC5011 Resolver queries for the zone's keyset per the
RFC5011 Active Refresh schedule, discussed in Section 2.3 of RFC5011 Active Refresh schedule, discussed in Section 2.3 of
RFC5011. Instead of receiving the intended published keyset, the RFC5011. Instead of receiving the intended published keyset, the
Attacker successfully replays the keyset and associated signatures Attacker successfully replays the keyset and associated signatures
recorded at T-1. Because the signature lifetime is 10 days (in recorded at T-1. Because the signature lifetime is 10 days (in
this example), the replayed signature and keyset is accepted as this example), the replayed signature and keyset is accepted as
valid (being only 6 days old, which is less than valid (being only 6 days old, which is less than
sigExpirationTime) and the RFC5011 Validator cancels the hold-down sigExpirationTime) and the RFC5011 Resolver cancels the (30-day)
timer for K_new, per the RFC5011 algorithm. hold-down timer for K_new, per the RFC5011 algorithm.
T+10 The RFC5011 Validator queries for the zone's keyset and T+10 The RFC5011 Resolver queries for the zone's keyset and
discovers a signed keyset that includes K_new (again), and is discovers a signed keyset that includes K_new (again), and is
signed by K_old. Note: the attacker is unable to replay the signed by K_old. Note: the attacker is unable to replay the
records cached at T-1, because they have now expired. Thus at records cached at T-1, because they have now expired. Thus at
T+10, the RFC5011 Validator starts (anew) the hold-timer for T+10, the RFC5011 Resolver starts (anew) the hold-timer for K_new.
K_new.
T+11 through T+29 The RFC5011 Validator continues checking the T+11 through T+29 The RFC5011 Resolver continues checking the zone's
zone's key set at the prescribed regular intervals. During this key set at the prescribed regular intervals. During this period,
period, the attacker can no longer replay traffic to their the attacker can no longer replay traffic to their benefit.
benefit.
T+30 The Zone Signer knows that this is the first time at which some T+30 The Zone Signer knows that this is the first time at which some
validators might accept K_new as a new trust anchor, since the validators might accept K_new as a new trust anchor, since the
hold-down timer of a RFC5011 Validator not under attack that had hold-down timer of a RFC5011 Resolver not under attack that had
queried and retrieved K_new at T+0 would now have reached 30 days. queried and retrieved K_new at T+0 would now have reached 30 days.
However, the hold-down timer of our attacked RFC5011 Validator is However, the hold-down timer of our attacked RFC5011 Resolver is
only at 20 days. only at 20 days.
T+35 The Zone Signer (mistakenly) believes that all validators T+35 The Zone Signer (mistakenly) believes that all validators
following the Active Refresh schedule (Section 2.3 of RFC5011) following the Active Refresh schedule (Section 2.3 of RFC5011)
should have accepted K_new as a the new trust anchor (since the should have accepted K_new as a the new trust anchor (since the
hold down time (30 days) + the query interval [which is just 1/2 hold down time (30 days) + the query interval [which is just 1/2
the signature validity period in this example] would have passed). the signature validity period in this example] would have passed).
However, the hold-down timer of our attacked RFC5011 Validator is However, the hold-down timer of our attacked RFC5011 Resolver is
only at 25 days (T+35 minus T+10); thus the RFC5011 won't consider only at 25 days (T+35 minus T+10); thus the RFC5011 Resolver won't
it a valid trust anchor addition yet, as the required 30 days have consider it a valid trust anchor addition yet, as the required 30
not yet elapsed. days have not yet elapsed.
T+36 The Zone Signer, believing K_new is safe to use, switches their T+36 The Zone Signer, believing K_new is safe to use, switches their
active signing KSK to K_new and publishes a new RRSIG, signed with active signing KSK to K_new and publishes a new RRSIG, signed with
K_new, covering the DNSKEY set. Non-attacked RFC5011 validators, (only) K_new, covering the DNSKEY set. Non-attacked RFC5011
with a hold-down timer of at least 30 days, would have accepted validators, with a hold-down timer of at least 30 days, would have
K_new into their set of trusted keys. But, because our attacked accepted K_new into their set of trusted keys. But, because our
RFC5011 Validator now has a hold-down timer for K_new of only 26 attacked RFC5011 Resolver now has a hold-down timer for K_new of
days, it failed to accept K_new as a trust anchor. Since K_old is only 26 days, it failed to ever accept K_new as a trust anchor.
no longer being used to sign the zone's DNSKEYs, all the DNSKEY Since K_old is no longer being used to sign the zone's DNSKEYs,
records from the zone will be treated as invalid. Subsequently, all the DNSKEY records from the zone will be treated as invalid.
all of the records in the DNS tree below the zone's apex will be Subsequently, all of the records in the DNS tree below the zone's
deemed invalid by DNSSEC. apex will be deemed invalid by DNSSEC.
6. Minimum RFC5011 Timing Requirements 6. Minimum RFC5011 Timing Requirements
6.1. Timing Requirements For Adding a New KSK This section defines the minimum timing requirements for making
exclusive use of newly added DNSKEYs and timing requirements for
Given the attack description in Section 5, the correct minimum length ceasing the publication of DNSKEYs to be revoked. First, we define
of time required for the Zone Signer to wait after publishing K_new the term components used in both equations in Section 6.1.
but before exclusively using it and newer keys is:
addWaitTime = addHoldDownTime 6.1. Equation Components
+ sigExpirationTime
+ activeRefresh
+ activeRefreshOffset
+ safetyMargin
6.1.1. addHoldDownTime 6.1.1. addHoldDownTime
The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as: The addHoldDownTime is defined in Section 2.4.1 of [RFC5011] as:
The add hold-down time is 30 days or the expiration time of the The add hold-down time is 30 days or the expiration time of the
original TTL of the first trust point DNSKEY RRSet that contained original TTL of the first trust point DNSKEY RRSet that contained
the new key, whichever is greater. This ensures that at least the new key, whichever is greater. This ensures that at least
two validated DNSKEY RRSets that contain the new key MUST be seen two validated DNSKEY RRSets that contain the new key MUST be seen
by the resolver prior to the key's acceptance. by the resolver prior to the key's acceptance.
6.1.2. sigExpirationTime 6.1.2. sigExpirationTimeRemaining
sigExpirationTime is defined in Section 3. sigExpirationTimeRemaining is defined in Section 3.
6.1.3. activeRefresh 6.1.3. activeRefresh
activeRefresh time is defined by RFC5011 by activeRefresh time is defined by RFC5011 by
A resolver that has been configured for an automatic update A resolver that has been configured for an automatic update
of keys from a particular trust point MUST query that trust of keys from a particular trust point MUST query that trust
point (e.g., do a lookup for the DNSKEY RRSet and related point (e.g., do a lookup for the DNSKEY RRSet and related
RRSIG records) no less often than the lesser of 15 days, half RRSIG records) no less often than the lesser of 15 days, half
the original TTL for the DNSKEY RRSet, or half the RRSIG the original TTL for the DNSKEY RRSet, or half the RRSIG
skipping to change at page 9, line 48 skipping to change at page 10, line 13
Specifically, activeRefreshOffset will be "addHoldDownTime % Specifically, activeRefreshOffset will be "addHoldDownTime %
activeRefresh", where % is the mathematical mod operator (calculating activeRefresh", where % is the mathematical mod operator (calculating
the remainder in a division problem). This will frequently be zero, the remainder in a division problem). This will frequently be zero,
but could be nearly as large as activeRefresh itself. For but could be nearly as large as activeRefresh itself. For
simplicity, setting the activeRefreshOffset to the activeRefresh simplicity, setting the activeRefreshOffset to the activeRefresh
value itself is always safe. value itself is always safe.
6.1.5. safetyMargin 6.1.5. safetyMargin
The safetyMargin is an extra period of time to account for caching, The safetyMargin is an extra period of time to account for caching,
network delays, etc. A suggested operational value for this is 2 * network delays, dropped packets, and other operational concerns
MAX(TTL of all records) unless the TTLs are shorter than an hour, at otherwise beyond the scope of this document. The value operators
which point they start affecting the calculations in the MIN() clause should chose is highly dependent on the deployment siptuation
in the activeRefresh timer in Section 6.1.3. Thus, we suggest a associated with their zone. Note that no value of a safetyMargin can
safetyMargin of at least: protect against resolvers that are "down". None the less, we do
offer the following as one method considering reasonable values to
select from.
safetyMargin = MAX (1.5 hours, 2 * MAX(TTL of all records)) The following list of variables need to be considered when selecting
an appropriate safetyMargin value:
RFC5011 also discusses a retryTime value for failed queries. Our successRate: A likely success rate for client queries and retries
equation cannot take into account undeterministic failure situations,
so it might be wise to extend the safetyMargin by some factor of
retryTime, which is defined in RFC5011 as:
retryTime = MAX (1 hour, numResolvers: The number of client RFC5011 Resolvers
MIN (1 day,
.1 * TTL of K_old DNSKEY RRset,
.1 * sigExpirationTime))
6.1.6. Fully expanded equation Note that RFC5011 defines retryTime as:
The full expanded equation, with activeRefreshOffset set to If the query fails, the resolver MUST repeat the query until
activeRefresh for simplicity, is: satisfied no more often than once an hour and no less often
than the lesser of 1 day, 10% of the original TTL, or 10% of
the original expiration interval. That is,
retryTime = MAX (1 hour, MIN (1 day, .1 * origTTL,
.1 * expireInterval)).
With these values selected and the definition of retryTime from
RFC5011, one method for determining how many retryTime intervals to
wait in order to reduce the set of uncompleted servers to 0 assuming
normal probability is thus:
x = (1/(1 - successRate))
retryCountWait = Log_base_x(numResolvers)
To reduce the need for readers to pull out a scientific calculator,
we offer the following lookup table based on successRate and
numResolvers:
retryCountWait lookup table
---------------------------
Number of client RFC5011 Resolvers (numResolvers)
10,000 100,000 1,000,000 10,000,000 100,000,000
0.01 917 1146 1375 1604 1833
Probability 0.05 180 225 270 315 360
of Success 0.10 88 110 132 153 175
Per Retry 0.15 57 71 86 100 114
Interval 0.25 33 41 49 57 65
(successRate) 0.50 14 17 20 24 27
0.90 4 5 6 7 8
0.95 4 4 5 6 7
0.99 2 3 3 4 4
0.999 2 2 2 3 3
Finally, a suggested value of safetyMargin can then be this
retryCountWait number multiplied by the retryTime from RFC5011:
safetyMargin = retryCountWait * retryTime
6.2. Timing Requirements For Adding a New KSK
This section defines a method for calculating the amount of time to
wait until it is safe to start signing exclusively with a new key
Section 6.2.1 (especially useful for writing code involving sleep
based timers), and an a method for calculating a wall-clock value
after which it is safe to start signing exclusively with a new key
Section 6.2.2 (especially useful for writing code based on clock-
based event triggers).
6.2.1. Wait Timer Based Calculation
Given the attack description in Section 5, the correct minimum length
of time required for the Zone Signer to wait after publishing K_new
but before exclusively using it and newer keys is:
addWaitTime = addHoldDownTime addWaitTime = addHoldDownTime
+ sigExpirationTime + sigExpirationTimeRemaining
+ activeRefresh
+ activeRefreshOffset
+ safetyMargin
6.2.1.1. Fully expanded equation
The full expanded equation is:
addWaitTime = addHoldDownTime
+ sigExpirationTimeRemaining
+ 2 * MAX(1 hour, + 2 * MAX(1 hour,
MIN(sigExpirationTime / 2, MIN(sigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2, MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days) 15 days)
) )
+ (addHoldDownTime % activeRefresh) + (addHoldDownTime % activeRefresh)
+ MAX(1.5 hours, 2 * MAX(TTL of all records)) + MAX(1.5 hours, 2 * MAX(TTL of all records))
+ safetyMargin
6.1.7. Timing Constraint Summary 6.2.2. Wall-Clock Based Calculation
The above equations are defined based upon how long to wait from a
particular moment in time. An alternative, but equivalent, method is
to calculate the date and time before which it is unsafe to use a key
for signing. This calculation thus becomes:
addWallClockTime = lastSigExpirationTime
+ addHoldDownTime
+ activeRefresh
+ activeRefreshOffset
+ safetyMargin
where lastSigExpirationTime is the latest value of any
sigExpirationTime for which RRSIGs were created that could
potentially be replayed. Fully expanded, this becomes:
addWallClockTime = lastSigExpirationTime
+ addHoldDownTime
+ 2 * MAX(1 hour,
MIN(sigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days)
)
+ (addHoldDownTime % activeRefresh)
+ MAX(1.5 hours, 2 * MAX(TTL of all records))
+ safetyMargin
6.2.3. Timing Constraint Summary
The important timing constraint introduced by this memo relates to The important timing constraint introduced by this memo relates to
the last point at which a validating resolver may have received a the last point at which a RFC5011 Resolver may have received a
replayed original DNSKEY set, containing K_old and not K_new. The replayed original DNSKEY set, containing K_old and not K_new. The
next query of the RFC5011 validator at which K_new will be seen next query of the RFC5011 validator at which K_new will be seen
without the potential for a replay attack will occur after the without the potential for a replay attack will occur after the
publication time plus sigExpirationTime. Thus, the latest time that publication time plus sigExpirationTime. Thus, the latest time that
a RFC5011 Validator may begin their hold down timer is an "Active a RFC5011 Validator may begin their hold down timer is an "Active
Refresh" period after the last point that an attacker can replay the Refresh" period after the last point that an attacker can replay the
K_old DNSKEY set. The worst case scenario of this attack is if the K_old DNSKEY set. The worst case scenario of this attack is if the
attacker can replay K_old seconds before the (DNSKEY RRSIG Signature attacker can replay K_old just seconds before the (DNSKEY RRSIG
Validity) field of the last K_old only RRSIG. Signature Validity) field of the last K_old only RRSIG.
6.1.8. Additional Considerations 6.2.4. Additional Considerations for RFC7583
Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1 Note: our notion of addWaitTime is called "Itrp" in Section 3.3.4.1
of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it of [RFC7583]. The equation for Itrp in RFC7583 is insecure as it
does not include the sigExpirationTime listed above. The Itrp does not include the sigExpirationTime listed above. The Itrp
equation in RFC7583 also does not include the 2*TTL safety margin, equation in RFC7583 also does not include the 2*TTL safety margin,
though that is an operational consideration and not necessarily as though that is an operational consideration and not necessarily as
critical. critical.
6.1.8.1. Example Results 6.2.5. Example Scenario Calculations
For the parameters listed in Section 5.1, the activeRefreshOffset is For the parameters listed in Section 5.1, the activeRefreshOffset is
0, since 30 days is evenly divisible by activeRefresh (1/2 day), and 0, since 30 days is evenly divisible by activeRefresh (1/2 day), and
our resulting addWaitTime is: our resulting addWaitTime is:
addWaitTime = 30 addWaitTime = 30
+ 10 + 10
+ 1 / 2 + 1 / 2
+ 2 * (1) (days) + 2 * (1) (days)
addWaitTime = 42.5 (days) addWaitTime = 42.5 (days)
This addWaitTime of 42.5 days is 12.5 days longer than just the hold This addWaitTime of 42.5 days is 12.5 days longer than just the hold
down timer. down timer.
6.2. Timing Requirements For Revoking an Old KSK 6.3. Timing Requirements For Revoking an Old KSK
It is important to note that this issue affects not just the This issue affects not just the publication of new DNSKEYs intended
publication of new DNSKEYs intended to be used as trust anchors, but to be used as trust anchors, but also the length of time required to
also the length of time required to continuously publish a DNSKEY continuously publish a DNSKEY with the revoke bit set.
with the revoke bit set. Both of these publication timing
requirements are affected by the attacks described in this document,
but with revocation the key is revoked immediately and the
addHoldDown timer does not apply. Thus the minimum amount of time
that a Trust Anchor Publisher must wait before removing a revoked key
from publication is:
remWaitTime = sigExpirationTime This section defines a method for calculating the amount of time
operators need to wait until it is safe to cease publishing a DNSKEY
Section 6.2.1 (especially useful for writing code involving sleep
based timers), and an a method for calculating a minimal wall-clock
value after which it is safe to cease publishing a DNSKEY
Section 6.2.2 (especially useful for writing code based on clock-
based event triggers).
6.3.1. Wait Timer Based Calculation
Both of these publication timing requirements are affected by the
attacks described in this document, but with revocation the key is
revoked immediately and the addHoldDown timer does not apply. Thus
the minimum amount of time that a SEP Publisher must wait before
removing a revoked key from publication is:
remWaitTime = sigExpirationTimeRemaining
+ MAX(1 hour, + MAX(1 hour,
MIN((sigExpirationTime) / 2, MIN((sigExpirationTime) / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2, MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days), 15 days),
1 hour) 1 hour)
+ 2 * MAX(TTL of all records) + 2 * MAX(TTL of all records)
Note that the activeRefreshOffset time does not apply to this Note that the activeRefreshOffset time does not apply to this
equation. equation.
Note also that adding retryTime intervals to the remWaitTime may be
wise, just as it was for addWaitTime in Section 6.
6.3.2. Wall-Clock Based Calculation
Like before, the above equations are defined based upon how long to
wait from a particular moment in time. An alternative, but
equivalent, method is to calculate the date and time before which it
is unsafe to cease publishing a revoked key. This calculation thus
becomes:
remWallClockTime = lastSigExpirationTime
+ activeRefresh
+ activeRefreshOffset
+ safetyMargin
where lastSigExpirationTime is the latest value of any
sigExpirationTime for which RRSIGs were created that could
potentially be replayed. Fully expanded, this becomes:
remWallClockTime = lastSigExpirationTime
+ 2 * MAX(1 hour,
MIN(sigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days)
)
+ (addHoldDownTime % activeRefresh)
+ MAX(1.5 hours, 2 * MAX(TTL of all records))
6.3.3. Additional Considerations for RFC7583
Note that our notion of remWaitTime is called "Irev" in Note that our notion of remWaitTime is called "Irev" in
Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is
insecure as it does not include the sigExpirationTime listed above. insecure as it does not include the sigExpirationTime listed above.
The Irev equation in RFC7583 also does not include the 2*TTL safety The Irev equation in RFC7583 also does not include the 2*TTL safety
margin, though that is an operational consideration and not margin, though that is an operational consideration and not
necessarily as critical. necessarily as critical.
Note also that adding retryTime intervals to the remWaitTime may be 6.3.4. Example Scenario Calculations
wise, just as it was for addWaitTime in Section 6.
6.2.1. Example Results
For the parameters listed in Section 5.1, our example: For the parameters listed in Section 5.1, our example:
remwaitTime = 10 remwaitTime = 10
+ 1 / 2 + 1 / 2
+ 2 * (1) (days) + 2 * (1) (days)
remwaitTime = 12.5 (days) remwaitTime = 12.5 (days)
Note that for the values in this example produce a length shorter Note that for the values in this example produce a length shorter
than the recommended 30 days in RFC5011's section 6.6, step 3. Other than the recommended 30 days in RFC5011's section 6.6, step 3. Other
values of sigExpirationTime and the original TTL of the K_old DNSKEY values of sigExpirationTime and the original TTL of the K_old DNSKEY
RRSet, however, can produce values longer than 30 days. RRSet, however, can produce values longer than 30 days.
Note that because revocation happens immediately, an attacker has a Note that because revocation happens immediately, an attacker has a
much harder job tricking a RFC5011 Validator into leaving a trust much harder job tricking a RFC5011 Resolver into leaving a trust
anchor in place, as the attacker must successfully replay the old anchor in place, as the attacker must successfully replay the old
data for every query a RFC5011 Validator sends, not just one. data for every query a RFC5011 Resolver sends, not just one.
7. IANA Considerations 7. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
8. Operational Considerations 8. Operational Considerations
A companion document to RFC5011 was expected to be published that A companion document to RFC5011 was expected to be published that
describes the best operational practice considerations from the describes the best operational practice considerations from the
perspective of a zone publisher and Trust Anchor Publisher. However, perspective of a zone publisher and PEP Publisher. However, this
this companion document has yet to be published. The authors of this companion document has yet to be published. The authors of this
document hope that it will at some point in the future, as RFC5011 document hope that it will at some point in the future, as RFC5011
timing can be tricky as we have shown, and a BCP is clearly timing can be tricky as we have shown, and a BCP is clearly
warranted. This document is intended only to fill a single warranted. This document is intended only to fill a single
operational void which, when left misunderstood, can result in operational void which, when left misunderstood, can result in
serious security ramifications. This document does not attempt to serious security ramifications. This document does not attempt to
document any other missing operational guidance for zone publishers. document any other missing operational guidance for zone publishers.
9. Security Considerations 9. Security Considerations
This document, is solely about the security considerations with This document, is solely about the security considerations with
respect to the Trust Anchor Publisher of RFC5011 trust anchors / respect to the SEP Publisher's ability to advertise new DNSKEYs via
DNSKEYs. Thus the entire document is a discussion of Security the RFC5011 automated trust anchor update process. Thus the entire
Considerations when adding or removing DNSKEYs from trust anchor document is a discussion of Security Considerations when adding or
storage using the RFC5011 process. removing DNSKEYs from trust anchor storage using the RFC5011 process.
For simplicity, this document assumes that the Trust Anchor Publisher For simplicity, this document assumes that the SEP Publisher will use
will use a consistent RRSIG validity period. Trust Anchor Publishers a consistent RRSIG validity period. SEP Publishers that vary the
that vary the length of RRSIG validity periods will need to adjust length of RRSIG validity periods will need to adjust the
the sigExpirationTime value accordingly so that the equations in sigExpirationTime value accordingly so that the equations in
Section 6 and Section 6.2 use a value that coincides with the last Section 6 and Section 6.3 use a value that coincides with the last
time a replay of older RRSIGs will no longer succeed. time a replay of older RRSIGs will no longer succeed.
10. Acknowledgements 10. Acknowledgements
The authors would like to especially thank to Michael StJohns for his The authors would like to especially thank to Michael StJohns for his
help and advice and the care and thought he put into RFC5011 itself. help and advice and the care and thought he put into RFC5011 itself.
We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking, We would also like to thank Bob Harold, Shane Kerr, Matthijs Mekking,
Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working Duane Wessels, Petr Petr Spacek, Ed Lewis, and the dnsop working
group who have assisted with this document. group who have assisted with this document.
 End of changes. 72 change blocks. 
206 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/