< draft-ietf-dnsext-ad-is-secure-05.txt		draft-ietf-dnsext-ad-is-secure-06.txt >
	DNSEXT Working Group Brian Wellington		DNSEXT Working Group Brian Wellington
	INTERNET-DRAFT Olafur Gudmundsson		INTERNET-DRAFT Olafur Gudmundsson
	<draft-ietf-dnsext-ad-is-secure-05.txt> March 2002		<draft-ietf-dnsext-ad-is-secure-06.txt> June 2002
	Updates: RFC 2535		Updates: RFC 2535
	Redefinition of DNS AD bit		Redefinition of DNS AD bit
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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
	Comments should be sent to the authors or the DNSEXT WG mailing list		Comments should be sent to the authors or the DNSEXT WG mailing list
	namedroppers@ops.ietf.org		namedroppers@ops.ietf.org
	This draft expires on September 25, 2002.		This draft expires on December 25, 2002.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All rights reserved.		Copyright (C) The Internet Society (2002). All rights reserved.
	Abstract		Abstract
	Based on implementation experience, the current definition of the AD		Based on implementation experience, the RFC2535 definition of the
	bit in the DNS header is not useful. This draft changes the		Authenticated Data (AD) bit in the DNS header is not useful. This
	specification so that the AD bit is only set on answers where		draft changes the specification so that the AD bit is only set on
	signatures have been cryptographically verified or the server is		answers where signatures have been cryptographically verified or the
	authoritative for the data and is allowed to set the bit by policy.		server is authoritative for the data and is allowed to set the bit by
			policy.
	1 - Introduction		1 - Introduction
	Familiarity with the DNS system [RFC1035] and DNS security extensions		Familiarity with the DNS system [RFC1035] and DNS security extensions
	[RFC2535] is helpful but not necessary.		[RFC2535] is helpful but not necessary.
	As specified in RFC 2535 (section 6.1), the AD bit indicates in a		As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
	response that all data included in the answer and authority sections		bit indicates in a response that all data included in the answer and
	of the response have been authenticated by the server according to		authority sections of the response have been authenticated by the
	the policies of that server. This is not especially useful in		server according to the policies of that server. This is not
	practice, since a conformant server should never reply with data that		especially useful in practice, since a conformant server SHOULD never
	failed its security policy.		reply with data that failed its security policy.
	This draft proposes to redefine the AD bit such that it is only set		This draft redefines the AD bit such that it is only set if all data
	if all data in the response has been cryptographically verified or		in the response has been cryptographically verified or otherwise
	otherwise meets the server's local security policy. Thus, a response		meets the server's local security policy. Thus, a response
	containing properly delegated insecure data will not have AD set, nor		containing properly delegated insecure data will not have AD set, nor
	will a response from a server configured without DNSSEC keys. As		will a response from a server configured without DNSSEC keys. As
	before, data which failed to verify will not be returned. An		before, data which failed to verify will not be returned. An
	application running on a host that has trust relationship with the		application running on a host that has a trust relationship with the
	server performing the recursive query can now use the value of the AD		server performing the recursive query can now use the value of the AD
	bit to determine if the data is secure or not.		bit to determine if the data is secure or not.
	1.1 - Requirements		1.1 - Motivation
			A full DNSSEC capable resolver called directly from an application
			can return to the application the security status of the RRsets in
			the answer. However, most applications use a limited stub resolver
			that relies on an external full resolver. The remote resolver can
			use the AD bit in a response to indicate the security status of the
			data in the answer, and the local resolver can pass this information
			to the application. The application in this context can be either a
			human using a DNS tool or a software application.
			The AD bit SHOULD be used by the local resolver if and only if it has
			been explicitly configured to trust the remote resolver. The AD bit
			SHOULD be ignored when the remote resolver is not trusted.
			An alternate solution would be to embed a full DNSSEC resolver into
			every application. This has several disadvantages.
			- DNSSEC validation is both CPU and network intensive, and caching
			SHOULD be used whenever possible.
			- DNSSEC requires non-trivial configuration - the root key must be
			configured, as well as keys for any "islands of security" that will
			exist until DNSSEC is fully deployed. The number of configuration
			points should be minimized.
			1.2 - Requirements
	The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD		The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
	NOT", in this document are to be interpreted as described in RFC2119.		NOT", "RECOMMENDED", in this document are to be interpreted as
			described in RFC2119.
	1.2 - Updated documents and sections		1.3 - Updated documents and sections
	The definition of the AD bit in RFC2535, Section 6.1, is changed.		The definition of the AD bit in RFC2535, Section 6.1, is changed.
	2 - Setting of AD bit		2 - Setting of AD bit
	The presence of the CD (checking disabled) bit in a query does not		The presence of the CD (Checking Disabled) bit in a query does not
	affect the setting of the AD bit in the response. If the CD bit is		affect the setting of the AD bit in the response. If the CD bit is
	set, the server will not perform checking, but SHOULD still set the		set, the server will not perform checking, but SHOULD still set the
	AD bit if the data has already been checked or complies with local		AD bit if the data has already been cryptographically verified or
	policy. The AD bit MUST only be set if DNSSEC records have been		complies with local policy. The AD bit MUST only be set if DNSSEC
	requested [RFC3225] and relevant SIG records are returned.		records have been requested via the OK bit [RFC3225] and relevant SIG
			records are returned.
	2.1 - Setting of AD bit by recursive servers		2.1 - Setting of AD bit by recursive servers
	Section 6.1 of RFC2535 says:		Section 6.1 of RFC2535 says:
	"The AD bit MUST NOT be set on a response unless all of the RRs in		"The AD bit MUST NOT be set on a response unless all of the RRs in
	the answer and authority sections of the response are either		the answer and authority sections of the response are either
	Authenticated or Insecure."		Authenticated or Insecure."
	The replacement text reads:		The replacement text reads:
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 48 ¶
	"The AD bit SHOULD be set if and only if all RRs in the answer		"The AD bit SHOULD be set if and only if all RRs in the answer
	section and any relevant negative response RRs in the authority		section and any relevant negative response RRs in the authority
	section are Authenticated."		section are Authenticated."
	A recursive DNS server following this modified specification will		A recursive DNS server following this modified specification will
	only set the AD bit when it has cryptographically verified the data		only set the AD bit when it has cryptographically verified the data
	in the answer.		in the answer.
	2.2 - Setting of AD bit by authoritative servers		2.2 - Setting of AD bit by authoritative servers
	Primary server for a secure zone the data, MAY have the policy of		A primary server for a secure zone MAY have the policy of treating
	treating authoritative secure zones as Authenticated. Secondary		authoritative secure zones as Authenticated. Secondary servers MAY
	servers MAY have the same policy, but SHOULD NOT consider zone data		have the same policy, but SHOULD NOT consider zone data Authenticated
	Authenticated unless the zone was transfered securely and/or the data		unless the zone was transferred securely and/or the data was
	was verified. An authoritative server MUST only set the AD bit for		verified. An authoritative server MUST only set the AD bit for
	authoritative answers from a secure zone if it has been explicitly		authoritative answers from a secure zone if it has been explicitly
	configured to do so. The default for this behavior SHOULD be off.		configured to do so. The default for this behavior SHOULD be off.
	2.2.1 - Justification for setting AD bit w/o verifying data		2.2.1 - Justification for setting AD bit w/o verifying data
	The setting of the AD bit by authoritative servers affects only a		The setting of the AD bit by authoritative servers affects only a
	small set of resolvers that are configured to directly query and		small set of resolvers that are configured to directly query and
	trust authoritative servers. This only affects servers that function		trust authoritative servers. This only affects servers that function
	as both recursive and authoritative. All recursive resolvers SHOULD		as both recursive and authoritative. All recursive resolvers SHOULD
	ignore the AD bit.		ignore the AD bit.
	The cost of verifying all signatures on load by an authoritative		The cost of verifying all signatures on load by an authoritative
	server can be high and increases the delay before it can begin		server can be high and increases the delay before it can begin
	answering queries. Verifying signatures at query time is also		answering queries. Verifying signatures at query time is also
	expensive and could lead to resolvers timing out on many queries		expensive and could lead to resolvers timing out on many queries
	after the server reloads zones.		after the server reloads zones.
	Organizations that require that all DNS responses contain		Organizations that require that all DNS responses contain
	cryptographically verified data must separate the functions of		cryptographically verified data MUST separate the functions of
	authoritative and recursive servers, as authoritative servers are not		authoritative and recursive servers, as authoritative servers are not
	required to validate local secure data.		required to validate local secure data.
	3 - Interpretation of the AD bit		3 - Interpretation of the AD bit
	A response containing data marked Insecure in the answer or authority		A response containing data marked Insecure in the answer or authority
	section will never have the AD bit set. In this case, the resolver		section MUST never have the AD bit set. In this case, the resolver
	SHOULD treat the data as Insecure whether or not SIG records are		SHOULD treat the data as Insecure whether or not SIG records are
	present.		present.
	A resolver MUST NOT blindly trust the AD bit unless it communicates		A resolver MUST NOT blindly trust the AD bit unless it communicates
	with the server over a secure transport mechanism or using message		with the full function resolver over a secure transport mechanism or
	authentication such as TSIG [RFC2845] or SIG(0) [RFC2931] and is		using message authentication such as TSIG [RFC2845] or SIG(0)
	configured to trust the server.		[RFC2931] and is explicitly configured to trust this resolver.
			4 - Applicability statement
			The AD bit is intended to allow the transmission of the indication
			that a resolver has verified the DNSSEC signatures accompanying the
			records in the Answer and Authority section. The AD bit MUST only be
			trusted when the end consumer of the DNS data has confidence that the
			intermediary resolver setting the AD bit is trustworthy. This can
			only be accomplished via out of band mechanism such as:
			- Fiat: An organization can dictate that it is OK to trust certain DNS
			servers.
			- Personal: Because of a personal relationship or the reputation of a
			resolver operator, a DNS consumer can decide to trust that
			resolver.
			- Knowledge: If a resolver operator posts the configured policy of a
			resolver a consumer can decide that resolver is trustworthy.
			In the absence of one or more of these factors AD bit from a resolver
			SHOULD NOT be trusted. For example, home users frequently depend on
			their ISP to provide recursive DNS service; it is not advisable to
			trust these resolvers. A roaming/traveling host SHOULD not use DNS
			resolvers offered by DHCP when looking up information where security
			status matters.
			When faced with a situation where there are no satisfactory recursive
			resolvers available, running one locally is RECOMMENDED. This has
			the advantage that it can be trusted, and the AD bit can still be
			used to allow applications to use stub resolvers.
	4 - Security Considerations:		4 - Security Considerations:
	This document redefines a bit in the DNS header. If a resolver		This document redefines a bit in the DNS header. If a resolver
	trusts the value of the AD bit, it must be sure that the server is		trusts the value of the AD bit, it must be sure that the responder is
	using the updated definition, which is any server supporting the OK		using the updated definition, which is any DNS server/resolver
	bit.		supporting the OK bit[RFC3225].
	Authoritative servers that set the AD bit on answers without doing
	cryptographic checks must only do so if explicitly configured to.
	This only affects resolvers that directly query and trust the
	authoritative server, and this functionality should only be used on
	servers that act both as authoritative servers and recursive
	resolver.
	Authoritative servers that set the AD bit on answers without doing		Authoritative servers can be explicitly configured to set the AD bit
	cryptographic checks must only do so on explicit zone by zone		on answers without doing cryptographic checks. This behavior MUST be
	enablement. This only affects resolvers that trust the server and		off by default. The only affected resolvers are those that directly
	this functionality should only be used on servers that act both as		query and trust the authoritative server, and this functionality
	authoritative servers and recursive resolver.		SHOULD only be used on servers that act both as authoritative servers
			and recursive resolver.
	Resolvers (full or stub) that blindly trust the AD bit without		Resolvers (full or stub) that trust the AD bit on answers from a
	knowing the security policy of the server generating the answer can		configured set of resolvers are DNSSEC security compliant.
	not be considered security aware.
	5 - IANA Considerations:		5 - IANA Considerations:
	None.		None.
	6 - Internationalization Considerations:		6 - Internationalization Considerations:
	None, this document does not change any textual data in any protocol.		None. This document does not change any textual data in any
			protocol.
	7 - Acknowledgments:		7 - Acknowledgments:
	The following people have provided input on this document: Andreas		The following people have provided input on this document: Robert
	Gustafsson, Bob Halley, Steven Jacob, Edward Lewis, Jakob Schlyter,		Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
	Roy Arends, Ted Lindgreen.		Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
	References:		Normative References:
	[RFC1035] P. Mockapetris, ``Domain Names - Implementation and		[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
	Specification'', STD 13, RFC 1035, November 1987.		Specification'', STD 13, RFC 1035, November 1987.
	[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC		[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
	2535, March 1999.		2535, March 1999.
	[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,		[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
	``Secret Key Transaction Authentication for DNS (TSIG)'', RFC		``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
	2845, May 2000.		2845, May 2000.
	skipping to change at page 5, line 16 ¶		skipping to change at page 6, line 22 ¶
	[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures		[RFC2931] D. Eastlake, ``DNS Request and Transaction Signatures
	(SIG(0))'', RFC 2931, September 2000.		(SIG(0))'', RFC 2931, September 2000.
	[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC		[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
	3225, December 2001.		3225, December 2001.
	Authors Addresses		Authors Addresses
	Brian Wellington Olafur Gudmundsson		Brian Wellington Olafur Gudmundsson
	Nominum Inc.		Nominum Inc.
	2385 Bay Street 3826 Legation Street, NW		2385 Bay Road 3826 Legation Street, NW
	Redwood City, CA, 94063 Washington, DC, 20015		Redwood City, CA, 94063 Washington, DC, 20015
	USA USA		USA USA
	<Brian.Wellington@nominum.com> <ogud@ogud.com>		<Brian.Wellington@nominum.com> <ogud@ogud.com>
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2002>. All Rights Reserved.		Copyright (C) The Internet Society (2002>. All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
End of changes. 22 change blocks.
	58 lines changed or deleted		110 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/