diff options
Diffstat (limited to 'doc/rfc/rfc4955.txt')
| -rw-r--r-- | doc/rfc/rfc4955.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt new file mode 100644 index 0000000..2d2eb84 --- /dev/null +++ b/doc/rfc/rfc4955.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group D. Blacka +Request for Comments: 4955 VeriSign, Inc. +Category: Standards Track July 2007 + + + DNS Security (DNSSEC) Experiments + +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 IETF Trust (2007). + +Abstract + + This document describes a methodology for deploying alternate, non- + backwards-compatible, DNS Security (DNSSEC) methodologies in an + experimental fashion without disrupting the deployment of standard + DNSSEC. + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + +Blacka Standards Track [Page 1] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +1. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC and to try these + changes on real zones in the public DNS. This creates a problem when + the change to DNSSEC would make all or part of the zone using those + changes appear bogus (bad) or otherwise broken to existing security- + aware resolvers. + + This document describes a standard methodology for setting up DNSSEC + experiments. This methodology addresses the issue of coexistence + with standard DNSSEC and DNS by using unknown algorithm identifiers + to hide the experimental DNSSEC protocol modifications from standard + security-aware resolvers. + +2. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and + RFC 4035 [4]) is assumed. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and servers that do implement the + DNSSEC standard. + + Non-Backwards-Compatible: describes experiments that would cause a + standard security-aware resolver to (incorrectly) determine that + all or part of a zone is bogus, or to otherwise not interoperate + with standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly may be used + if desired. + + + + +Blacka Standards Track [Page 2] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +4. Method + + The core of the methodology is the use of strictly unknown algorithm + identifiers when signing the experimental zone, and more importantly, + having only unknown algorithm identifiers in the DS records for the + delegation to the zone at the parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithm identifiers. From RFC 4035 [4], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + Although this behavior isn't strictly mandatory (as marked by MUST), + it is unlikely for a validator to implement a substantially different + behavior. Essentially, if the validator does not have a usable chain + of trust to a child zone, then it can only do one of two things: + treat responses from the zone as insecure (the recommended behavior), + or treat the responses as bogus. If the validator chooses the + latter, this will both violate the expectation of the zone owner and + defeat the purpose of the above rule. However, with local policy, it + is within the right of a validator to refuse to trust certain zones + based on any criteria, including the use of unknown signing + algorithms. + + Because we are talking about experiments, it is RECOMMENDED that + private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. + Note that secure handling of private algorithms requires special + handing by the validator logic. See "Clarifications and + Implementation Notes for DNSSECbis" [6] for further details.) + Normally, instead of actually inventing new signing algorithms, the + recommended path is to create alternate algorithm identifiers that + are aliases for the existing, known algorithms. While, strictly + speaking, it is only necessary to create an alternate identifier for + the mandatory algorithms, it is suggested that all optional defined + algorithms be aliased as well. + + + +Blacka Standards Track [Page 3] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + will suffice. + + Using this method, resolvers (or, more specifically, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of security-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiment's algorithm identifiers and + experimental semantics), and servers and resolvers that are unaware + of the experiment. + + This method also precludes any zone from being both in an experiment + and in a classic DNSSEC island of security. That is, a zone is + either in an experiment and only possible to validate experimentally, + or it is not. + +5. Defining an Experiment + + The DNSSEC experiment MUST define the particular set of (previously + unknown) algorithm identifiers that identify the experiment and + define what each unknown algorithm identifier means. Typically, + unless the experiment is actually experimenting with a new DNSSEC + algorithm, this will be a mapping of private algorithm identifiers to + existing, known algorithms. + + Normally the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + Object Identifier (OID) private algorithm space instead (using + algorithm number 254), or MAY choose non-private algorithm numbers, + although this would require an IANA allocation. + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and declare + that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC + algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an + alias of DNSSEC algorithm 5 (RSASHA1). + + + +Blacka Standards Track [Page 4] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + Resolvers MUST only recognize the experiment's semantics when present + in a zone signed by one or more of these algorithm identifiers. This + is necessary to isolate the semantics of one experiment from any + others that the resolver might understand. + + In general, resolvers involved in the experiment are expected to + understand both standard DNSSEC and the defined experimental DNSSEC + protocol, although this isn't required. + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. If an unaware validator does not correctly follow the rules laid + out in RFC 4035 (e.g., the validator interprets a DNSSEC record + prior to validating it), or if the experiment is broader in scope + that just modifying the DNSSEC semantics, the experiment may not + be sufficiently masked by this technique. This may cause + unintended resolution failures. + + 2. It will not be possible for security-aware resolvers unaware of + the experiment to build a chain of trust through an experimental + zone. + +7. Use in Non-Experiments + + This general methodology MAY be used for non-backwards compatible + DNSSEC protocol changes that start out as or become standards. In + this case: + + o The protocol change SHOULD use public IANA allocated algorithm + identifiers instead of private algorithm identifiers. This will + help identify the protocol change as a standard, rather than an + experiment. + + o Resolvers MAY recognize the protocol change in zones not signed + (or not solely signed) using the new algorithm identifiers. + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + Implementers should take into account any security issues that may + result from environments being configured to trust both experimental + and non-experimental zones. If the experimental zone is more + + + +Blacka Standards Track [Page 5] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + vulnerable to attacks, it could, for example, be used to promote + trust in zones not part of the experiment, possibly under the control + of an attacker. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +9.2. Informative References + + [5] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [6] Weiler, S. and R. Austein, "Clarifications and Implementation + Notes for DNSSECbis", Work in Progress, March 2007. + +Author's Address + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + +Blacka Standards Track [Page 6] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Blacka Standards Track [Page 7] + |