< draft-ietf-dnsop-rfc5011-security-considerations-02.txt   draft-ietf-dnsop-rfc5011-security-considerations-03.txt >
dnsop W. Hardaker dnsop W. Hardaker
Internet-Draft USC/ISI Internet-Draft USC/ISI
Intended status: Standards Track W. Kumari Updates: 7583 (if approved) W. Kumari
Expires: December 29, 2017 Google Intended status: Standards Track Google
June 27, 2017 Expires: March 16, 2018 September 12, 2017
Security Considerations for RFC5011 Publishers Security Considerations for RFC5011 Publishers
draft-ietf-dnsop-rfc5011-security-considerations-02 draft-ietf-dnsop-rfc5011-security-considerations-03
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 with time-length that a DNS zone publisher must wait before signing
only recently added DNSKEYs. This document also describes the exclusively with recently added DNSKEYs. This document also
minimum time-length that a DNS zone publisher must wait after describes the minimum time-length that a DNS zone publisher must wait
publishing a revoked DNSKEY before assuming that all active RFC5011 after publishing a revoked DNSKEY before assuming that all active
resolvers should have seen the revocation-marked key and removed it RFC5011 resolvers should have seen the revocation-marked key and
from their list of trust anchors. 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.
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 December 29, 2017. This Internet-Draft will expire on March 16, 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 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4 4. Timing Associated with RFC5011 Processing . . . . . . . . . . 4
4.1. Timing Associated with Publication . . . . . . . . . . . 4 4.1. Timing Associated with Publication . . . . . . . . . . . 4
4.2. Timing Associated with Revocation . . . . . . . . . . . . 5 4.2. Timing Associated with Revocation . . . . . . . . . . . . 5
5. Denial of Service Attack Considerations . . . . . . . . . . . 5 5. Denial of Service Attack Considerations . . . . . . . . . . . 5
5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 5 5.1. Enumerated Attack Example . . . . . . . . . . . . . . . . 5
5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6 5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 6
6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 7 6. Minimum RFC5011 Timing Requirements . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Timing Requirements For Adding a New KSK . . . . . . . . 8
8. Operational Considerations . . . . . . . . . . . . . . . . . 9 6.1.1. Example Results . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6.2. Timing Requirements For Revoking an Old KSK . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. Example Results . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 10 8. Operational Considerations . . . . . . . . . . . . . . . . . 11
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. Normative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Real World Example: The 2017 Root KSK Key Roll . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
[RFC5011] defines a mechanism by which DNSSEC validators can extend [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. 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 using only recently published keys for signing records, or how to exclusively using recently published keys for signing records, or
long they must wait before removing a revoked key from a zone. 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 compliment 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 using a new KSK [RFC4033] that they must wait before signing a zone exclusively with a new KSK
was being rolled according to the 5011 process. All 5 experts [RFC4033] that was being introduced according to the 5011 process.
answered with an insecure value, and we determined that this lack of All 5 experts answered with an insecure value, and we determined that
operational guidance is causing security concerns today and wrote this lack of operational guidance is causing security concerns today
this companion document to RFC5011. We hope that this document will and wrote this companion document to RFC5011. We hope that this
rectify this understanding and provide better guidance to zone document will rectify this understanding and provide better guidance
publishers that wish to make use of the RFC5011 rollover process. to zone publishers that wish to make use of the RFC5011 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 upcoming] 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 Validating
Resolver may accept a newly published KSK as a trust anchor for Resolver may accept a newly published KSK as a trust anchor for
validating future DNSSEC signed records. It also describes the validating future DNSSEC signed records. It also describes the
process for publicly revoking a published KSK. This document process for publicly revoking a published KSK. This document
augments that information with additional constraints, as required augments that information with additional constraints, from the
from the DNSKEY publication and revocation's points of view. Note DNSKEY publication and revocation's points of view. Note that this
that it does not define any other operational guidance or document does not define any other operational guidance or
recommendations about the RFC5011 process and restricts itself to recommendations about the RFC5011 process and restricts itself to
solely the security and operational ramifications of switching to solely the security and operational ramifications of switching to
using only recently added keys or removing a revoked keys too soon. exclusively using recently added keys or removing a revoked keys too
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 will 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 a key in time may result in RFC5011 Validating Resolvers leaving that key in
their trust anchor storage beyond their expected lifetime. their trust anchor storage beyond the key's expected lifetime.
3. Terminology 3. Terminology
Trust Anchor Publisher The entity responsible for publishing a Trust Anchor Publisher The entity responsible for publishing a
DNSKEY that can be used as a trust anchor. DNSKEY 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 will become a trust anchor by validators
following the RFC5011 process. following the RFC5011 process.
RFC5011 Validating Resolver A DNSSEC Validating Resolver that is RFC5011 Validating Resolver A DNSSEC Validating Resolver that is
using the RFC5011 processes to track and update trust anchors. using the RFC5011 processes to track and update trust anchors.
Sometimes referred to as a "RFC5011 Resolver" Sometimes referred to as a "RFC5011 Resolver"
Attacker An attacker intent on foiling the RFC5011 Validator's Attacker An entity intent on foiling the RFC5011 Validator's ability
ability to successfully adopt the Zone Signer's new DNSKEY as a to successfully adopt the Zone Signer's new DNSKEY as a new trust
new trust anchor or to prevent the RFC5011 Validator from removing anchor or to prevent the RFC5011 Validator from removing an old
an old DNSKEY from its list of trust anchors. DNSKEY from its list of trust anchors.
SigExpirationTime The amount of time remaining before a RRSIG's
Signature Expiration time is reached. This will fundamentally be
the RRSIG's Signature Expiration time minus the RRSIG's Signature
Inception time when the signature is created.
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 steps are not sufficient for proper RFC5011 implementation, but
provide enough background for the reader to follow the discussion in
this document. Readers need to fully understand [RFC5011] as well to
fully comprehend the 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 key and then making use
of that key falls into a number of high-level steps to be performed of that key falls into a number of high-level steps to be performed
by the Trust Anchor Publisher: by the Trust Anchor Publisher. This document discusses the following
scenario, which is one of many possible combinations of operations
defined in Section 6 of RFC5011:
1. Publish a new DNSKEY in the zone, but continue to sign the zone 1. Publish a new DNSKEY in the 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 using only 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 step 2 of the above process. Some
interpretations of RFC5011 have erroneously determined that the wait interpretations of RFC5011 have erroneously determined that the wait
time is equal to RFC5011's "hold down time". time is equal to RFC5011's "hold down time". Section 5 describes an
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 results in a denial of service attack against the zone
if that value is used.
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 validating 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 step 3 of the above process. Some
interpretations of RFC5011 have erroneously determined that the wait interpretations of RFC5011 have erroneously determined that the wait
time is equal to RFC5011's "hold down time". time is equal to RFC5011's "hold down time". This document describes
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 staying in a validating resolver long past its expected usage.
RFC5011 validating resolver long past its expected usage.
5. Denial of Service Attack Considerations 5. Denial of Service Attack Considerations
If an attacker is able to provide a RFC5011 Validating Resolver with If an attacker is able to provide a RFC5011 Validating Resolver with
past responses, such as when it is in-path or able to otherwise past responses, such as when it is in-path or able to perform any
perform any number of cache poisoning attacks, the attacker may be number of cache poisoning attacks, the attacker may be able to leave
able to leave compliant RFC5011-Validating Resolvers without an compliant RFC5011-Validating Resolvers without an appropriate DNSKEY
appropriate DNSKEY trust anchor. This scenario will remain until an trust anchor. This scenario will remain until an administrator
administrator manually fixes the situation. manually fixes the situation.
The following timeline 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
DNSKEY RRSIG Signature Validity 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 Trust Anchor Publisher that waits for only the RFC5011 hold
time timer length of 30 days subjects its users to a potential Denial time timer length of 30 days subjects its users to a potential Denial
of Service attack. The timing schedule listed below is based on a of Service attack. The timing schedule listed below is based on a
Trust Anchor Publisher publishing a new Key Signing Key (KSK), with Trust Anchor Publisher publishing a new Key Signing Key (KSK), with
the intent that it will later become a trust anchor. We label this the intent that it will later become a trust anchor. We label this
publication time as "T+0". All numbers in this sequence refer to publication time as "T+0". All numbers in this sequence refer to
days before and after this initial publication event. Thus, T-1 is days before and after this initial publication event. Thus, T-1 is
the day before the introduction of the new key, and T+15 is the 15th the day before the introduction of the new key, and T+15 is the 15th
day after the key was introduced into the fictitious zone being day after the key was introduced into the fictitious zone being
discussed. discussed.
In this dialog, we consider two keys being published: 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 becoming a K_new A new KSK being transitioned into active use and expected to
Trust Anchor via the RFC5011 process. become a Trust Anchor via the RFC5011 process.
5.1.1. Attack Timing Breakdown 5.1.1. Attack Timing Breakdown
The following series of steps depicts the timeline in which an attack The steps shows an attack that foils the adoption of a new DNSKEY by
occurs that foils the adoption of a new DNSKEY by a Trust Anchor a 5011 Validating Resolver when the Trust Anchor Publisher that
Publisher that starts signing with the new DNSKEY too quickly. starts signing and publishing with the new DNSKEY too quickly.
T-1 The last RRSIGs are published by the Zone Signer that signs only T-1 The K_old based RRSIGs are being published by the Zone Signer.
K_old key using the K_old key itself. [It may also be signing [It may also be signing ZSKs as well, but they are not relevant to
ZSKs as well, but they are not relevant to this event so we will this event so we will not talk further about them; we are only
not talk further about them; we are only talking about RRSIGs that considering the RRSIGs that cover the DNSKEYs in this document.]
cover the DNSKEYs.] The Attacker queries for, retrieves and The Attacker queries for, retrieves and caches this DNSKEY set and
caches this DNSKEY set and corresponding RRSIG signatures. corresponding RRSIG signatures.
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 Validator (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 Validator starts
the (30-day) hold-down timer for K_new. the (30-day) hold-down timer for K_new. [Note that in a more
real-world scenario there will likely be a further delay between
the point where the Zone Signer publishes a new RRSIG and the
RFC5011 Validator notices its publication; though not shown in
this example, this delay is accounted for in the final solution
below]
T+5 The RFC5011 Validator queries for the zone's keyset per the T+5 The RFC5011 Validator 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
that they recorded at T-1. Because the signature lifetime is 10 recorded at T-1. Because the signature lifetime is 10 days (in
days (in this example), the replayed signature and keyset is this example), the replayed signature and keyset is accepted as
accepted as valid (being only 6 days old) and the RFC5011 valid (being only 6 days old, which is less than
Validator cancels the hold-down timer for K_new, per the RFC5011 SigExpirationTime) and the RFC5011 Validator cancels the hold-down
algorithm. timer for K_new, per the RFC5011 algorithm.
T+10 The RFC5011 Validator queries for the zone's keyset and T+10 The RFC5011 Validator queries for the zone's keyset and
discovers the new kset which includes K_new (again), signed by discovers a signed keyset that includes K_new (again), and is
K_old. Note: the attacker is unable to replay the records cached signed by K_old. Note: the attacker is unable to replay the
at T-1, because they have now expired. The RFC5011 Validator records cached at T-1, because they have now expired. Thus at
starts (anew) the hold-timer for K_new. T+10, the RFC5011 Validator starts (anew) the hold-timer for
K_new.
T+15,T+20, and T+25 The RFC5011 Validator continues checking the T+11 through T-29 The RFC5011 Validator continues checking the
zone's key set at the prescribed regular intervals. The RFC5011 zone's key set at the prescribed regular intervals. During this
Validator's hold-down timer keep running without being reset period, the attacker can no longer replay traffic to their
assuming all of the validations succeed (again: the attacker can benefit.
no longer replay traffic to their 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 Validator 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 Validator 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 of 30 days + 1/2 the signature validity period hold down time (30 days) + the query interval [which is just 1/2
would have passed). However, the hold-down timer of our attacked the signature validity period in this example] would have passed).
RFC5011 Validator is only at 25 days; The replay attack at T+5 However, the hold-down timer of our attacked RFC5011 Validator is
means its new hold-time timer actually started at T+10, and thus only at 25 days (T+35 minus T+10); thus the RFC5011 won't consider
at this time it's real hold-down timer is at T+35 - T+10 = 25 it a valid trust anchor addition yet, as the required 30 days have
days, which is less than the RFC5011 required 30 days and the not yet elapsed.
RFC5011 won't consider it a valid trust anchor addition yet.
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, and covering the DNSKEY set. Non-attacked RFC5011 K_new, covering the DNSKEY set. Non-attacked RFC5011 validators,
validators, with a hold-down timer of at least 30 days, would have with a hold-down timer of at least 30 days, would have accepted
accepted K_new into their set of trusted keys. But, because our K_new into their set of trusted keys. But, because our attacked
attacked RFC5011 Validator has a hold-down timer for K_new at only RFC5011 Validator now has a hold-down timer for K_new of only 26
26 days, it will fail to accept K_new as a trust anchor. Since days, it failed to accept K_new as a trust anchor. Since K_old is
K_old is no longer being used, all the DNSKEY records from the no longer being used to sign the zone's DNSKEYs, all the DNSKEY
zone signed by K_new will be treated as invalid. Subsequently, records from the zone will be treated as invalid. Subsequently,
all keys in the key set are now unusable, invalidating all of the all of the records in the DNS tree below the zone's apex will be
records in the zone of any type and name. deemed invalid by DNSSEC.
6. Minimum RFC5011 Timing Requirements 6. Minimum RFC5011 Timing Requirements
6.1. Timing Requirements For Adding a New KSK
Given the attack description in Section 5, the correct minimum length Given the attack description in Section 5, the correct minimum length
of time required for the Zone Signer to wait before using K_new is: of time required for the Zone Signer to wait after publishing K_new
but before exclusively using it and newer keys is:
waitTime = addHoldDownTime addWaitTime = addHoldDownTime
+ (DNSKEY RRSIG Signature Validity) + SigExpirationTime
+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, + activeRefresh
MAX(original TTL of K_old DNSKEY RRSet) / 2, + activeRefreshOffset
15 days), + 2 * MAX(TTL of all records)
1 hour)
+ 2 * MAX(TTL of all records)
The RFC5011 "Active Refresh" requirements state that: Where 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
expiration interval and no more often than once per hour. expiration interval and no more often than once per hour.
This translates to the following equation:
activeRefresh = MAX(1 hour,
MIN(SigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days)
)
The activeRefreshOffset term must be added for situations where the
activeRefresh value is not a factor of "30 days". Specifically,
activeRefreshOffset will be "(30 days) % activeRefresh", where % is
the mathematical mod operator (which calculates the remainder in a
division problem). This will frequently be zero, but could be nearly
as large as activeRefresh itself. For simplicity, setting the
activeRefreshOffset to the activeRefresh value itself is safe.
The full expanded equation, with activeRefreshOffset set to
activeRefresh for simplicity, is:
addWaitTime = addHoldDownTime
+ SigExpirationTime
+ 2 * MAX(1 hour,
MIN(SigExpirationTime / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days)
)
+ 2 * MAX(TTL of all records)
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 validating resolver may have received a
replayed the original DNSKEY set (K_old) without the new key. It's replayed original DNSKEY set, containing K_old and not K_new. The
the next query of the RFC5011 validator that the assured K_new will next query of the RFC5011 validator at which K_new will be seen
be seen without a potential replay afterward. Thus, the latest time without the potential for a replay attack will occur after the
a RFC5011 validator may begin their hold down timer is an "Active publication time plus SigExpirationTime. Thus, the latest time that
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. 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
Validity) field of the last K_old only RRSIG.
The "Active Refresh" interval used by a RFC5011 validator is RFC5011 also discusses a retryTime value for failed queries. Our
determined by the larger of (DNSKEY RRSIG Signature Validity) and equation cannot take into account undeterministic failure situations,
(original TTL for the DNSKEY RRSet). The Following text assumes that so it might be wise to extend the addWaitTime by some factor of
(DNSKEY RRSIG Signature Validity) is larger of the two, which is retryTime, which is defined in RFC5011 as:
operationally more common today.
Thus, the worst case scenario of this attack is when the attacker can retryTime = MAX (1 hour,
replay K_old just before (DNSKEY RRSIG Signature Validity). If a MIN (1 day,
RFC5011 validator picks up K_old at this this point, it will not have .1 * TTL of K_old DNSKEY RRset,
a hold down timer started as it will have been reset by previous .1 * SigExpirationTime))
replays. It's not until the next "Active Refresh" time that they'll
pick up K_new with assurance, and thus start their (final) hold down
timer. Thus, this is not at (DNSKEY RRSIG Signature Validity) time
past publication but may be significantly longer based on the zone's
DNSSEC parameters.
The extra 2 * MAX(TTL of all records) is the standard added safety The extra 2 * MAX(TTL of all records) is the standard added safety
margin when dealing with DNSSEC due to caching that can take place. margin when dealing with DNSSEC due to caching that can take place.
Because the 5011 steps require direct validation using the signature Because the 5011 steps require direct validation using the signature
validity, the authors aren't yet convinced it is needed in this validity, the authors aren't yet convinced it is needed in this
particular case, but it is prudent to include it for added assurance. particular case, but it is prudent to include it for added assurance.
For the parameters listed in Section 5.1, our example: 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
does not include the SigExpirationTime listed above. The Itrp
equation in RFC7583 also does not include the 2*TTL safety margin,
though that is an operational consideration and not necessarily as
critical.
waitTime = 30 6.1.1. Example Results
+ 10
+ 10 / 2
+ 2 * (1) (days)
waitTime = 47 (days) For the parameters listed in Section 5.1, the activeRefreshOffset is
0, since 30 days is evenly divisible by activeRefresh (1/2 day), and
our resulting addWaitTime is:
This hold-down time of 47 days is 12 days longer than the (frequently addWaitTime = 30
perceived) 35 days in the example at T+35 above. + 10
+ 1 / 2
+ 2 * (1) (days)
It is important to note that this value affects not just the addWaitTime = 42.5 (days)
This addWaitTime of 42.5 days is 12.5 days longer than just the hold
down timer.
6.2. Timing Requirements For Revoking an Old KSK
It is important to note that this issue affects not just the
publication of new DNSKEYs intended to be used as trust anchors, but publication of new DNSKEYs intended to be used as trust anchors, but
also the length of time required to publish a DNSKEY with the revoke also the length of time required to continuously publish a DNSKEY
bit set. Both of these publication timing requirements are affected with the revoke bit set. Both of these publication timing
by the attacks described in this document. 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
+ MAX(1 hour,
MIN((SigExpirationTime) / 2,
MAX(TTL of K_old DNSKEY RRSet) / 2,
15 days),
1 hour)
+ 2 * MAX(TTL of all records)
Note that the activeRefreshOffset time does not apply to this
equation.
Note that our notion of remWaitTime is called "Irev" in
Section 3.3.4.2 of [RFC7583]. The equation for Irev in RFC7583 is
insecure as it does not include the SigExpirationTime listed above.
The Irev equation in RFC7583 also does not include the 2*TTL safety
margin, though that is an operational consideration and not
necessarily as critical.
Note also that adding retryTime intervals to the remWaitTime may be
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:
remwaitTime = 10
+ 1 / 2
+ 2 * (1) (days)
remwaitTime = 12.5 (days)
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
values of SigExpirationTime and the original TTL of the K_old DNSKEY
RRSet, however, can produce values longer than 30 days.
Note that because revocation happens immediately, an attacker has a
much harder job tricking a RFC5011 Validator into leaving a trust
anchor in place, as the attacker must successfully replay the old
data for every query a RFC5011 Validator 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 Trust Anchor Publisher. However,
this companion document has yet to be published. The authors of this 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 we do not suggest "good timing can be tricky as we have shown, and a BCP is clearly
operational practice" that might be associated with a BCP on the warranted. This document is intended only to fill a single
subject. This document is intended only to fill a single operational operational void which, when left misunderstood, can result in
void that results in security ramifications (specifically a denial of serious security ramifications. This document does not attempt to
service attack against an RFC5011 Validator). This document does not document any other missing operational guidance for zone publishers.
attempt to 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 Trust Anchor Publisher of RFC5011 trust anchors /
keys. Thus the entire document is a discussion of Security DNSKEYs. Thus the entire document is a discussion of Security
Considerations when rolling DNSKEYs using the RFC5011 process. Considerations when adding or removing DNSKEYs from trust anchor
storage using the RFC5011 process.
For simplicity, this document assumes that the Trust Anchor Publisher
will use a consistent RRSIG validity period. Trust Anchor Publishers
that vary the length of RRSIG validity periods will need to adjust
the SigExpirationTime value accordingly so that the equations in
Section 6 and Section 6.2 use a value that coincides with the last
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, and the dnsop working group who have Duane Wessels, Petr Petr Spacek, and the dnsop working group who have
assisted with this document. assisted with this document.
11. Normative References 11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <http://www.rfc-editor.org/info/rfc5011>. September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015, <https://www.rfc-
editor.org/info/rfc7583>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", RFC 7719, DOI 10.17487/RFC7719, December
2015, <http://www.rfc-editor.org/info/rfc7719>. 2015, <https://www.rfc-editor.org/info/rfc7719>.
Appendix A. Real World Example: The 2017 Root KSK Key Roll Appendix A. Real World Example: The 2017 Root KSK Key Roll
In 2017, ICANN expects to (or has, depending on when you're reading In 2017, ICANN expects to (or has, depending on when you're reading
this) roll the key signing key (KSK) for the root zone. The relevant this) roll the key signing key (KSK) for the root zone. The relevant
parameters associated with the root zone at the time of this writing parameters associated with the root zone at the time of this writing
is as follows: is as follows:
addHoldDownTime: 30 days addHoldDownTime: 30 days
Old DNSKEY RRSIG Signature Validity: 21 days Old DNSKEY SigExpirationTime: 21 days
Old DNSKEY TTL: 2 days Old DNSKEY TTL: 2 days
Thus, sticking this information into the equation in Thus, sticking this information into the equation in
Section Section 6 yields (in days): Section Section 6 yields (in days):
waitTime = addHoldDownTime addWaitTime = 30
+ (DNSKEY RRSIG Signature Validity) + (21)
+ MAX(MIN((DNSKEY RRSIG Signature Validity) / 2, + MAX(MIN((21) / 2,
MAX(original TTL of K_old DNSKEY RRSet) / 2, MAX(2 / 2,
15 days), 15 days)),
1 hour) 1 hour)
+ 2 * MAX(TTL of all records) + 2 * MAX(2)
waitTime = 30
+ (21)
+ MAX(MIN((21) / 2,
MAX(2 / 2,
15 days)),
1 hour)
+ 2 * MAX(2)
waitTime = 30 + 21 + MAX(MIN(11.5, MAX( 1, 15)), 1 hour) + 4
waitTime = 30 + 21 + 11.5 + 4
waitTime = 66.5 days
Thus, ICANN should wait 66.5 days before switching to the newly
published KSK and before removing the old revoked key once it is
published as revoked. ICANN's current plans are to wait 70 days
before using the new KEY and 69 days before removing the old, revoked
key. Thus, their current rollover plans are sufficiently secure from
the attack discussed in this memo.
Appendix B. Changes / Author Notes.
From Individual-00 to DNSOP-00:
o Filename change.
From -00 to -01:
o Added Revocation processing (including "Timing Associated with
Revocation")
o Added real world example.
o Fixed some typoes and missing references.
From Ind-00 to -02:
Additional background and clarifications in abstract.
Better separation in attack description between attacked and non-
attacked resolvers.
Some language cleanup.
Clarified that this is maths ( and math is hard, let's go
shopping!)
Changed to " <?rfc include='reference....'?> " style references.
From -02 to -03:
Minor changes from Bob Harold
Clarified why 3/2 signature validity is needed
Changed min wait time math to include TTL value as well
From -03 to -04:
Fixed the waitTime equation to handle the difference between the
usage of the expiration time and the Active Refresh time.
More clarification text and text changes proposed by Petr Spacek
From -04 to -05:
Clarifications about signing using only new keys, vs old ones too
Pre-DNSOP document: From hardaker-04 to ietf-00:
Just rebranding. addWaitTime = 30 + 21 + MAX(MIN(11.5, 1, 15)), 1 hour) + 4
From ietf-00 to ietf-01: addWaitTime = 30 + 21 + 1 + 4
Added discussion surrounding revocation everywhere addWaitTime = 56 days
Fixed the text about the formula Note that we use a activeRefreshOffset of 0, since 30 days is evenly
divisible by activeRefresh (1 day).
Another complete re-read for word-smithing Thus, ICANN should wait a minimum of 56 days before switching to the
newly published KSK (and 26 days before removing the old revoked key
once it is published as revoked). ICANN's current plans are to wait
70 days before using the new KEY and 69 days before removing the old,
revoked key. Thus, their current rollover plans are sufficiently
secure from the attack discussed in this memo.
Authors' Addresses Authors' Addresses
Wes Hardaker Wes Hardaker
USC/ISI USC/ISI
P.O. Box 382 P.O. Box 382
Davis, CA 95617 Davis, CA 95617
US US
Email: ietf@hardakers.net Email: ietf@hardakers.net
Warren Kumari Warren Kumari
Google Google
 End of changes. 61 change blocks. 
242 lines changed or deleted 294 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/