< draft-ietf-dnsop-delegation-trust-maintainance-09.txt		draft-ietf-dnsop-delegation-trust-maintainance-10.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-09		draft-ietf-dnsop-delegation-trust-maintainance-10
	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. This document does not address the initial configuration of
	trust anchors for a domain. The technique described is aimed at		trust anchors for a domain. The technique described is aimed at
	delegations in which it is currently hard to move information from		delegations in which it is currently hard to move information from
	the child to parent.		the child to parent.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	child has told the parent it will use to sign its DNSKEY RRset. In		child has told the parent it will use to sign its DNSKEY RRset. In
	DNSSEC trust relationship between zones is provided by the following		DNSSEC trust relationship between zones is provided by the following
	chain:		chain:
	parent DNSKEY --> DS --> child DNSKEY.		parent DNSKEY --> DS --> child DNSKEY.
	A prior proposal [I-D.auto-cpsync] suggested that the child send an		A prior proposal [I-D.auto-cpsync] suggested that the child send an
	"update" to the parent via a mechanism similar to Dynamic Update.		"update" to the parent via a mechanism similar to Dynamic Update.
	The main issue became: How does the child find the actual parental		The main issue became: How does the child find the actual parental
	agent/server to send the update to? While that could have been		agent/server to send the update to? While that could have been
	solved via technical means, it failed to each consensus. There is		solved via technical means, it failed to reach consensus. There is
	also a similar proposal in [I-D.parent-zones].		also a similar proposal in [I-D.parent-zones].
	As the DS record can only be present at the parent ( [RFC4034]), some		As the DS record can only be present at the parent ( [RFC4034]), some
	other method is needed to automate which DNSKEYs are picked to be		other method is needed to automate which DNSKEYs are picked to be
	represented in the parent zone's DS records. One possibility is to		represented in the parent zone's DS records. One possibility is to
	use flags in the DNSKEY record. If the SEP bit is set, this		use flags in the DNSKEY record. If the SEP bit is set, this
	indicates that the DNSKEY is intended for use as a secure entry		indicates that the DNSKEY is intended for use as a secure entry
	point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent		point. This DNSKEY signs the DNSKEY RRset, and the Parental Agent
	can calculate DS records based on that. But this fails to meet some		can calculate DS records based on that. But this fails to meet some
	operating needs, including the child having no influence what DS		operating needs, including the child having no influence what DS
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	o Multi-step Combinations: The information flows through an		o Multi-step Combinations: The information flows through an
	intermediary. It is possible, but unlikely, that all the steps		intermediary. It is possible, but unlikely, that all the steps
	are automated via API's and there are no humans are involved.		are automated via API's and there are no humans are involved.
	A domain name holder (Child) may operate its own DNS servers or		A domain name holder (Child) may operate its own DNS servers or
	outsource the operation. While we use the word parent as a singular,		outsource the operation. While we use the word parent as a singular,
	parent can consist of single entity or a composite of many discrete		parent can consist of single entity or a composite of many discrete
	parts that have rules and roles. We refer to the entity that the		parts that have rules and roles. We refer to the entity that the
	child corresponds with as the Parent.		child corresponds with as the Parent.
	In some cases an organization may delegate parts of its name-space to		An organization (such as an enterprise) may delegate parts of its
	be operated by a group that is not the same as that which operates		name-space to be operated by a group that is not the same as that
	the organization's DNS servers. In this case the flow of information		which operates the organization's DNS servers. In some of these
	is frequently handled in either an ad hoc manner or via some		cases the flow of information is handled in either an ad hoc manner
	corporate mechanism; this can range from email to fully-automated		or via some corporate mechanism; this can range from email to fully-
	operation.		automated operation.
	2.2.1. Solution Space		2.2.1. Solution Space
	This document is aimed at the cases in which there is a separation		This document is aimed at the cases in which there is a separation
	between the child and parent.		between the child and parent.
	A further complication is when the Child DNS Operator is not the		A further complication is when the Child DNS Operator is not the
	Child. There are two common cases of this:		Child. There are two common cases of this:
	a) The Parental Agent (e.g. registrar) handles the DNS operation.		a) The Parental Agent (e.g. registrar) handles the DNS operation.
	skipping to change at page 9, line 9 ¶		skipping to change at page 9, line 9 ¶
	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.
	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."		current DNSKEY and DS RRset's" (unless the parent 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 a CDS and / or CDNSKEY resource records.		Child DNS Operator publishes CDS and / or CDNSKEY resource records.
	In order to be valid, the CDS / CDNSKEY RRset MUST be compliant with		In order to be valid, the CDS / CDNSKEY RRset MUST be compliant with
	the rules in Section 4.1. When the Parent DS is "in-sync" with the		the rules in Section 4.1. When the Parent DS is "in-sync" with the
	CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the		CDS / CDNSKEY resource records, the Child DNS Operator MAY delete the
	CDS / CDNSKEY record(s); the child can determine if this is the case		CDS / CDNSKEY record(s); the child can determine if this is the case
	by quering for DS records in the parent. Note that if the child has		by querying for DS records in the parent.
	published a CDNSKEY RR, the Parent will have to calculate the DS
	(using the requested digest algorithm) to do the comparison.
	6. Parent Side CDS / CDNSKEY Consumption		6. Parent Side CDS / CDNSKEY Consumption
	The CDS / CDNSKEY RRset SHOULD be used by the Parental Agent to		The CDS / CDNSKEY RRset SHOULD be used by the Parental Agent to
	update the DS RRset in the parent zone. The Parental Agent for this		update the DS RRset in the parent zone. The Parental Agent for this
	uses a tool that understands the CDS / CDNSKEY signing rules from		uses a tool that understands the CDS / CDNSKEY signing rules from
	Section 4.1 so it may not be able to use a standard validator.		Section 4.1 so it might not be able to use a standard validator.
	The parent MUST choose to use either CDNSKEY or CDS resource records		The parent MUST choose to use either CDNSKEY or CDS resource records
	as their default updating mechanism. The parent MAY only accept		as their default updating mechanism. The parent MAY only accept
	either CDNSKEY or CDS, but it MAY also accept both, so it can use the		either CDNSKEY or CDS, but it MAY also accept both, so it can use the
	other in the absence of the default updating mechanism, but it MUST		other in the absence of the default updating mechanism, but it MUST
	NOT expect there to be both.		NOT expect there to be both.
	6.1. Detecting a Changed CDS / CDNSKEY		6.1. Detecting a Changed CDS / CDNSKEY
	How the Parental Agent gets the CDS / CDNSKEY RRset may differ, below		How the Parental Agent gets the CDS / CDNSKEY RRset may differ, below
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 10 ¶
	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		Dickinson, Paul Ebersman, Tony Finch, Jim Galvin, Paul Hoffman, Samir
	Hussain, Tatuya Jinmei, Olaf Kolkman, Cricket Liu, Stephan Lagerholm,		Hussain, Tatuya Jinmei, Olaf Kolkman, Stephan Lagerholm, Cricket Liu,
	Matt Larson, Marco Sanz, Antoin Verschuren, Suzanne Woolf, Paul		Stephan Lagerholm, Matt Larson, Marco Sanz, Antoin Verschuren,
	Wouters, John Dickinson, Timothe Litt and Edward Lewis.		Suzanne Woolf, Paul Wouters, John Dickinson, Timothe Litt and Edward
			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 16, line 19 ¶		skipping to change at page 16, line 19 ¶
	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-09 to WG-10
			o Incorporated off list comments from Stephan Lagerholm. Largest
			change is fixing discrepancy between parent MAY perform OOB
			validation and the Signer rule in 4.1. Clarified by updating
			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.
	o ... with a modification from Jaap.		o ... with a modification from Jaap.
	WG-07 to WG-08		WG-07 to WG-08
	o Incorporated text from Antoin Verschuren at the end of Section 6.		o Incorporated text from Antoin Verschuren at the end of Section 6.
End of changes. 9 change blocks.
	17 lines changed or deleted		25 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/