Security Considerations for RFC5011 Publishers
draft-hardaker-rfc5011-security-considerations-00
dnsop W. Hardaker
Internet-Draft Parsons, Inc.
Intended status: Standards Track W. Kumari
Expires: January 26, 2017 Google
July 25, 2016
Security Considerations for RFC5011 Publishers
draft-hardaker-rfc5011-security-considerations-00
Abstract
This document describes the minimum requirements which a publisher of
a zone must wait before using a new DNSKEY advertised using the
RFC5011 DNSKEY rollover process.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Hardaker & Kumari Expires January 26, 2017 [Page 1]
Internet-Draft RFC5011 Security Considerations July 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Timing associated with RFC5011 processing . . . . . . . . . . 3
5. Denial of Service Attack Considerations . . . . . . . . . . . 3
5.1. Numerical Concrete Attack Example . . . . . . . . . . . . 3
5.1.1. Attack Timing Breakdown . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Operational
Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
RFC5011 [RFC5011] defines a mechanism by which DNSSEC validators can
extend their list of trust anchors when they've seen a new key.
However, RFC5011 [intentionally] provides no guidance to publishers
of DNSKEYs about how long they must wait before such a new key is
actually usable. Because of this lack of guidance, DNSSEC publishers
may derive incorrect assumptions about safe usage of the RFC5011
process. This document describes the minimum security requirements
from a publishers point of view and is indented to compliment the
guidance offered in RFC5011 (which is designed to solely represent
the Validating Resolvers point of view).
The authors reached out to 5 DNSSEC experts and asked them how long
they must wait before using a new KSK that was being rolled according
to the 5011 process. All 5 experts answered with an insecure value,
and thus the authors have determined that this lack of operational
guidance is causing security concerns. This document will hopefully
help rectify this problem.
One important (temporary?) note about ICANN's upcoming KSK rolling
plan for the root zone: the timing values, at the time of this
writing, chosen for rolling the KSK in the root zone appear
completely safe, and are not in any way affected by the timing
concerns introduced by this draft
Hardaker & Kumari Expires January 26, 2017 [Page 2]
Internet-Draft RFC5011 Security Considerations July 2016
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Show full document text