< draft-ietf-dnsop-delegation-trust-maintainance-10.txt		draft-ietf-dnsop-delegation-trust-maintainance-11.txt >
	dnsop W. Kumari		dnsop W. Kumari
	Internet-Draft Google		Internet-Draft Google
	Intended status: Informational O. Gudmundsson		Intended status: Informational O. Gudmundsson
	Expires: October 18, 2014 Shinkuro Inc.		Expires: October 18, 2014 Shinkuro Inc.
	G. Barwood		G. Barwood
	April 16, 2014		April 16, 2014
	Automating DNSSEC Delegation Trust Maintenance		Automating DNSSEC Delegation Trust Maintenance
	draft-ietf-dnsop-delegation-trust-maintainance-10		draft-ietf-dnsop-delegation-trust-maintainance-11
	Abstract		Abstract
	This document describes a method to allow DNS operators to more		This document describes a method to allow DNS operators to more
	easily update DNSSEC Key Signing Keys using the DNS as communication		easily update DNSSEC Key Signing Keys using the DNS as communication
	channel. This document does not address the initial configuration of		channel. The technique described is aimed at delegations in which it
	trust anchors for a domain. The technique described is aimed at		is currently hard to move information from the child to parent.
	delegations in which it is currently hard to move information from
	the child to parent.
	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/.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 27 ¶
	3. CDS / CDNSKEY (Child DS/ Child DNSKEY) Record Definitions . . 7		3. CDS / CDNSKEY (Child DS/ Child DNSKEY) Record Definitions . . 7
	3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8		3.1. CDS Resource Record Format . . . . . . . . . . . . . . . 8
	3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8		3.2. CDNSKEY Resource Record Format . . . . . . . . . . . . . 8
	4. Automating DS Maintainance With CDS/CDNSKEY records . . . . . 8		4. Automating DS Maintainance With CDS/CDNSKEY records . . . . . 8
	4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8		4.1. CDS / CDNSKEY Processing Rules . . . . . . . . . . . . . 8
	5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9		5. CDS / CDNSKEY Publication . . . . . . . . . . . . . . . . . . 9
	6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9		6. Parent Side CDS / CDNSKEY Consumption . . . . . . . . . . . . 9
	6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9		6.1. Detecting a Changed CDS / CDNSKEY . . . . . . . . . . . . 9
	6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10		6.1.1. CDS / CDNSKEY Polling . . . . . . . . . . . . . . . . 10
	6.1.2. Other Mechanisms . . . . . . . . . . . . . . . . . . 10		6.1.2. Other Mechanisms . . . . . . . . . . . . . . . . . . 10
	6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 10		6.2. Using the New CDS / CDNSKEY Records . . . . . . . . . . . 11
	6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11		6.2.1. Parent Calculates DS . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12		8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 15		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15		Appendix A. RRR background . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16		Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 16
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 42 ¶
	The solution described in this document only allows transferring		The solution described in this document only allows transferring
	information about DNSSEC keys (DS and DNSKEY) from the child to the		information about DNSSEC keys (DS and DNSKEY) from the child to the
	parental agent. It lists exactly what the parent should publish, and		parental agent. It lists exactly what the parent should publish, and
	allows for publication of stand-by keys. A different protocol,		allows for publication of stand-by keys. A different protocol,
	[I-D.csync], can be used to maintain other important delegation		[I-D.csync], can be used to maintain other important delegation
	information, such as NS and glue. These two protocols have been kept		information, such as NS and glue. These two protocols have been kept
	as separate solutions because the problems are fundamentally		as separate solutions because the problems are fundamentally
	different, and a combined solution is overly complex.		different, and a combined solution is overly complex.
	This document describes a method for automating maintanance of the		This document describes a method for automating maintenance of the
	delegation trust information, and proposes a polled / periodic		delegation trust information, and proposes a polled / periodic
	trigger for simplicity. Some users may prefer a different trigger,		trigger for simplicity. Some users may prefer a different trigger,
	for example a button on a webpage, a REST interface or a DNS NOTIFY.		for example a button on a webpage, a REST interface or a DNS NOTIFY.
	These alternate / additional triggers are not discussed in this		These alternate / additional triggers are not discussed in this
	document.		document.
	This proposal does not include all operations needed for the		This proposal does not include all operations needed for the
	maintenance of DNSSEC key material, specifically the initial		maintenance of DNSSEC key material, specifically the initial
	introduction or complete removal of all keys. Because of this,		introduction or complete removal of all keys. Because of this,
	alternate communications mechanisms must always exist, potentially		alternate communications mechanisms must always exist, potentially
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	publish that record type (for example, some children wish the parent		publish that record type (for example, some children wish the parent
	to publish a DS, but they wish to keep the DNSKEY "hidden" until		to publish a DS, but they wish to keep the DNSKEY "hidden" until
	needed). If the child publishes both, the two RRsets MUST match in		needed). If the child publishes both, the two RRsets MUST match in
	content.		content.
	4.1. CDS / CDNSKEY Processing Rules		4.1. CDS / CDNSKEY Processing Rules
	If there are no CDS / CDNSKEY RRset in the child, this signals that		If there are no CDS / CDNSKEY RRset in the child, this signals that
	no change should be made to the current DS set. This means that,		no change should be made to the current DS set. This means that,
	once the child and parent are in sync, the Child DNS Operator MAY		once the child and parent are in sync, the Child DNS Operator MAY
	remove all CDS and CDNSKEY resource records from the zone.		remove all CDS and CDNSKEY resource records from the zone The Child
			DNS Operator may choose to do this to decrease the size of the zone,
			or to decrease the workload for the parent (if the parent receives no
			CDS / CDNSKEY records it can go back to sleep. If it does receive a
			CDS or CDNSKEY RRset it needs to check them against what is currently
			published - see Section 5)
	Following acceptance rules are placed on the CDS / CDNSKEY resource		Following acceptance rules are placed on the CDS / CDNSKEY resource
	records as follows:		records as follows:
	o Location: "the CDS / CDNSKEY resource records MUST be at the child		o Location: "the CDS / CDNSKEY resource records MUST be at the child
	zone apex".		zone apex".
	o Signer: "MUST be signed with a key that is represented in both the		o Signer: "MUST be signed with a key that is represented in both the
	current DNSKEY and DS RRset's" (unless the parent validates the		current DNSKEY and DS RRset's" (unless the parent uses the CDS /
	CDS / CDNSKEY though some other means (see Section 6.1 and the		CDNSKEY RRset for initial enrollment, in that case the parent
	Security Considerations.))		validates the CDS / CDNSKEY though some other means (see
			Section 6.1 and the Security Considerations.))
	o Continuity: "MUST NOT break the current delegation if applied to		o Continuity: "MUST NOT break the current delegation if applied to
	DS RRset"		DS RRset"
	If any these conditions fail the CDS / CDNSKEY resource record MUST		If any these conditions fail the CDS / CDNSKEY resource record MUST
	be ignored.		be ignored.
	5. CDS / CDNSKEY Publication		5. CDS / CDNSKEY Publication
	Child DNS Operator publishes CDS and / or CDNSKEY resource records.		Child DNS Operator publishes CDS and / or CDNSKEY resource records.
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 16 ¶
	each of the children that has a DS record to see if there is a		each of the children that has a DS record to see if there is a
	CDS or CDNSKEY RRset.		CDS or CDNSKEY RRset.
	Pushing The delegation user interface has a button {Fetch DS} when		Pushing The delegation user interface has a button {Fetch DS} when
	pushed preforms the CDS / CDNSKEY processing. If the Parent		pushed preforms the CDS / CDNSKEY processing. If the Parent
	zone does not contain DS for this delegation then the "push"		zone does not contain DS for this delegation then the "push"
	SHOULD be ignored. If the Parental Agent displays the contents		SHOULD be ignored. If the Parental Agent displays the contents
	of the CDS / CDSNKEY to the user and gets confirmation that		of the CDS / CDSNKEY to the user and gets confirmation that
	this represents their key, the Parental Agent MAY use this for		this represents their key, the Parental Agent MAY use this for
	initial enrolment (when the Parent zone does not contain the DS		initial enrolment (when the Parent zone does not contain the DS
	for this delgation).		for this delegation).
	In either case the Parental Agent MAY apply additional rules that		In either case the Parental Agent MAY apply additional rules that
	defer the acceptance of a CDS / CDNSKEY change, these rules may		defer the acceptance of a CDS / CDNSKEY change, these rules may
	include a condition that the CDS / CDNSKEY remains in place and valid		include a condition that the CDS / CDNSKEY remains in place and valid
	for some time period before it is accepted. It may be appropriate in		for some time period before it is accepted. It may be appropriate in
	the "Pushing" case to assume that the Child is ready and thus accept		the "Pushing" case to assume that the Child is ready and thus accept
	changes without delay.		changes without delay.
	6.1.1. CDS / CDNSKEY Polling		6.1.1. CDS / CDNSKEY Polling
	This is the only defined use of CDS / CDNSKEY resource records in		This is the only defined use of CDS / CDNSKEY resource records in
	this document. There are limits to the scaleability of polling		this document. There are limits to the scaleability of polling
	techniques, thus some other mechanism is likely to be specified later		techniques, thus some other mechanism is likely to be specified later
	that addresses CDS / CDNSKEY resource recod usage in the situation		that addresses CDS / CDNSKEY resource record usage in the situation
	where polling does not scale to. Having said that Polling will work		where polling does not scale to. Having said that Polling will work
	in many important cases such as enterprises, universities and smaller		in many important cases such as enterprises, universities and smaller
	TLDs. In many regulatory environments the registry is prohibited		TLDs. In many regulatory environments the registry is prohibited
	from talking to the registrant. In most of these cases the		from talking to the registrant. In most of these cases the
	registrant has a business relationship with the registrar, and so the		registrant has a business relationship with the registrar, and so the
	registrar can offer this as a service.		registrar can offer this as a service.
	If the CDS / CDNSKEY RRset does not exist, the Parental Agent MUST		If the CDS / CDNSKEY RRset does not exist, the Parental Agent MUST
	take no action. Specifically it MUST NOT delete or alter the		take no action. Specifically it MUST NOT delete or alter the
	existing DS RRset.		existing DS RRset.
	skipping to change at page 10, line 51 ¶		skipping to change at page 11, line 10 ¶
	records or an unauthenticated POST could be made to a webserver (with		records or an unauthenticated POST could be made to a webserver (with
	rate-limiting).)		rate-limiting).)
	Other documents can specify the trigger conditions.		Other documents can specify the trigger conditions.
	6.2. Using the New CDS / CDNSKEY Records		6.2. Using the New CDS / CDNSKEY Records
	Regardless of how the Parental Agent detected changes to a CDS /		Regardless of how the Parental Agent detected changes to a CDS /
	CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to		CDNSKEY RRset, the Parental Agent SHOULD use a DNSSEC validator to
	obtain a validated CDS / CDNSKEY RRset from the Child zone. The only		obtain a validated CDS / CDNSKEY RRset from the Child zone. The only
	exception to this is if the parent perfoms some additional validation		exception to this is if the parent performs some additional
	on the data to confirm that it is the "correct" key. This behavior		validation on the data to confirm that it is the "correct" key. This
	is NOT RECOMMENDED.		behavior is NOT RECOMMENDED.
	The Parental Agent MUST ensure that previous versions of the CDS /		The Parental Agent MUST ensure that previous versions of the CDS /
	CDNSKEY RRset do not overwrite more recent versions. This MAY be		CDNSKEY RRset do not overwrite more recent versions. This MAY be
	accomplished by checking that the signature inception in the RRSIG		accomplished by checking that the signature inception in the RRSIG
	for CDS / CDNSKEY RRset is later and/or the serial number on the		for CDS / CDNSKEY RRset is later and/or the serial number on the
	child's SOA is greater. This may require the Parental Agent to		child's SOA is greater. This may require the Parental Agent to
	maintain some state information.		maintain some state information.
	The Parental Agent MAY take extra security measures. For example, to		The Parental Agent MAY take extra security measures. For example, to
	mitigate the possibility that a Child's key signing key has been		mitigate the possibility that a Child's key signing key has been
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 14 ¶
	not identical with the data in the CDS resource record made available		not identical with the data in the CDS resource record made available
	by the child.		by the child.
	7. IANA Considerations		7. IANA Considerations
	IANA has assigned RR Type code 59 for the CDS resource record. This		IANA has assigned RR Type code 59 for the CDS resource record. This
	was done for an earlier version of this document[I-D.ds-publish] This		was done for an earlier version of this document[I-D.ds-publish] This
	document is to become the reference for CDS RRtype.		document is to become the reference for CDS RRtype.
	IANA is requested to assign another RR Type for the CDNSKEY, and to		IANA is requested to assign another RR Type for the CDNSKEY, and to
	replace TBA1 with this value (currntly 60 is still free, it would be		replace TBA1 with this value (currently 60 is still free, it would be
	nice if that were assigned...)		nice if that were assigned...)
	8. Privacy Considerations		8. Privacy Considerations
	All of the information handled / transmitted by this protocol is		All of the information handled / transmitted by this protocol is
	public information published in the DNS.		public information published in the DNS.
	9. Security Considerations		9. Security Considerations
	This work is for the normal case; when things go wrong there is only		This work is for the normal case; when things go wrong there is only
	skipping to change at page 14, line 9 ¶		skipping to change at page 14, line 9 ¶
	security.		security.
	By automating the maintenance of the DNSSEC key information (and		By automating the maintenance of the DNSSEC key information (and
	removing humans from the process), we expect to decrease the number		removing humans from the process), we expect to decrease the number
	of DNSSEC related outages, which should increase DNSSEC deployment.		of DNSSEC related outages, which should increase DNSSEC deployment.
	10. Acknowledgements		10. Acknowledgements
	We would like to thank a large number of folk, including: Mark		We would like to thank a large number of folk, including: Mark
	Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian		Andrews, Joe Abley, Jaap Akkerhuis, Roy Arends, Doug Barton, Brian
	Dickinson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir		Dickson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
	Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,		Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
	Stephan Lagerholm, Matt Larson, Marco Sanz, Antoin Verschuren,		Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul
	Suzanne Woolf, Paul Wouters, John Dickinson, Timothe Litt and Edward		Wouters, John Dickinson, Timothe Litt and Edward Lewis.
	Lewis.
	Special thanks to Wes Hardaker for contributing significant text and		Special thanks to Wes Hardaker for contributing significant text and
	creating the complementary (CSYNC) solution, and to Patrik Faltstrom,		creating the complementary (CSYNC) solution, and to Patrik Faltstrom,
	Paul Hoffman, Matthijs Mekking and Mukund Sivaraman for text and in-		Paul Hoffman, Matthijs Mekking and Mukund Sivaraman for text and in-
	depth review.		depth review.
	There were a number of other folk with whom we discussed this,		There were a number of other folk with whom we discussed this,
	apologies for not remembering everyone.		apologies for not remembering everyone.
	11. References		11. References
	skipping to change at page 15, line 45 ¶		skipping to change at page 15, line 45 ¶
	Provisioning Protocol (EPP)", RFC 5910, May 2010.		Provisioning Protocol (EPP)", RFC 5910, May 2010.
	Appendix A. RRR background		Appendix A. RRR background
	In the RRR world, the different parties are frequently from different		In the RRR world, the different parties are frequently from different
	organizations. In the single enterprise world there are also		organizations. In the single enterprise world there are also
	organizational/geographical/cultural separations that affect how		organizational/geographical/cultural separations that affect how
	information flows from a Child to the parent.		information flows from a Child to the parent.
	Due to the complexity of the different roles and interconnections,		Due to the complexity of the different roles and interconnections,
	automation of delegation information has not yet occured. There have		automation of delegation information Expolhas not yet occurred.
	been proposals to automate this, in order to improve the reliability		There have been proposals to automate this, in order to improve the
	of the DNS. These proposals have not gained enough traction to		reliability of the DNS. These proposals have not gained enough
	become standards.		traction to become standards.
	For example in many of the TLD cases there is the RRR model		For example in many of the TLD cases there is the RRR model
	(Registry, Registrar and Registrant). The Registry operates DNS for		(Registry, Registrar and Registrant). The Registry operates DNS for
	the TLD, the Registrars accept registrations and place information		the TLD, the Registrars accept registrations and place information
	into the Registries database. The Registrant only communicates with		into the Registries database. The Registrant only communicates with
	the Registrar; frequently the Registry is not allowed to communicate		the Registrar; frequently the Registry is not allowed to communicate
	with the Registrant. In that case as far as the registrant is		with the Registrant. In that case as far as the registrant is
	concerned the Registrar == Parent.		concerned the Registrar == Parent.
	In many RRR cases the Registrar and Registry communicate via		In many RRR cases the Registrar and Registry communicate via
	EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number		EPP[RFC5730] and use the EPP DNSSEC extension [RFC5910]. In a number
	of ccTLDs there are other mechanisms in use as well as EPP, but in		of ccTLDs there are other mechanisms in use as well as EPP, but in
	general there seems to be a movement towards EPP usage when DNSSEC is		general there seems to be a movement towards EPP usage when DNSSEC is
	enabled in the TLD.		enabled in the TLD.
	Appendix B. Changes / Author Notes.		Appendix B. Changes / Author Notes.
	[RFC Editor: Please remove this section before publication ]		[RFC Editor: Please remove this section before publication ]
			WG-10 to WG-11
			o More useful text from Matthijs.
			o Explained why the child might want to remove the CDS / CDNSKEY
			Records.
	WG-09 to WG-10		WG-09 to WG-10
	o Incorporated off list comments from Stephan Lagerholm. Largest		o Incorporated off list comments from Stephan Lagerholm. Largest
	change is fixing discrepancy between parent MAY perform OOB		change is fixing discrepancy between parent MAY perform OOB
	validation and the Signer rule in 4.1. Clarified by updating		validation and the Signer rule in 4.1. Clarified by updating
	signer rule to allow		signer rule to allow
	WG-08 to WG-09		WG-08 to WG-09
	o New text from Paul Hoffman for the first paragraph of the intro.		o New text from Paul Hoffman for the first paragraph of the intro.
End of changes. 14 change blocks.
	25 lines changed or deleted		35 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/