idnits 2.17.1 draft-blacka-dnssec-experiments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 314. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 320. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 22, 2004) is 7058 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Blacka 2 Internet-Draft Verisign, Inc. 3 Expires: June 22, 2005 December 22, 2004 5 DNSSEC Experiments 6 draft-blacka-dnssec-experiments-00 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 22, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 In the long history of the development of the DNS security [1] 42 extensions, a number of alternate methodologies and modifications 43 have been proposed and rejected for practical, rather than strictly 44 technical, reasons. There is a desire to be able to experiment with 45 these alternate methods in the public DNS. This document describes a 46 methodology for deploying alternate, non-backwards-compatible, DNSSEC 47 methodologies in an experimental fashion without disrupting the 48 deployment of standard DNSSEC. 50 Table of Contents 52 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8 57 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9 58 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10 59 8. Security Considerations . . . . . . . . . . . . . . . . . . 11 60 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 10.1 Normative References . . . . . . . . . . . . . . . . . . . 13 63 10.2 Informative References . . . . . . . . . . . . . . . . . . 13 64 Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . 15 68 1. Definitions and Terminology 70 Throughout this document, familiarity with the DNS system (RFC 1035 71 [4]) and the DNS security extensions ([1], [2], and [3]. 73 The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [5]. 77 2. Overview 79 Historically, experimentation with DNSSEC alternatives has been a 80 problematic endeavor. There has typically been a desire to both 81 introduce non-backwards-compatible changes to DNSSEC, and to try 82 these changes on real zones in the public DNS. This creates a 83 problem when the change to DNSSEC would make all or part of the zone 84 using those changes appear bogus or otherwise broken to existing 85 DNSSEC-aware resolvers. 87 This document describes a standard methodology for setting up public 88 DNSSEC experiments. This methodology addresses the issue of 89 co-existence with standard DNSSEC and DNS by using unknown algorithm 90 identifiers to hide the experimental DNSSEC protocol modifications 91 from standard DNSSEC-aware resolvers. 93 3. Experiments 95 When discussing DNSSEC experiments, it is necessary to classify these 96 experiments into two broad categories: 98 Backwards-Compatible: describes experimental changes that, while not 99 strictly adhering to the DNSSEC standard, are nonetheless 100 interoperable with clients and server that do implement the DNSSEC 101 standard. 102 Non-Backwards-Compatible: describes experiments that would cause a 103 standard DNSSEC-aware resolver to (incorrectly) determine that all 104 or part of a zone is bogus, or to otherwise not interoperable with 105 standard DNSSEC clients and servers. 107 Not included in these terms are experiments with the core DNS 108 protocol itself. 110 The methodology described in this document is not necessary for 111 backwards-compatible experiments, although it certainly could be used 112 if desired. 114 Note that, in essence, this metholodolgy would also be used to 115 introduce a new DNSSEC algorithm, independently from any DNSSEC 116 experimental protocol change. 118 4. Method 120 The core of the methodology is the use of only "unknown" algorithms 121 to sign the experimental zone, and more importantly, having only 122 unknown algorithm DS records for the delegation to the zone at the 123 parent. 125 This technique works because of the way DNSSEC-compliant validators 126 are expected to work in the presence of a DS set with only unknown 127 algorithms. From [3], Section 5.2: 129 If the validator does not support any of the algorithms listed in 130 an authenticated DS RRset, then the resolver has no supported 131 authentication path leading from the parent to the child. The 132 resolver should treat this case as it would the case of an 133 authenticated NSEC RRset proving that no DS RRset exists, as 134 described above. 136 And further: 138 If the resolver does not support any of the algorithms listed in 139 an authenticated DS RRset, then the resolver will not be able to 140 verify the authentication path to the child zone. In this case, 141 the resolver SHOULD treat the child zone as if it were unsigned. 143 While this behavior isn't strictly mandatory (as marked by MUST), it 144 is unlikely that a validator would not implement the behavior, or, 145 more to the point, it will not violate this behavior in an unsafe way 146 (see below (Section 6).) 148 Because we are talking about experiments, it is recommended that 149 private algorithm numbers be used (see [2], appendix A.1.1 150 [Comment.1].) Normally, instead of actually inventing new signing 151 algorithms, the recommended path is to create alternate algorithm 152 identifiers that are aliases for the existing, known algorithms. 153 While, strictly speaking, it is only necessary to create an alternate 154 identifier for the mandatory algorithms (currently, this is only 155 algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined 156 algorithms as well. 158 It is RECOMMENDED that for a particular DNSSEC experiment, a 159 particular domain name base is chosen for all new algorithms, then 160 the algorithm number (or name) is prepended to it. For example, for 161 experiment A, the base name of "dnssec-experiment-a.example.com" is 162 chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are 163 defined to be "3.dnssec-experiment-a.example.com" and 164 "5.dnssec-experiment-a.example.com". However, any unique identifier 165 will suffice. 167 Using this method, resolvers (or, more specificially, DNSSEC 168 validators) essentially indicate their ability to understand the 169 DNSSEC experiment's semantics by understanding what the new algorithm 170 identifiers signify. 172 This method creates two classes of DNSSEC-aware servers and 173 resolvers: servers and resolvers that are aware of the experiment 174 (and thus recognize the experiments algorithm identifiers and 175 experimental semantics), and servers and resolvers that are unware of 176 the experiment. 178 5. Defining an Experiment 180 The DNSSEC experiment must define the particular set of (previously 181 unknown) algorithms that identify the experiment, and define what 182 each unknown algorithm identifier means. Typically, unless the 183 experiment is actually experimenting with a new DNSSEC algorithm, 184 this will be a mapping of private algorithm identifiers to existing, 185 known algorithms. 187 Typically, the experiment will choose a DNS name as the algorithm 188 identifier base. This DNS name SHOULD be under the control of the 189 authors of the experiment. Then the experiment will define a mapping 190 between known mandatory and optional algorithms into this private 191 algorithm identifier space. Alternately, the experiment MAY use the 192 OID private algorithm space instead (using algorithm number 254), or 193 may choose non-private algorithm numbers, although this would require 194 an IANA allocation (see below (Section 9).) 196 For example, an experiment might specify in its description the DNS 197 name "dnssec-experiment-a.example.com" as the base name, and provide 198 the mapping of "3.dnssec-experiment-a.example.com" is an alias of 199 DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is 200 an alias of DNSSEC algorithm 5 (RSASHA1). 202 Resolvers MUST then only recognize the experiment's semantics when 203 present in a zone signed by one or more of these private algorithms. 205 In general, however, resolvers involved in the experiment are 206 expected to understand both standard DNSSEC and the defined 207 experimental DNSSEC protocol, although this isn't, strictly speaking, 208 required. 210 6. Considerations 212 There are a number of considerations with using this methodology. 214 1. Under some circumstances, it may be that the experiment will not 215 be sufficiently masked by this technique and may cause resolution 216 problem for resolvers not aware of the experiment. For instance, 217 the resolver may look at the not validatable response and 218 conclude that the response is bogus, either due to local policy 219 or implementation details. This is not expected to be the common 220 case, however. 221 2. It will, in general, not be possible for DNSSEC-aware resolvers 222 not aware of the experiment to build a chain of trust through an 223 experimental zone. 225 7. Transitions 227 If an experiment is successful, there may be a desire to move the 228 experiment to a standards-track extension. One way to do so would be 229 to move from private algorithm numbers to IANA allocated algorithm 230 numbers, with otherwise the same meaning. This would still leave a 231 divide between resolvers that understood the extension versus 232 resolvers that did not. It would, in essence, create an additional 233 version of DNSSEC. 235 An alternate technique might be to do a typecode rollover, thus 236 actually creating a definitive new version of DNSSEC. There may be 237 other transition techniques available, as well. 239 8. Security Considerations 241 Zones using this methodology will be considered insecure by all 242 resolvers except those aware of the experiment. It is not generally 243 possible to create a secure delegation from an experimental zone that 244 will be followed by resolvers unaware of the experiment. 246 9. IANA Considerations 248 IANA may need to allocate new DNSSEC algorithm numbers if that 249 transition approach is taken, or the experiment decides to use 250 allocated numbers to begin with. No IANA action is required to 251 deploy an experiment using private algorithm identifiers. 253 10. References 255 10.1 Normative References 257 [1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, 258 "DNS Security Introduction and Requirements", 259 draft-ietf-dnsext-dnssec-intro-13 (work in progress), October 260 2004. 262 [2] Arends, R., "Resource Records for the DNS Security Extensions", 263 draft-ietf-dnsext-dnssec-records-11 (work in progress), October 264 2004. 266 [3] Arends, R., "Protocol Modifications for the DNS Security 267 Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in 268 progress), October 2004. 270 10.2 Informative References 272 [4] Mockapetris, P., "Domain names - implementation and 273 specification", STD 13, RFC 1035, November 1987. 275 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", BCP 14, RFC 2119, March 1997. 278 Editorial Comments 280 [Comment.1] Note: the DS record does not appear to be defined to 281 handle private algorithm identifiers in a way consistent 282 with DNSKEY and RRSIG, so it is possible that building 283 in support for private algorithms in a DNSSEC validator 284 is not feasible 286 Author's Address 288 David Blacka 289 Verisign, Inc. 290 21355 Ridgetop Circle 291 Dulles, VA 20166 292 US 294 Phone: +1 703 948 3200 295 EMail: davidb@verisign.com 296 URI: http://www.verisignlabs.com 298 Intellectual Property Statement 300 The IETF takes no position regarding the validity or scope of any 301 Intellectual Property Rights or other rights that might be claimed to 302 pertain to the implementation or use of the technology described in 303 this document or the extent to which any license under such rights 304 might or might not be available; nor does it represent that it has 305 made any independent effort to identify any such rights. Information 306 on the procedures with respect to rights in RFC documents can be 307 found in BCP 78 and BCP 79. 309 Copies of IPR disclosures made to the IETF Secretariat and any 310 assurances of licenses to be made available, or the result of an 311 attempt made to obtain a general license or permission for the use of 312 such proprietary rights by implementers or users of this 313 specification can be obtained from the IETF on-line IPR repository at 314 http://www.ietf.org/ipr. 316 The IETF invites any interested party to bring to its attention any 317 copyrights, patents or patent applications, or other proprietary 318 rights that may cover technology that may be required to implement 319 this standard. Please address the information to the IETF at 320 ietf-ipr@ietf.org. 322 Disclaimer of Validity 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 327 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 328 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 329 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Copyright Statement 334 Copyright (C) The Internet Society (2004). This document is subject 335 to the rights, licenses and restrictions contained in BCP 78, and 336 except as set forth therein, the authors retain all their rights. 338 Acknowledgment 340 Funding for the RFC Editor function is currently provided by the 341 Internet Society.