idnits 2.17.1 draft-ietf-dnsext-dnssec-experiments-04.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 342. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 20, 2007) is 6246 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-ietf-dnsext-dnssec-bis-updates-02 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT D. Blacka 3 Internet-Draft VeriSign, Inc. 4 Intended status: Best Current March 20, 2007 5 Practice 6 Expires: September 21, 2007 8 DNSSEC Experiments 9 draft-ietf-dnsext-dnssec-experiments-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 21, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a methodology for deploying alternate, non- 43 backwards-compatible, DNSSEC methodologies in an experimental fashion 44 without disrupting the deployment of standard DNSSEC. 46 Table of Contents 48 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 49 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8 53 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 54 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 56 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 59 10.2. Informative References . . . . . . . . . . . . . . . . . 13 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 Intellectual Property and Copyright Statements . . . . . . . . . . 15 63 1. Definitions and Terminology 65 Throughout this document, familiarity with the DNS system (RFC 1035 66 [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and 67 RFC 4035 [4]) is assumed. 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [1]. 73 2. Overview 75 Historically, experimentation with DNSSEC alternatives has been a 76 problematic endeavor. There has typically been a desire to both 77 introduce non-backwards-compatible changes to DNSSEC and to try these 78 changes on real zones in the public DNS. This creates a problem when 79 the change to DNSSEC would make all or part of the zone using those 80 changes appear bogus (bad) or otherwise broken to existing security- 81 aware resolvers. 83 This document describes a standard methodology for setting up DNSSEC 84 experiments. This methodology addresses the issue of co-existence 85 with standard DNSSEC and DNS by using unknown algorithm identifiers 86 to hide the experimental DNSSEC protocol modifications from standard 87 security-aware resolvers. 89 3. Experiments 91 When discussing DNSSEC experiments, it is necessary to classify these 92 experiments into two broad categories: 94 Backwards-Compatible: describes experimental changes that, while not 95 strictly adhering to the DNSSEC standard, are nonetheless 96 interoperable with clients and servers that do implement the 97 DNSSEC standard. 99 Non-Backwards-Compatible: describes experiments that would cause a 100 standard security-aware resolver to (incorrectly) determine that 101 all or part of a zone is bogus, or to otherwise not interoperate 102 with standard DNSSEC clients and servers. 104 Not included in these terms are experiments with the core DNS 105 protocol itself. 107 The methodology described in this document is not necessary for 108 backwards-compatible experiments, although it certainly may be used 109 if desired. 111 4. Method 113 The core of the methodology is the use of strictly unknown algorithm 114 identifiers when signing the experimental zone, and more importantly, 115 having only unknown algorithm identifiers in the DS records for the 116 delegation to the zone at the parent. 118 This technique works because of the way DNSSEC-compliant validators 119 are expected to work in the presence of a DS set with only unknown 120 algorithm identifiers. From RFC 4035 [4], Section 5.2: 122 If the validator does not support any of the algorithms listed in 123 an authenticated DS RRset, then the resolver has no supported 124 authentication path leading from the parent to the child. The 125 resolver should treat this case as it would the case of an 126 authenticated NSEC RRset proving that no DS RRset exists, as 127 described above. 129 And further: 131 If the resolver does not support any of the algorithms listed in 132 an authenticated DS RRset, then the resolver will not be able to 133 verify the authentication path to the child zone. In this case, 134 the resolver SHOULD treat the child zone as if it were unsigned. 136 Although this behavior isn't strictly mandatory (as marked by MUST), 137 it is unlikely for a validator to implement a substantially different 138 behavior. Essentially, if the validator does not have a usable chain 139 of trust to a child zone, then it can only do one of two things: 140 treat responses from the zone as insecure (the recommended behavior), 141 or treat the responses as bogus. If the validator chooses the 142 latter, this will both violate the expectation of the zone owner and 143 defeat the purpose of the above rule. However, with local policy, it 144 is within the right of a validator to refuse to trust certain zones 145 based on any criteria, including the use of unknown signing 146 algorithms. 148 Because we are talking about experiments, it is RECOMMENDED that 149 private algorithm numbers be used (see RFC 4034 [3], appendix A.1.1. 150 Note that secure handling of private algorithms requires special 151 handing by the validator logic. See draft-ietf-dnssec-bis-updates 152 [6] for further details.) Normally, instead of actually inventing 153 new signing algorithms, the recommended path is to create alternate 154 algorithm identifiers that are aliases for the existing, known 155 algorithms. While, strictly speaking, it is only necessary to create 156 an alternate identifier for the mandatory algorithms, it is suggested 157 that all optional defined algorithms be aliased as well. 159 It is RECOMMENDED that for a particular DNSSEC experiment, a 160 particular domain name base is chosen for all new algorithms, then 161 the algorithm number (or name) is prepended to it. For example, for 162 experiment A, the base name of "dnssec-experiment-a.example.com" is 163 chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are 164 defined to be "3.dnssec-experiment-a.example.com" and 165 "5.dnssec-experiment-a.example.com". However, any unique identifier 166 will suffice. 168 Using this method, resolvers (or, more specifically, DNSSEC 169 validators) essentially indicate their ability to understand the 170 DNSSEC experiment's semantics by understanding what the new algorithm 171 identifiers signify. 173 This method creates two classes of security-aware servers and 174 resolvers: servers and resolvers that are aware of the experiment 175 (and thus recognize the experiment's algorithm identifiers and 176 experimental semantics), and servers and resolvers that are unaware 177 of the experiment. 179 This method also precludes any zone from being both in an experiment 180 and in a classic DNSSEC island of security. That is, a zone is 181 either in an experiment and only possible to validate experimentally, 182 or it is not. 184 5. Defining an Experiment 186 The DNSSEC experiment MUST define the particular set of (previously 187 unknown) algorithm identifiers that identify the experiment, and 188 define what each unknown algorithm identifier means. Typically, 189 unless the experiment is actually experimenting with a new DNSSEC 190 algorithm, this will be a mapping of private algorithm identifiers to 191 existing, known algorithms. 193 Normally the experiment will choose a DNS name as the algorithm 194 identifier base. This DNS name SHOULD be under the control of the 195 authors of the experiment. Then the experiment will define a mapping 196 between known mandatory and optional algorithms into this private 197 algorithm identifier space. Alternately, the experiment MAY use the 198 OID private algorithm space instead (using algorithm number 254), or 199 MAY choose non-private algorithm numbers, although this would require 200 an IANA allocation. 202 For example, an experiment might specify in its description the DNS 203 name "dnssec-experiment-a.example.com" as the base name, and declare 204 that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC 205 algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an 206 alias of DNSSEC algorithm 5 (RSASHA1). 208 Resolvers MUST only recognize the experiment's semantics when present 209 in a zone signed by one or more of these algorithm identifiers. This 210 is necessary to isolate the semantics of one experiment from any 211 others that the resolver might understand. 213 In general, resolvers involved in the experiment are expected to 214 understand both standard DNSSEC and the defined experimental DNSSEC 215 protocol, although this isn't required. 217 6. Considerations 219 There are a number of considerations with using this methodology. 221 1. If an unaware validator does not correctly follow the rules laid 222 out in RFC 4035 (e.g., the validator interprets a DNSSEC record 223 prior to validating it), or if the experiment is broader in scope 224 that just modifying the DNSSEC semantics, the experiment may not 225 be sufficiently masked by this technique. This may cause 226 unintended resolution failures. 228 2. It will not be possible for security-aware resolvers unaware of 229 the experiment to build a chain of trust through an experimental 230 zone. 232 7. Use in Non-Experiments 234 This general methodology MAY be used for non-backwards compatible 235 DNSSEC protocol changes that start out as or become standards. In 236 this case: 238 o The protocol change SHOULD use public IANA allocated algorithm 239 identifiers instead of private algorithm identifiers. This will 240 help identify the protocol change as a standard, rather than an 241 experiment. 243 o Resolvers MAY recognize the protocol change in zones not signed 244 (or not solely signed) using the new algorithm identifiers. 246 8. Security Considerations 248 Zones using this methodology will be considered insecure by all 249 resolvers except those aware of the experiment. It is not generally 250 possible to create a secure delegation from an experimental zone that 251 will be followed by resolvers unaware of the experiment. 253 Implementers should take into account any security issues that may 254 result from environments being configured to trust both experimental 255 and non-experimental zones. If the experimental zone is more 256 vulnerable to attacks, it could, for example, be used promote trust 257 in zones not part of the experiment, possibly under the control of an 258 attacker. 260 9. IANA Considerations 262 This document has no IANA actions. 264 10. References 266 10.1. Normative References 268 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 269 Levels", BCP 14, RFC 2119, March 1997. 271 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 272 "DNS Security Introduction and Requirements", RFC 4033, 273 March 2005. 275 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 276 "Resource Records for the DNS Security Extensions", RFC 4034, 277 March 2005. 279 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 280 "Protocol Modifications for the DNS Security Extensions", 281 RFC 4035, March 2005. 283 10.2. Informative References 285 [5] Mockapetris, P., "Domain names - implementation and 286 specification", STD 13, RFC 1035, November 1987. 288 [6] Austein, R. and S. Weiler, "Clarifications and Implementation 289 Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02 290 (work in progress), January 2006. 292 Author's Address 294 David Blacka 295 VeriSign, Inc. 296 21355 Ridgetop Circle 297 Dulles, VA 20166 298 US 300 Phone: +1 703 948 3200 301 Email: davidb@verisign.com 302 URI: http://www.verisignlabs.com 304 Full Copyright Statement 306 Copyright (C) The IETF Trust (2007). 308 This document is subject to the rights, licenses and restrictions 309 contained in BCP 78, and except as set forth therein, the authors 310 retain all their rights. 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 315 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 316 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 317 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 320 Intellectual Property 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 found in BCP 78 and BCP 79. 331 Copies of IPR disclosures made to the IETF Secretariat and any 332 assurances of licenses to be made available, or the result of an 333 attempt made to obtain a general license or permission for the use of 334 such proprietary rights by implementers or users of this 335 specification can be obtained from the IETF on-line IPR repository at 336 http://www.ietf.org/ipr. 338 The IETF invites any interested party to bring to its attention any 339 copyrights, patents or patent applications, or other proprietary 340 rights that may cover technology that may be required to implement 341 this standard. Please address the information to the IETF at 342 ietf-ipr@ietf.org. 344 Acknowledgment 346 Funding for the RFC Editor function is provided by the IETF 347 Administrative Support Activity (IASA).