doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc3655.txt b/doc/rfc/rfc3655.txt
new file mode 100644
index 0000000..13e586b
--- /dev/null
+++ b/doc/rfc/rfc3655.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3655                                O. Gudmundsson
+Updates: 2535                                              November 2003
+Category: Standards Track
+
+
+            Redefinition of DNS Authenticated Data (AD) bit
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document alters the specification defined in RFC 2535.  Based on
+   implementation experience, the Authenticated Data (AD) bit in the DNS
+   header is not useful.  This document redefines the AD bit such that
+   it is only set if all answers or records proving that no answers
+   exist in the response has been cryptographically verified or
+   otherwise meets the server's local security policy.
+
+1.  Introduction
+
+   Familiarity with the DNS system [RFC1035] and DNS security extensions
+   [RFC2535] is helpful but not necessary.
+
+   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
+   bit indicates in a response that all data included in the answer and
+   authority sections of the response have been authenticated by the
+   server according to the policies of that server.  This is not
+   especially useful in practice, since a conformant server SHOULD never
+   reply with data that failed its security policy.
+
+   This document redefines the AD bit such that it is only set if all
+   data in the response has been cryptographically verified or otherwise
+   meets the server's local security policy.  Thus, neither a response
+   containing properly delegated insecure data, nor a server configured
+   without DNSSEC keys, will have the AD set.  As before, data that
+   failed to verify will not be returned.  An application running on a
+   host that has a trust relationship with the server performing the
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 1]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   recursive query can now use the value of the AD bit to determine
+   whether the data is secure.
+
+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 recursive name server which incorporates a
+   full resolver.  The recursive nameserver 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 recursive name server is not trusted.
+
+   An alternate solution would be to embed a full DNSSEC resolver into
+   every application, but 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
+   NOT", "RECOMMENDED", in this document are to be interpreted as
+   described in BCP 14, RFC 2119 [RFC2119].
+
+1.3.  Updated documents and sections
+
+   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
+
+2.  Setting of AD bit
+
+   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
+   set, the server will not perform checking, but SHOULD still set the
+   AD bit if the data has already been cryptographically verified or
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 2]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   complies with local policy.  The AD bit MUST only be set if DNSSEC
+   records have been requested via the DO bit [RFC3225] and relevant SIG
+   records are returned.
+
+2.1.  Setting of AD bit by recursive servers
+
+   Section 6.1 of RFC 2535 says:
+
+   "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
+   Authenticated or Insecure."
+
+   The replacement text reads:
+
+   "The AD bit MUST NOT be set on a response unless all of the RRsets in
+   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
+   section and any relevant negative response RRs in the authority
+   section are Authenticated."
+
+   A recursive DNS server following this modified specification will
+   only set the AD bit when it has cryptographically verified the data
+   in the answer.
+
+2.2.  Setting of AD bit by authoritative servers
+
+   A primary server for a secure zone MAY have the policy of treating
+   authoritative secure zones as Authenticated.  Secondary servers MAY
+   have the same policy, but SHOULD NOT consider zone data Authenticated
+   unless the zone was transferred securely and/or the data was
+   verified.  An authoritative server MUST only set the AD bit for
+   authoritative answers from a secure zone if it has been explicitly
+   configured to do so.  The default for this behavior SHOULD be off.
+
+   Note that having the AD bit clear on an authoritative answer is
+   normal and expected behavior.
+
+2.2.1.  Justification for setting AD bit w/o verifying data
+
+   The setting of the AD bit by authoritative servers affects only the
+   small set of resolvers that are configured to directly query and
+   trust authoritative servers.  This only affects servers that function
+   as both recursive and authoritative.  Iterative resolvers SHOULD
+   ignore the AD bit.
+
+   The cost of verifying all signatures on load by an authoritative
+   server can be high and increases the delay before it can begin
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 3]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   answering queries.  Verifying signatures at query time is also
+   expensive and could lead to resolvers timing out on many queries
+   after the server reloads zones.
+
+   Organizations requiring that all DNS responses contain
+   cryptographically verified data will need to separate the
+   authoritative name server and signature verification functions, since
+   name servers are not required to validate signatures of data for
+   which they are authoritative.
+
+3.  Interpretation of the AD bit
+
+   A response containing data marked Insecure in the answer or authority
+   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
+   present.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   with a recursive nameserver over a secure transport mechanism or
+   using a message authentication such as TSIG [RFC2845] or SIG(0)
+   [RFC2931] and is explicitly configured to trust this recursive name
+   server.
+
+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 an out of band mechanism such as:
+
+   -  Fiat: An organization that can dictate whether it is OK to trust
+      certain DNS servers.
+
+   -  Personal: Because of a personal relationship or the reputation of
+      a recursive nameserver operator, a DNS consumer can decide to
+      trust that recursive nameserver.
+
+   -  Knowledge: If a recursive nameserver operator posts the configured
+      policy of a recursive nameserver, a consumer can decide that
+      recursive nameserver is trustworthy.
+
+   In the absence of one or more of these factors AD bit from a
+   recursive name server SHOULD NOT be trusted.  For example, home users
+   frequently depend on their ISP to provide recursive DNS service; it
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 4]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   is not advisable to trust these recursive nameservers.  A
+   roaming/traveling host SHOULD not use recursive DNS servers offered
+   by DHCP when looking up information where security status matters.
+
+   In the latter two cases, the end consumer must also completely trust
+   the path to the trusted recursive name servers, or a secure transport
+   must be employed to protect the traffic.
+
+   When faced with a situation where there are no satisfactory recursive
+   nameservers 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.
+
+5.  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 DO 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 and
+   recursive name servers.
+
+   Resolvers (full or stub) that blindly trust the AD bit without
+   knowing the security policy of the server generating the answer can
+   not be considered security aware.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   such as IPsec, or using message authentication such as TSIG [RFC2845]
+   or SIG(0) [RFC2931].  In addition, the resolver must have been
+   explicitly configured to trust this recursive name server.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Internationalization Considerations
+
+   None.  This document does not change any textual data in any
+   protocol.
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 5]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+8.  Intellectual Property Rights Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+9.  Acknowledgments
+
+   The following people have provided input on this document: Robert
+   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
+   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
+
+10.  Normative References
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0))", RFC 2931, September 2000.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 6]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+11.  Authors' Addresses
+
+   Brian Wellington
+   Nominum Inc.
+   2385 Bay Road
+   Redwood City, CA, 94063
+   USA
+
+   EMail: Brian.Wellington@nominum.com
+
+
+   Olafur Gudmundsson
+   3821 Village Park Drive
+   Chevy Chase, MD, 20815
+   USA
+
+   EMail: ogud@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 7]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 8]
+