summaryrefslogtreecommitdiffstats
path: root/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt')
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt784
1 files changed, 784 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
new file mode 100644
index 0000000..ee03583
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
@@ -0,0 +1,784 @@
+
+
+
+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]
+
OpenPOWER on IntegriCloud