draft-ietf-dnsext-ad-is-secure-04.txt   draft-ietf-dnsext-ad-is-secure-05.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-04.txt> February 2002 <draft-ietf-dnsext-ad-is-secure-05.txt> March 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 July 10, 2002. This draft expires on September 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 current definition of the AD
bit in the DNS header is not useful. This draft changes the bit in the DNS header is not useful. This draft changes the
specification so that the AD bit is only set on answers where specification so that the AD bit is only set on answers where
skipping to change at page 2, line 13 skipping to change at page 2, line 13
authoritative for the data and is allowed to set the bit by policy. 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 bit indicates in a
response that all data included in the answer and authority sections response that all data included in the answer and authority sections
of the response have been authenticated by the server according to of the response have been authenticated by the server according to
the policies of that server. This is not especially to the policies the policies of that server. This is not especially useful in
of that server. This is not especially useful in practice, since a practice, since a conformant server should never reply with data that
conformant server should never reply with data that failed its failed its security policy.
security policy.
This draft proposes to redefine the AD bit such that it is only set This draft proposes to redefine the AD bit such that it is only set
if all data in the response has been cryptographically verified or if all data in the response has been cryptographically verified or
otherwise meets the server's local security policy. Thus, a response otherwise 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 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.
skipping to change at page 3, line 16 skipping to change at page 3, line 16
the answer and authority sections of the response are Authenticated." the answer and authority sections of the response are Authenticated."
"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 authorative servers 2.2 - Setting of AD bit by authoritative servers
A primary server for a secure zone the data MAY have a policy of Primary server for a secure zone the data, MAY have the policy of
treating authoritative secure zones as Authenticated. Secondary treating authoritative secure zones as Authenticated. Secondary
servers MAY have the same policy, but SHOULD NOT consider zone data servers MAY have the same policy, but SHOULD NOT consider zone data
Authenticated unless the zone was transfered securely and/or the data Authenticated unless the zone was transfered securely and/or the data
was verified. An authoritative server MUST only set the AD bit for was 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 authorative. 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 answer 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
skipping to change at page 4, line 20 skipping to change at page 4, line 20
using the updated definition, which is any server supporting the OK using the updated definition, which is any server supporting the OK
bit. bit.
Authoritative servers that set the AD bit on answers without doing Authoritative servers that set the AD bit on answers without doing
cryptographic checks must only do so if explicitly configured to. cryptographic checks must only do so if explicitly configured to.
This only affects resolvers that directly query and trust the This only affects resolvers that directly query and trust the
authoritative server, and this functionality should only be used on authoritative server, and this functionality should only be used on
servers that act both as authoritative servers and recursive servers that act both as authoritative servers and recursive
resolver. resolver.
Authorative servers that set the AD bit on answers without doing Authoritative servers that set the AD bit on answers without doing
cryptographic checks must only do so on explicit zone by zone cryptographic checks must only do so on explicit zone by zone
enablement. This only affects resolvers that trust the server and enablement. This only affects resolvers that trust the server and
this functionality should only be used on servers that act both as this functionality should only be used on servers that act both as
authorative servers and recursive resolver. authoritative servers and recursive resolver.
Resolvers (full or stub) that blindly trust the AD bit without Resolvers (full or stub) that blindly trust the AD bit without
knowing the security policy of the server generating the answer can knowing the security policy of the server generating the answer can
not be considered security aware. 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: Andreas
Gustafsson, Bob Halley, Steven Jacob, Edward Lewis, Jakob Schlyter, Gustafsson, Bob Halley, Steven Jacob, Edward Lewis, Jakob Schlyter,
Roy Arends, Ted Lindgreen. Roy Arends, Ted Lindgreen.
skipping to change at page 5, line 23 skipping to change at page 5, line 23
Brian Wellington Olafur Gudmundsson Brian Wellington Olafur Gudmundsson
Nominum Inc. Nominum Inc.
2385 Bay Street 3826 Legation Street, NW 2385 Bay Street 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 (2001). 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
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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