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 - Security Considerations: 4 - Applicability statement
This document redefines a bit in the DNS header. If a resolver The AD bit is intended to allow the transmission of the indication
trusts the value of the AD bit, it must be sure that the server is that a resolver has verified the DNSSEC signatures accompanying the
using the updated definition, which is any server supporting the OK records in the Answer and Authority section. The AD bit MUST only be
bit. 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:
Authoritative servers that set the AD bit on answers without doing - Fiat: An organization can dictate that it is OK to trust certain DNS
cryptographic checks must only do so if explicitly configured to. servers.
This only affects resolvers that directly query and trust the - Personal: Because of a personal relationship or the reputation of a
authoritative server, and this functionality should only be used on resolver operator, a DNS consumer can decide to trust that
servers that act both as authoritative servers and recursive
resolver. resolver.
- Knowledge: If a resolver operator posts the configured policy of a
resolver a consumer can decide that resolver is trustworthy.
Authoritative servers that set the AD bit on answers without doing In the absence of one or more of these factors AD bit from a resolver
cryptographic checks must only do so on explicit zone by zone SHOULD NOT be trusted. For example, home users frequently depend on
enablement. This only affects resolvers that trust the server and their ISP to provide recursive DNS service; it is not advisable to
this functionality should only be used on servers that act both as trust these resolvers. A roaming/traveling host SHOULD not use DNS
authoritative servers and recursive resolver. resolvers offered by DHCP when looking up information where security
status matters.
Resolvers (full or stub) that blindly trust the AD bit without When faced with a situation where there are no satisfactory recursive
knowing the security policy of the server generating the answer can resolvers available, running one locally is RECOMMENDED. This has
not be considered security aware. 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:
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 responder is
using the updated definition, which is any DNS server/resolver
supporting the OK bit[RFC3225].
Authoritative servers can be explicitly configured to set the AD bit
on answers without doing cryptographic checks. This behavior MUST be
off by default. The only affected resolvers are those 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.
Resolvers (full or stub) that trust the AD bit on answers from a
configured set of resolvers are DNSSEC security compliant.
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. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/