draft-ietf-dnsop-maintain-ds-01.txt   draft-ietf-dnsop-maintain-ds-02.txt 
dnsop O. Gudmundsson dnsop O. Gudmundsson
Internet-Draft CloudFlare Internet-Draft CloudFlare
Intended status: Informational P. Wouters Intended status: Informational P. Wouters
Expires: September 21, 2016 Red Hat Expires: October 6, 2016 Red Hat
March 20, 2016 April 4, 2016
Managing DS records from parent via CDS/CDNSKEY Managing DS records from parent via CDS/CDNSKEY
draft-ietf-dnsop-maintain-ds-01 draft-ietf-dnsop-maintain-ds-02
Abstract Abstract
RFC7344 specifies how DNS trust can be partially maintained in-band RFC7344 specifies how DNS trust can be partially maintained in-band
between parent and child. There are two features missing in that between parent and child. There are two features missing in that
specification: initial trust setup and removal of trust anchor. This specification: initial trust setup and removal of trust anchor. This
document addresses both these omissions. document addresses both these omissions.
Changing a domain's DNSSEC status can be a complicated matter Changing a domain's DNSSEC status can be a complicated matter
involving multiple unrelated parties. Some of these parties, such as involving multiple unrelated parties. Some of these parties, such as
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 September 21, 2016. This Internet-Draft will expire on October 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 48 skipping to change at page 2, line 48
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
CDS/CDNSKEY [RFC7344] records are used to signal changes in trust CDS/CDNSKEY [RFC7344] records are used to signal changes in trust
anchors, this is one method to maintain delegations that can be used anchors, this is one method to maintain delegations that can be used
when the DNS operator has no other way to inform the parent that when the DNS operator has no other way to inform the parent that
changes are needed. RFC7344 contains no "delete" signal for the changes are needed. [RFC7344] contains no "delete" signal for the
child to tell the parent that it wants to remove the DNSSEC security child to tell the parent that it wants to remove the DNSSEC security
for its domain. for its domain.
[RFC7344] did not include a method for the Initial Trust [RFC7344] did not include a method for the Initial Trust
establishment and left it to each parent to come up with an establishment and left it to each parent to come up with an
acceptance policy. acceptance policy.
1.1. Removing a DS Record 1.1. Removing a DS Record
This document introduces the delete option for both CDS and CDNSKEY, This document introduces the delete option for both CDS and CDNSKEY,
skipping to change at page 5, line 16 skipping to change at page 5, line 16
The semantic meaning of publishing a CDS RRset is interpreted to The semantic meaning of publishing a CDS RRset is interpreted to
mean: mean:
"Publishing a CDS or CDNSKEY record signals to the parent that the "Publishing a CDS or CDNSKEY record signals to the parent that the
child desires that the corresponding DS records be synchronized. child desires that the corresponding DS records be synchronized.
Every parent or parental agent should have an acceptance policy of Every parent or parental agent should have an acceptance policy of
these records for the three different use cases involved: Initial DS these records for the three different use cases involved: Initial DS
publication, Key rollover, and Returning to Insecure." publication, Key rollover, and Returning to Insecure."
In short, the CDS RRset is an instruction to the parent to modify DS In short, the CDS RRset is an instruction to the parent to modify the
RRset if the CDS and DS RRsets differ. The acceptance policy for CDS DS RRset if the CDS and DS RRsets differ. The acceptance policy for
in the rollover case is "seeing" according to [RFC7344]. The CDS in the rollover case is "seeing" according to [RFC7344]. The
acceptance policy in the Delete case is seeing a (validly signed) CDS acceptance policy in the Delete case is seeing a (validly signed) CDS
RRset with the delete operation specified in this document. RRset with the delete operation specified in this document.
3. Enabling DNSSEC via CDS/CDNSKEY 3. Enabling DNSSEC via CDS/CDNSKEY
There are number of different models for managing initial trust, but There are number of different models for managing initial trust, but
in the general case, the child wants to enable global validation for in the general case, the child wants to enable global validation for
the future. Thus during the period from the time the child publishes the future. Thus during the period from the time the child publishes
the CDS until the corresponding DS is published at the parent is the the CDS until the corresponding DS is published at the parent is the
period that DNS answers for the child could be forged. The goal is period that DNS answers for the child could be forged. The goal is
skipping to change at page 7, line 16 skipping to change at page 7, line 16
signed. signed.
Strictly speaking the CDS record could be "CDS X 0 X" as only the Strictly speaking the CDS record could be "CDS X 0 X" as only the
DNSKEY algorithm is what signals the DELETE operation, but for DNSKEY algorithm is what signals the DELETE operation, but for
clarity the "0 0 0" notation is mandated - this is not a definition clarity the "0 0 0" notation is mandated - this is not a definition
of DS Digest algorithm 0. The same argument applies to "CDNSKEY 0 3 of DS Digest algorithm 0. The same argument applies to "CDNSKEY 0 3
0", the value 3 in second field is mandated by RFC4034 section 2.1.2. 0", the value 3 in second field is mandated by RFC4034 section 2.1.2.
Once the parent has verified the CDS/CDNSKEY RRset and it has passed Once the parent has verified the CDS/CDNSKEY RRset and it has passed
other acceptance tests, the parent MUST remove the DS RRset. After other acceptance tests, the parent MUST remove the DS RRset. After
waiting a sufficient amount of time - depending the the parental waiting a sufficient amount of time - depending on the parental TTLs
TTL's - the child can start the process of turning off DNSSEC. - the child can start the process of turning off DNSSEC.
5. Security considerations 5. Security considerations
This document's main goal is to avoid validation failures when a This document's main goal is to avoid validation failures when a
domain moves from one DNS operator to another. Turning off DNSSEC domain moves from one DNS operator to another. Turning off DNSSEC
reduces the security of the domain and thus should only be done as a reduces the security of the domain and thus should only be done as a
last resort. last resort.
In most cases it is preferable that operators collaborate on the In most cases it is preferable that operators collaborate on the
rollover by doing a KSK+ZSK rollover as part of the hand-off, but rollover by doing a KSK+ZSK rollover as part of the hand-off, but
that is not always possible. This document addresses the case where that is not always possible. This document addresses the case where
unsigned state is needed to complete a rollover. unsigned state is needed to complete a rollover.
Users SHOULD keep in mind that re-establishing trust in delegation Users SHOULD keep in mind that re-establishing trust in delegation
can be hard and takes a long time. Before deciding to complete the can be hard and takes a long time. Before deciding to complete the
rollover via an unsigned state, all options SHOULD be considered. rollover via an unsigned state, all options SHOULD be considered.
A parent SHOULD ensure that when it is allowing a child to become A parent SHOULD ensure that when it is allowing a child to become
securely delegated, that it has a reasonable assurance that the CDS/ securely delegated, that it has a reasonable assurance that the CDS/
CDNSKEY RRset that is used to bootstrap the security is visible from CDNSKEY RRset that is used to bootstrap the security is visible from
a geographically and network topology diverse view. It SHOULD also a geographically and topologically diverse view. It SHOULD also
ensure the the zone validates correctly if the parent publishes the ensure that the zone validates correctly if the parent publishes the
DS record. A parent zone might also consider sending an email to its DS record. A parent zone might also consider sending an email to its
contact addresses to give the child zone a warning that security will contact addresses to give the child zone a warning that security will
be enabled after a certain about of wait time - thus allowing a child be enabled after a certain about of wait time - thus allowing a child
administrator to cancel the request. administrator to cancel the request.
6. IANA considerations 6. IANA considerations
This document updates the following IANA registries: "DNS Security This document updates the following IANA registries: "DNS Security
Algorithm Numbers" Algorithm Numbers"
 End of changes. 7 change blocks. 
12 lines changed or deleted 12 lines changed or added

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