< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/