summaryrefslogtreecommitdiffstats
path: root/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt')
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt840
1 files changed, 840 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
new file mode 100644
index 0000000..c8db709
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-03.txt
@@ -0,0 +1,840 @@
+
+
+
+DNSEXT D. Blacka
+Internet-Draft VeriSign, Inc.
+Intended status: Standards Track April 7, 2006
+Expires: October 9, 2006
+
+
+ DNSSEC Experiments
+ draft-ietf-dnsext-dnssec-experiments-03
+
+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 October 9, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 1]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+Abstract
+
+ This document describes a methodology for deploying alternate, non-
+ backwards-compatible, DNSSEC methodologies in an experimental fashion
+ without disrupting the deployment of standard DNSSEC.
+
+
+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. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 2]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+1. Definitions and Terminology
+
+ Throughout this document, familiarity with the DNS system (RFC 1035
+ [5]) and the DNS security extensions ([2], [3], and [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].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 3]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 security-
+ aware resolvers.
+
+ This document describes a standard methodology for setting up 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
+ security-aware resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 4]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 Expires October 9, 2006 [Page 5]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 [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.
+
+ While this behavior isn't strictly mandatory (as marked by MUST), it
+ is likely that a validator would implement this behavior, or, more to
+ the point, it would handle this situation in a safe way (see below
+ (Section 6).)
+
+ Because we are talking about experiments, it is RECOMMENDED that
+ private algorithm numbers be used (see [3], appendix A.1.1. Note
+ that secure handling of private algorithms requires special handing
+ by the validator logic. See [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.
+
+ 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
+
+
+
+Blacka Expires October 9, 2006 [Page 6]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+ 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 experimentally validatable, or it is
+ not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 7]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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
+ 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).
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 8]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 a non-validatable response and conclude
+ that the response is bogus, either due to local policy or
+ implementation details. This is not expected to be a common
+ case, however.
+
+ 2. It will not be possible for security-aware resolvers unaware of
+ the experiment to build a chain of trust through an experimental
+ zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 9]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 10]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 October 9, 2006 [Page 11]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+9. IANA Considerations
+
+ This document has no IANA actions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 12]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+10. References
+
+10.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.
+
+10.2. Informative References
+
+ [5] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [6] Austein, R. and S. Weiler, "Clarifications and Implementation
+ Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
+ (work in progress), January 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 13]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+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 October 9, 2006 [Page 14]
+
+Internet-Draft DNSSEC Experiments April 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ 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 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.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Blacka Expires October 9, 2006 [Page 15]
+
generated by cgit (git 2.34.1) at 2024-05-04 13:52:09 +0000