draft-ietf-dnsop-dnssec-trust-anchor-01.txt		draft-ietf-dnsop-dnssec-trust-anchor-02.txt
	DNS Operations M. Larson		DNS Operations M. Larson
	Internet-Draft VeriSign		Internet-Draft VeriSign
	Expires: August 14, 2008 O. Gudmundsson		Expires: January 15, 2009 O. Gudmundsson
	OGUD Consulting LLC		OGUD Consulting LLC
	February 11, 2008		July 14, 2008
	DNSSEC Trust Anchor Configuration and Maintenance		DNSSEC Trust Anchor Configuration and Maintenance
	draft-ietf-dnsop-dnssec-trust-anchor-01		draft-ietf-dnsop-dnssec-trust-anchor-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 14, 2008.		This Internet-Draft will expire on January 15, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document recommends a preferred format for specifying trust		This document recommends a preferred format for specifying trust
	anchors in DNSSEC validating security-aware resolvers and describes		anchors in DNSSEC validating security-aware resolvers and describes
	how such a resolver should initialize trust anchors for use. This		how such a resolver should initialize trust anchors for use. This
	document also describes different mechanisms for keeping trust		document also describes different mechanisms for keeping trust
	anchors up to date over time.		anchors up to date over time.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . . . 14		Intellectual Property and Copyright Statements . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The DNSSEC standards documents ([2], [3] and [4]) describe the need		The DNSSEC standards documents ([RFC4033], [RFC4034] and [RFC4035])
	for trust anchors and how they are used. A validating security-aware		describe the need for trust anchors and how they are used. A
	resolver (subsequently referred to as a "validating resolver") needs		validating security-aware resolver (subsequently referred to as a
	to be configured with one or more trust anchors, which specify the		"validating resolver") needs to be configured with one or more trust
	public keys of signed zones. To authenticate DNS data, a validating		anchors, which specify the public keys of signed zones. To
	resolver builds a chain of trust from a configured trust anchor to		authenticate DNS data, a validating resolver builds a chain of trust
	that data.		from a configured trust anchor to that data.
	In a widespread public DNSSEC deployment, the DNS root zone would be		In a widespread public DNSSEC deployment, the DNS root zone would be
	signed and a validating resolver would need to be configured with at		signed and a validating resolver would need to be configured with at
	least the root zone's trust anchor. A validating resolver might need		least the root zone's trust anchor. A validating resolver might need
	additional trust anchors configured to accommodate islands of		additional trust anchors configured to accommodate islands of
	security. (An island of security is a signed, delegated zone that		security. (An island of security is a signed, delegated zone that
	does not have an authentication chain from its delegating parent.)		does not have an authentication chain from its delegating parent.)
	For example, consider the situation where the root zone is signed but		For example, consider the situation where the root zone is signed but
	a given top-level domain (TLD) zone is not. Various second-level		a given top-level domain (TLD) zone is not. Various second-level
	zones under this unsigned TLD might be signed and resolver operators		zones under this unsigned TLD might be signed and resolver operators
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	To simplify this trust anchor configuration process that will occur		To simplify this trust anchor configuration process that will occur
	on a large number of resolvers, this document offers guidance to		on a large number of resolvers, this document offers guidance to
	validating resolver implementers by specifying a standardized format		validating resolver implementers by specifying a standardized format
	for describing trust anchors. The document also describes how a		for describing trust anchors. The document also describes how a
	validating resolver should initialize or "prime" trust anchors before		validating resolver should initialize or "prime" trust anchors before
	first use. Finally, the document lists options for keeping trust		first use. Finally, the document lists options for keeping trust
	anchor information current over time.		anchor information current over time.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Trust Anchor Format		2. Trust Anchor Format
	A trust anchor is a DNSSEC public key configured in a validating		A trust anchor is a DNSSEC public key configured in a validating
	resolver. A validating resolver's configuration MUST allow one or		resolver. A validating resolver's configuration MUST allow one or
	more trust anchors to be specified. According to the definition in		more trust anchors to be specified. According to the definition in
	Section 2 of RFC 4033 [2], a trust anchor can be specified as either		Section 2 of RFC 4033 [RFC4033], a trust anchor can be specified as
	a public key from a DNSKEY resource record (RR) or the hash of a		either a public key from a DNSKEY resource record (RR) or the hash of
	public key as found in a DS RR. (DS records are defined in Section 5		a public key as found in a DS RR. (DS records are defined in Section
	of RFC 4034 [3].)		5 of RFC 4034 [RFC4034].)
	This document RECOMMENDS that a trust anchor be specified using the		This document RECOMMENDS that a trust anchor be specified using the
	hash of a public key rather than the key itself, i.e., the fields		hash of a public key rather than the key itself, i.e., the fields
	from a DS record rather than from a DNSKEY record. A trust anchor		from a DS record rather than from a DNSKEY record. A trust anchor
	specified in this manner will use all the fields from the		specified in this manner will use all the fields from the
	corresponding key's DS record, including the owner name to indicate		corresponding key's DS record, including the owner name to indicate
	which zone the trust anchor corresponds to as well as the various		which zone the trust anchor corresponds to as well as the various
	fields from the DS RDATA. The digest algorithm SHOULD be SHA-256		fields from the DS RDATA. The digest algorithm SHOULD be SHA-256
	[5], which is DS digest type 2. DS records using SHA-1 (DS digest		[RFC4509], which is DS digest type 2. DS records using SHA-1 (DS
	type 1) to specify trust anchors are NOT RECOMMENDED: RFC 4509		digest type 1) to specify trust anchors are NOT RECOMMENDED: RFC 4509
	encourages the use of DS RRs using SHA-256 over those using SHA-1.		encourages the use of DS RRs using SHA-256 over those using SHA-1.
	Specifying a trust anchor using a DS format instead of a DNSKEY		Specifying a trust anchor using a DS format instead of a DNSKEY
	format offers a slight advantage because it forces the resolver to		format offers a slight advantage because it forces the resolver to
	make a DNS query to obtain the trust anchor's complete DNSKEY RRSet		make a DNS query to obtain the trust anchor's complete DNSKEY RRSet
	during a priming operation (described below). If only a DNSKEY		during a priming operation (described below). If only a DNSKEY
	record were specified, resolver implementers could conceivably avoid		record were specified, resolver implementers could conceivably avoid
	priming the trust anchor. But priming is desirable because it causes		priming the trust anchor. But priming is desirable because it causes
	the resolver to retrieve an up-to-date version of a zone's DNSKEY		the resolver to retrieve an up-to-date version of a zone's DNSKEY
	RRSet from one of the zone's authoritative servers. It should be		RRSet from one of the zone's authoritative servers. It should be
	skipping to change at page 4, line 50		skipping to change at page 4, line 50
	DNSKEY format and is easier to enter manually, either by typing or		DNSKEY format and is easier to enter manually, either by typing or
	cutting and pasting.		cutting and pasting.
	Another advantage of configuring a trust anchor using a DS record is		Another advantage of configuring a trust anchor using a DS record is
	that the entire hash of the public key in the DS RDATA need not		that the entire hash of the public key in the DS RDATA need not
	necessarily be specified. A validating resolver MAY support		necessarily be specified. A validating resolver MAY support
	configuration using a truncated DS hash value as a human-factors		configuration using a truncated DS hash value as a human-factors
	convenience: shorter strings are easier to type and less prone to		convenience: shorter strings are easier to type and less prone to
	error when entered manually. Even with a truncated hash configured,		error when entered manually. Even with a truncated hash configured,
	a validating resolver can still verify that the corresponding DNSKEY		a validating resolver can still verify that the corresponding DNSKEY
	is present in the trust anchor zone's apex DNSKEY RRSet.		is present in the trust anchor zone's apex DNSKEY RRSet. RFC 2104
			[RFC2104] offers guidance on acceptable truncation lengths.
	3. Trust Anchor Priming		3. Trust Anchor Priming
	A validating resolver needs to obtain and validate the DNSKEY RRSet		A validating resolver needs to obtain and validate the DNSKEY RRSet
	corresponding to a configured DS for that trust anchor to be usable		corresponding to a configured DS for that trust anchor to be usable
	in DNSSEC validation. This process is called "priming" the trust		in DNSSEC validation. This process is called "priming" the trust
	anchor. Priming can occur when the validating resolver starts, but a		anchor. Priming can occur when the validating resolver starts, but a
	validating resolver SHOULD defer priming of individual trust anchors		validating resolver SHOULD defer priming of individual trust anchors
	until each is first needed for verification. This priming on demand		until each is first needed for verification. This priming on demand
	is especially important when a validating resolver is configured with		is especially important when a validating resolver is configured with
	a large number of trust anchors to avoid sending a large number of		a large number of trust anchors to avoid sending a large number of
	DNS queries on start-up. This section adds additional details to the		DNS queries on start-up. This section adds additional details to the
	discussion of trust anchors in Section 5 of RFC 4035 [4].		discussion of trust anchors in Section 5 of RFC 4035 [RFC4035].
	Following are the steps a validating resolver SHOULD take to prime a		Following are the steps a validating resolver SHOULD take to prime a
	configured trust anchor:		configured trust anchor:
	1. Read the trust anchor's information (corresponding to the fields		1. Read the trust anchor's information (corresponding to the fields
	in a DS record) from the validating resolver's configuration		in a DS record) from the validating resolver's configuration
	(e.g., a text file).		(e.g., a text file).
	2. Look up the DNSKEY RRSet corresponding to the owner name of the		2. Look up the DNSKEY RRSet corresponding to the owner name of the
	trust anchor. (The validating resolver can either perform		trust anchor. (The validating resolver can either perform
	skipping to change at page 5, line 45		skipping to change at page 5, line 45
	zone signing key.)		zone signing key.)
	4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs		4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs
	found in the previous step, i.e., that there exists a valid RRSIG		found in the previous step, i.e., that there exists a valid RRSIG
	(cryptographically and temporally) for the DNSKEY RRSet generated		(cryptographically and temporally) for the DNSKEY RRSet generated
	with the private key corresponding to the DNSKEY found in the		with the private key corresponding to the DNSKEY found in the
	previous step.		previous step.
	If the validating resolver can successfully complete the steps above,		If the validating resolver can successfully complete the steps above,
	all DNSKEY RRs in the RRSet ought to be considered authenticated and		all DNSKEY RRs in the RRSet ought to be considered authenticated and
	can be used authenticate RRSets at or below the trust anchor.		can be used to authenticate RRSets at or below the trust anchor.
	If any of the steps above result in an error, the validating resolver		If any of the steps above result in an error, the validating resolver
	SHOULD log them.		SHOULD log them.
	If there are multiple trust anchors configured for a zone, any one of		If there are multiple trust anchors configured for a zone, any one of
	them is sufficient to validate data in the zone. For this reason,		them is sufficient to validate data in the zone. For this reason,
	old trust anchors SHOULD be removed from a validating resolver's		old trust anchors SHOULD be removed from a validating resolver's
	trust anchor list soon after the corresponding keys are no longer		trust anchor list soon after the corresponding keys are no longer
	used by the zone. A validating resolver should remove a trust anchor		used by the zone. If there are multiple trust anchors configured for
	that has been revoked as indicated by the REVOKE bit in the		a zone, any one of them is sufficient to validate data in the zone.
	corresponding DNSKEY record as described in RFC 5011 [6].		For this reason, old trust anchors SHOULD be removed from a
			validating resolver's trust anchor list soon after the corresponding
			keys are no longer used by the zone, as described in RFC 5011
			[RFC5011].
	If a validating resolver is unable to retrieve a signed DNSKEY RRSet		If a validating resolver is unable to retrieve a signed DNSKEY RRSet
	corresponding to a trust anchor (i.e., prime the trust anchor), it		corresponding to a trust anchor (i.e., prime the trust anchor), it
	SHOULD log this condition as an error. Inability to prime a zone's		SHOULD log this condition as an error. Inability to prime a zone's
	trust anchor results in the validating resolver's inability to		trust anchor results in the validating resolver's inability to
	validate data from the corresponding zone. The validating resolver		validate data from the corresponding zone. The validating resolver
	SHOULD treat this zone as bogus.		SHOULD treat this zone as bogus.
	4. Trust Anchor Maintenance		4. Trust Anchor Maintenance
	Trust anchors correspond to zones' key signing keys and these keys do		Trust anchors correspond to zones' key signing keys and these keys do
	change in the course of normal operation. Validating resolver		change in the course of normal operation. It is up to validating
	operators MUST ensure that configured trust anchor information		resolver operators to ensure that configured trust anchor information
	remains current and does not go stale: each configured trust anchor		remains current and does not go stale: each configured trust anchor
	SHOULD correspond to a DNSKEY RR in the trust anchor zone's apex		SHOULD correspond to a DNSKEY RR in the trust anchor zone's apex
	DNSKEY RRSet. This process is called trust anchor maintenance.		DNSKEY RRSet. This process is called trust anchor maintenance.
	(Initial trust anchor configuration requires human intervention to		(Initial trust anchor configuration requires human intervention to
	verify the trust anchor's authenticity using out-of-band means and is		verify the trust anchor's authenticity using out-of-band means and is
	outside the scope of this document.)		outside the scope of this document.)
	This section provides a brief overview of some possible mechanisms to		This section provides a brief overview of some possible mechanisms to
	keep trust anchor information current:		keep trust anchor information current:
	skipping to change at page 7, line 35		skipping to change at page 7, line 35
	RRSet) and updating that information. This process MAY require		RRSet) and updating that information. This process MAY require
	the operator to use the same out-of-band verification mechanism as		the operator to use the same out-of-band verification mechanism as
	used for initial configuration to ensure that the new trust anchor		used for initial configuration to ensure that the new trust anchor
	DS record is trustworthy. Because manual maintenance is		DS record is trustworthy. Because manual maintenance is
	burdensome and prone to error, and because other automated trust		burdensome and prone to error, and because other automated trust
	anchor maintenance processes either exist or are in development,		anchor maintenance processes either exist or are in development,
	manual trust anchor maintenance is NOT RECOMMENDED.		manual trust anchor maintenance is NOT RECOMMENDED.
	DNSSEC In-band Update: The IETF DNS Extensions Working Group has		DNSSEC In-band Update: The IETF DNS Extensions Working Group has
	developed a protocol to automatically update DNSSEC trust anchors,		developed a protocol to automatically update DNSSEC trust anchors,
	which is described in RFC 5011 [6]. This protocol relies on a		which is described in RFC 5011 [RFC5011]. This protocol relies on
	small DNSSEC protocol change (an additional flag in the DNSKEY		a small DNSSEC protocol change (an additional flag in the DNSKEY
	record) and can be implemented either in a validating resolver		record) and can be implemented either in a validating resolver
	itself or in an external program with access to the validating		itself or in an external program with access to the validating
	resolver's trust anchor configuration data.		resolver's trust anchor configuration data.
	Trusted update mechanism: Updated trust anchor information MAY be		Trusted update mechanism: Updated trust anchor information MAY be
	obtained via a trusted non-DNS update mechanism. One possibility		obtained via a trusted non-DNS update mechanism. One possibility
	is the operating system update mechanism provided by most software		is the operating system update mechanism provided by most software
	vendors. Operators already place considerable trust in this		vendors. Operators already place considerable trust in this
	mechanism, so it is reasonable to extend this trust to allow		mechanism, so it is reasonable to extend this trust to allow
	distribution and update of DNSSEC public key material. Another		distribution and update of DNSSEC public key material. Another
	skipping to change at page 9, line 28		skipping to change at page 9, line 28
	If multiple mechanisms are updating the trust anchor list then there		If multiple mechanisms are updating the trust anchor list then there
	is the possibility of conflict, such as one mechanism reinserting an		is the possibility of conflict, such as one mechanism reinserting an
	expired trust anchor.		expired trust anchor.
	Trust anchors are configuration information. A validating resolver		Trust anchors are configuration information. A validating resolver
	ought to treat this information differently than DNS data obtained		ought to treat this information differently than DNS data obtained
	over the network and never use the configured trust anchors as part		over the network and never use the configured trust anchors as part
	of an answer.		of an answer.
	A signed zone that plans to transition to an unsigned state must		A signed zone that plans to transition to an unsigned state must
	first give a warning that it is going insecure. Failure to do so		first give a warning that it is going insecure, such as using the
	will cause all validating resolvers that keep a trust anchor for the		technique described in RFC 5011 [RFC5011]. Failure to do so will
	zone configured to treat responses from the zone as bogus, causing		cause all validating resolvers that keep a trust anchor for the zone
			configured to treat responses from the zone as bogus, causing
	resolution failures.		resolution failures.
	6. IANA considerations		6. IANA considerations
	This document does not have any IANA actions.		This document does not have any IANA actions.
	7. Acknowledgments		7. Acknowledgments
	This work was undertaken at the suggestion of the DNSSEC Deployment		This work was undertaken at the suggestion of the DNSSEC Deployment
	working group (www.dnssec-deployment.org).		working group (www.dnssec-deployment.org).
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	"DNS Security Introduction and Requirements", RFC 4033,		Rose, "DNS Security Introduction and Requirements",
	March 2005.		RFC 4033, March 2005.
	[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	"Resource Records for the DNS Security Extensions", RFC 4034,		Rose, "Resource Records for the DNS Security Extensions",
	March 2005.		RFC 4034, March 2005.
	[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	"Protocol Modifications for the DNS Security Extensions",		Rose, "Protocol Modifications for the DNS Security
	RFC 4035, March 2005.		Extensions", RFC 4035, March 2005.
	[5] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)		[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
	Resource Records (RRs)", RFC 4509, May 2006.		(DS) Resource Records (RRs)", RFC 4509, May 2006.
	[6] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Anchors", RFC 5011, September 2007.		Hashing for Message Authentication", RFC 2104,
			February 1997.
			[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
			Trust Anchors", RFC 5011, September 2007.
	8.2. Informative References		8.2. Informative References
	Authors' Addresses		Authors' Addresses
	Matt Larson		Matt Larson
	VeriSign, Inc.		VeriSign, Inc.
	21345 Ridgetop Circle		21345 Ridgetop Circle
	Dulles, VA 20166-6503		Dulles, VA 20166-6503
	USA		USA
	skipping to change at page 14, line 44		skipping to change at line 395
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 22 change blocks.
	50 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/