diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt | 784 |
1 files changed, 0 insertions, 784 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt deleted file mode 100644 index ee03583..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt +++ /dev/null @@ -1,784 +0,0 @@ - - - -DNSEXT D. Blacka -Internet-Draft Verisign, Inc. -Expires: January 19, 2006 July 18, 2005 - - - DNSSEC Experiments - draft-ietf-dnsext-dnssec-experiments-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 19, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2005). - -Abstract - - In the long history of the development of the DNS security extensions - [1] (DNSSEC), a number of alternate methodologies and modifications - have been proposed and rejected for practical, rather than strictly - technical, reasons. There is a desire to be able to experiment with - these alternate methods in the public DNS. This document describes a - methodology for deploying alternate, non-backwards-compatible, DNSSEC - methodologies in an experimental fashion without disrupting the - deployment of standard DNSSEC. - - - - -Blacka Expires January 19, 2006 [Page 1] - -Internet-Draft DNSSEC Experiments July 2005 - - -Table of Contents - - 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 - 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 - 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 10.1 Normative References . . . . . . . . . . . . . . . . . . 13 - 10.2 Informative References . . . . . . . . . . . . . . . . . 13 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 - Intellectual Property and Copyright Statements . . . . . . . 14 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 2] - -Internet-Draft DNSSEC Experiments July 2005 - - -1. Definitions and Terminology - - Throughout this document, familiarity with the DNS system (RFC 1035 - [4]) and the DNS security extensions ([1], [2], and [3]. - - 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 [5]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 3] - -Internet-Draft DNSSEC Experiments July 2005 - - -2. 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 DNSSEC-aware resolvers. - - This document describes a standard methodology for setting up public - DNSSEC experiments. This methodology addresses the issue of co- - existence with standard DNSSEC and DNS by using unknown algorithm - identifiers to hide the experimental DNSSEC protocol modifications - from standard DNSSEC-aware resolvers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 4] - -Internet-Draft DNSSEC Experiments July 2005 - - -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 server that do implement the DNSSEC - standard. - - Non-Backwards-Compatible: describes experiments that would cause a - standard DNSSEC-aware resolver to (incorrectly) determine that all - or part of a zone is bogus, or to otherwise not interoperable 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 could be used - if desired. - - Note that, in essence, this metholodolgy would also be used to - introduce a new DNSSEC algorithm, independently from any DNSSEC - experimental protocol change. - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 5] - -Internet-Draft DNSSEC Experiments July 2005 - - -4. Method - - The core of the methodology is the use of strictly "unknown" - algorithms to sign the experimental zone, and more importantly, - having only unknown algorithm 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 - algorithms. From [3], 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. - - While this behavior isn't strictly mandatory (as marked by MUST), it - is unlikely that a validator would not implement the behavior, or, - more to the point, it will not violate this behavior in an unsafe way - (see below (Section 6).) - - Because we are talking about experiments, it is RECOMMENDED that - private algorithm numbers be used (see [2], appendix A.1.1. Note - that secure handling of private algorithms requires special handing - by the validator logic. See [6] for futher 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 RECOMMENDED that all OPTIONAL defined algorithms be - aliased as well. - - 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 - - - -Blacka Expires January 19, 2006 [Page 6] - -Internet-Draft DNSSEC Experiments July 2005 - - - suffice. - - Using this method, resolvers (or, more specificially, 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 DNSSEC-aware servers and - resolvers: servers and resolvers that are aware of the experiment - (and thus recognize the experiments algorithm identifiers and - experimental semantics), and servers and resolvers that are unware 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 experimentally validatable, or it - isn't. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 7] - -Internet-Draft DNSSEC Experiments July 2005 - - -5. Defining an Experiment - - The DNSSEC experiment must define the particular set of (previously - unknown) algorithms 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 - OID private algorithm space instead (using algorithm number 254), or - may choose non-private algorithm numbers, although this would require - an IANA allocation (see below (Section 9).) - - For example, an experiment might specify in its description the DNS - name "dnssec-experiment-a.example.com" as the base name, and provide - the mapping of "3.dnssec-experiment-a.example.com" is an alias of - DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is - an alias of DNSSEC algorithm 5 (RSASHA1). - - Resolvers MUST then only recognize the experiment's semantics when - present in a zone signed by one or more of these private algorithms. - - In general, however, resolvers involved in the experiment are - expected to understand both standard DNSSEC and the defined - experimental DNSSEC protocol, although this isn't required. - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 8] - -Internet-Draft DNSSEC Experiments July 2005 - - -6. Considerations - - There are a number of considerations with using this methodology. - - 1. Under some circumstances, it may be that the experiment will not - be sufficiently masked by this technique and may cause resolution - problem for resolvers not aware of the experiment. For instance, - the resolver may look at the not validatable response and - conclude that the response is bogus, either due to local policy - or implementation details. This is not expected to be the common - case, however. - - 2. In general, it will not be possible for DNSSEC-aware resolvers - not aware of the experiment to build a chain of trust through an - experimental zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 9] - -Internet-Draft DNSSEC Experiments July 2005 - - -7. Transitions - - If an experiment is successful, there may be a desire to move the - experiment to a standards-track extension. One way to do so would be - to move from private algorithm numbers to IANA allocated algorithm - numbers, with otherwise the same meaning. This would still leave a - divide between resolvers that understood the extension versus - resolvers that did not. It would, in essence, create an additional - version of DNSSEC. - - An alternate technique might be to do a typecode rollover, thus - actually creating a definitive new version of DNSSEC. There may be - other transition techniques available, as well. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 10] - -Internet-Draft DNSSEC Experiments July 2005 - - -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 11] - -Internet-Draft DNSSEC Experiments July 2005 - - -9. IANA Considerations - - IANA may need to allocate new DNSSEC algorithm numbers if that - transition approach is taken, or the experiment decides to use - allocated numbers to begin with. No IANA action is required to - deploy an experiment using private algorithm identifiers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Blacka Expires January 19, 2006 [Page 12] - -Internet-Draft DNSSEC Experiments July 2005 - - -10. References - -10.1 Normative References - - [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "DNS Security Introduction and Requirements", RFC 4033, - March 2005. - - [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Resource Records for the DNS Security Extensions", RFC 4034, - March 2005. - - [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, - "Protocol Modifications for the DNS Security Extensions", - RFC 4035, March 2005. - -10.2 Informative References - - [4] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [6] Weiler, S., "Clarifications and Implementation Notes for - DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in - progress), March 2005. - - -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 Expires January 19, 2006 [Page 13] - -Internet-Draft DNSSEC Experiments July 2005 - - -Intellectual Property Statement - - 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. - - -Disclaimer of Validity - - 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 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. - - -Copyright Statement - - Copyright (C) The Internet Society (2005). 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. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Blacka Expires January 19, 2006 [Page 14] - |
