draft-ietf-dnsop-dnssec-trust-anchor-00.txt		draft-ietf-dnsop-dnssec-trust-anchor-01.txt
	DNS Operations M. Larson		DNS Operations M. Larson
	Internet-Draft VeriSign		Internet-Draft VeriSign
	Expires: August 11, 2008 O. Gudmundsson		Expires: August 14, 2008 O. Gudmundsson
	OGUD Consulting LLC		OGUD Consulting LLC
	February 8, 2008		February 11, 2008
	DNSSEC Trust Anchor Configuration and Maintenance		DNSSEC Trust Anchor Configuration and Maintenance
	draft-ietf-dnsop-dnssec-trust-anchor-00		draft-ietf-dnsop-dnssec-trust-anchor-01
	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 11, 2008.		This Internet-Draft will expire on August 14, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		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
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 4		2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 4
	3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 5		3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 5
	4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 7		4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 7
	5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		5. Security considerations . . . . . . . . . . . . . . . . . . . 9
	6. Security considerations . . . . . . . . . . . . . . . . . . . 9		6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
	7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Internationalization considerations . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	9.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 ([2], [3] and [4]) describe the need
	for trust anchors and how they are used. A validating security-aware		for trust anchors and how they are used. A validating security-aware
	resolver (subsequently referred to as a "validating resolver") needs		resolver (subsequently referred to as a "validating resolver") needs
	to be configured with one or more trust anchors, which specify the		to be configured with one or more trust anchors, which specify the
	public keys of signed zones. To authenticate DNS data, a validating		public keys of signed zones. To authenticate DNS data, a validating
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	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 [1].
	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 [2], a trust anchor can be specified as either
	a DNSKEY resource record (RR) or a DS RR, which contains the hash of		a public key from a DNSKEY resource record (RR) or the hash of a
	the specific DNSKEY RR. (DS records are defined in Section 5 of RFC		public key as found in a DS RR. (DS records are defined in Section 5
	4034 [3].)		of RFC 4034 [3].)
	This document RECOMMENDS that a trust anchor be specified as a DS RR.		This document RECOMMENDS that a trust anchor be specified using the
	A DS RR used to specify a trust anchor in this manner SHOULD use a		hash of a public key rather than the key itself, i.e., the fields
	digest algorithm of SHA-256 [5], which is DS digest type 2. DS RRs		from a DS record rather than from a DNSKEY record. A trust anchor
	using SHA-1 (DS digest type 1) to specify trust anchors are NOT		specified in this manner will use all the fields from the
	RECOMMENDED: RFC 4509 encourages the use of DS RRs using SHA-256 over		corresponding key's DS record, including the owner name to indicate
	those using SHA-1.		which zone the trust anchor corresponds to as well as the various
			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
			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.
	Specifying a trust anchor using a DS RR instead of a DNSKEY RR offers		Specifying a trust anchor using a DS format instead of a DNSKEY
	a slight advantage because it forces the resolver to make a DNS query		format offers a slight advantage because it forces the resolver to
	to obtain the trust anchor's complete DNSKEY RRSet during a priming		make a DNS query to obtain the trust anchor's complete DNSKEY RRSet
	operation (described below). If only a DNSKEY record were specified,		during a priming operation (described below). If only a DNSKEY
	a resolver implementers could conceivably avoid priming the trust		record were specified, resolver implementers could conceivably avoid
	anchor. But priming is desirable because it causes the resolver to		priming the trust anchor. But priming is desirable because it causes
	retrieve an up-to-date version of a zone's DNSKEY RRSet from one of		the resolver to retrieve an up-to-date version of a zone's DNSKEY
	the zone's authoritative servers. It should be noted that in		RRSet from one of the zone's authoritative servers. It should be
	practice, priming is almost always required because data in the trust		noted that in practice, priming is almost always required because
	anchor zone will usually be signed with a different key than the one		data in the trust anchor zone will usually be signed with a different
	configured as the trust anchor, thus requiring the validating		key than the one configured as the trust anchor, thus requiring the
	resolver to obtain all keys in the DNSKEY RRSet.		validating resolver to obtain all keys in the DNSKEY RRSet.
	Using a DS RR is also recommended because it is smaller than the		Using a DS format is also recommended because it is smaller than the
	DNSKEY RR 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 RR is that		Another advantage of configuring a trust anchor using a DS record is
	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.
	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 RR for that trust anchor to be		corresponding to a configured DS for that trust anchor to be usable
	usable in DNSSEC validation. This process is called "priming" the		in DNSSEC validation. This process is called "priming" the trust
	trust anchor. Priming can occur when the validating resolver starts,		anchor. Priming can occur when the validating resolver starts, but a
	but a validating resolver SHOULD defer priming of individual trust		validating resolver SHOULD defer priming of individual trust anchors
	anchors until each is first needed for verification. This priming on		until each is first needed for verification. This priming on demand
	demand is especially important when a validating resolver is		is especially important when a validating resolver is configured with
	configured with a large number of trust anchors to avoid sending a		a large number of trust anchors to avoid sending a large number of
	large number of DNS queries on start-up. This section adds		DNS queries on start-up. This section adds additional details to the
	additional details to the discussion of trust anchors in Section 5 of		discussion of trust anchors in Section 5 of RFC 4035 [4].
	RFC 4035 [4].
	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 DS RR from the validating resolver's		1. Read the trust anchor's information (corresponding to the fields
	configuration (e.g., a text file).		in a DS record) from the validating resolver's configuration
			(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
	DS RR. (The validating resolver can either perform iterative		trust anchor. (The validating resolver can either perform
	resolution or request recursive service from a recursive name		iterative resolution or request recursive service from a
	server, depending on its capabilities.)		recursive name server, depending on its capabilities.)
	3. Verify that the DNSKEY RR corresponding to the configured DS RR		3. Verify that the DNSKEY RR corresponding to the configured trust
	(i.e., the DNSKEY whose hash appears in the DS record) appears in		anchor (i.e., the DNSKEY whose hash is configured) appears in the
	the DNSKEY RRSet and that the DNSKEY RR has the Zone Key Flag		DNSKEY RRSet and that this DNSKEY RR has the Zone Key Flag
	(DNSKEY RDATA bit 7) set (i.e. the DNSKEY is allowed to sign DNS		(DNSKEY RDATA bit 7) set. (This bit only indicates that the
	zone, this does not make the key a zone signing key).		DNSKEY is allowed to sign the zone. This DNSKEY may or not be a
			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
	used authenticate RRSets at or below the trust anchor.		can be used 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. A validating resolver should remove a trust anchor
	that has been revoked as indicated by the REVOKE bit in the		that has been revoked as indicated by the REVOKE bit in the
	corresponding DNSKEY record as described in RFC 5011. RFC5011 [6]		corresponding DNSKEY record as described in RFC 5011 [6].
	If a validating resolver is unable to to retrieve a signed DNSKEY		If a validating resolver is unable to retrieve a signed DNSKEY RRSet
	RRSet corresponding to a trust anchor (i.e., prime the trust anchor),		corresponding to a trust anchor (i.e., prime the trust anchor), it
	it SHOULD log this condition as an error. Inability to prime a		SHOULD log this condition as an error. Inability to prime a zone's
	zone's trust anchor will likely result in the validating resolver's		trust anchor results in the validating resolver's inability to
	inability to validate data from the corresponding zone and cause the		validate data from the corresponding zone. The validating resolver
	resolver to return an error in response to the original DNS query.		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. Validating resolver
	operators MUST ensure that configured trust anchor information		operators MUST 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
	DS RR SHOULD correspond to a DNSKEY RR in the trust anchor zone's		SHOULD correspond to a DNSKEY RR in the trust anchor zone's apex
	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:
	Manual configuration: The validating resolver operator MAY choose to		Manual configuration: The validating resolver operator MAY choose to
	maintain trust anchor information completely manually. In this		maintain trust anchor information completely manually. In this
	case, the operator assumes responsibility for noticing stale trust		case, the operator assumes responsibility for noticing stale trust
	anchor information (i.e., DS records that no longer point to a		anchor information (i.e., DS records that no longer point to a
	corresponding DNSKEY RR in the trust anchor zone's apex DNSKEY		corresponding DNSKEY RR in the trust anchor zone's apex DNSKEY
	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		the operator to use the same out-of-band verification mechanism as
	used to initial configuration to ensure that the new trust anchor		used for initial configuration to ensure that the new trust anchor
	DS RR is trustworthy. Because manual maintenance is burdensome		DS record is trustworthy. Because manual maintenance is
	and prone to error, and because other automated trust anchor		burdensome and prone to error, and because other automated trust
	maintenance processes either exist or are in development, manual		anchor maintenance processes either exist or are in development,
	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. RFC5011 [6] This protocol relies		which is described in RFC 5011 [6]. This protocol relies on a
	on a small DNSSEC protocol change (an additional flag in the		small DNSSEC protocol change (an additional flag in the DNSKEY
	DNSKEY record) and can be implemented either in a validating		record) and can be implemented either in a validating resolver
	resolver itself or in an external program with access to the		itself or in an external program with access to the validating
	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
	possibility is to obtain trust anchor configuration directly from		possibility is to obtain trust anchor configuration directly from
	the validating resolver software vendor. This mechanism is		the validating resolver software vendor. This mechanism is
	realistically only feasible for updating a small number of trust		realistically only feasible for updating a small number of trust
	anchors, such as for the top-level domains. In a public DNSSEC		anchors, such as for the top-level domains. In a public DNSSEC
	deployment, the root zone would be signed and only the root's		deployment, the root zone would be signed and only the root's
	trust anchor would need updating.		trust anchor would need updating.
	5. Acknowledgments		Combination of update mechanisms: It is possible that for a given
			validating resolver, different trust anchors will be maintained by
	This work was undertaken at the suggestion of the DNSSEC Deployment		different mechanisms. For example, some trust anchors might be
	working group (www.dnssec-deployment.org).		kept up to date by a trusted update mechanism and others
			maintained by some site-specific mechanism. In this case, it is
			important that the mechanisms maintain a mutually exclusive set of
			trust anchors.
	6. Security considerations		5. Security considerations
	This document proposes a standard format for documenting DNSSEC trust		This document proposes a standard format for documenting DNSSEC trust
	anchors. Configuration of trust anchors, especially those obtained		anchors. Configuration of trust anchors, especially those obtained
	from third parties as part of an automated process, is a critical		from third parties as part of an automated process, is a critical
	security operation. The procedures described above describe the		security operation. The procedures listed above describe the minimal
	minimal checks that should be performed and reporting that should be		checks that should be performed and reporting that should be done
	done when configuring trust anchors.		when configuring trust anchors.
	In a widespread DNSSEC deployment, the root zone and many TLD zones		In a widespread DNSSEC deployment, the root zone and many TLD zones
	would be signed, thus greatly reducing the number trust anchors that		would be signed, thus greatly reducing the number trust anchors that
	validating resolvers would need to store and keep track of.		validating resolvers would need to store and keep track of.
	7. IANA considerations		If multiple mechanisms are updating the trust anchor list then there
			is the possibility of conflict, such as one mechanism reinserting an
			expired trust anchor.
			Trust anchors are configuration information. A validating resolver
			ought to treat this information differently than DNS data obtained
			over the network and never use the configured trust anchors as part
			of an answer.
			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
			will cause all validating resolvers that keep a trust anchor for the
			zone configured to treat responses from the zone as bogus, causing
			resolution failures.
			6. IANA considerations
	This document does not have any IANA actions.		This document does not have any IANA actions.
	8. Internationalization considerations		7. Acknowledgments
	There are no new internationalization considerations introduced by		This work was undertaken at the suggestion of the DNSSEC Deployment
	this memo.		working group (www.dnssec-deployment.org).
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"DNS Security Introduction and Requirements", RFC 4033,		"DNS Security Introduction and Requirements", RFC 4033,
	March 2005.		March 2005.
	[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"Resource Records for the DNS Security Extensions", RFC 4034,		"Resource Records for the DNS Security Extensions", RFC 4034,
	skipping to change at page 12, line 30		skipping to change at page 12, line 30
	[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,		[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
	"Protocol Modifications for the DNS Security Extensions",		"Protocol Modifications for the DNS Security Extensions",
	RFC 4035, March 2005.		RFC 4035, March 2005.
	[5] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)		[5] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
	Resource Records (RRs)", RFC 4509, May 2006.		Resource Records (RRs)", RFC 4509, May 2006.
	[6] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust		[6] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust
	Anchors", RFC 5011, September 2007.		Anchors", RFC 5011, September 2007.
	9.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
	Email: mlarson@verisign.com		Email: mlarson@verisign.com
End of changes. 29 change blocks.
	92 lines changed or deleted		114 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/