idnits 2.17.1 draft-ietf-dnsext-dnssec-online-signing-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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. ** 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. 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 draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4034, updated by this document, for RFC5378 checks: 2002-02-26) -- 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 (May 12, 2005) is 6921 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) -- Looks like a reference, but probably isn't: '-bis' on line 276 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft SPARTA, Inc 4 Updates: 4034, 4035 (if approved) J. Ihren 5 Expires: November 13, 2005 Autonomica AB 6 May 12, 2005 8 Minimally Covering NSEC Records and DNSSEC On-line Signing 9 draft-ietf-dnsext-dnssec-online-signing-00 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 November 13, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes how to construct DNSSEC NSEC resource records 43 that cover a smaller range of names than called for by RFC4034. By 44 generating and signing these records on demand, authoritative name 45 servers can effectively stop the disclosure of zone contents 46 otherwise made possible by walking the chain of NSEC records in a 47 signed zone. 49 Changes from weiler-01 to ietf-00 51 Inserted RFC numbers for 4033, 4034, and 4035. 53 Specified contents of bitmap field in synthesized NSEC RR's, pointing 54 out that this relaxes a constraint in 4035. Added 4035 to the 55 Updates header. 57 Changes from weiler-00 to weiler-01 59 Clarified that this updates RFC4034 by relaxing requirements on the 60 next name field. 62 Added examples covering wildcard names. 64 In the 'better functions' section, reiterated that perfect functions 65 aren't needed. 67 Added a reference to RFC 2119. 69 Table of Contents 71 1. Introduction and Terminology . . . . . . . . . . . . . . . . 4 72 2. Minimally Covering NSEC Records . . . . . . . . . . . . . . 4 73 3. Better Increment & Decrement Functions . . . . . . . . . . . 6 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 75 5. Security Considerations . . . . . . . . . . . . . . . . . . 7 76 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 78 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 79 Intellectual Property and Copyright Statements . . . . . . . 10 81 1. Introduction and Terminology 83 With DNSSEC [1], an NSEC record lists the next instantiated name in 84 its zone, proving that no names exist in the "span" between the 85 NSEC's owner name and the name in the "next name" field. In this 86 document, an NSEC record is said to "cover" the names between its 87 owner name and next name. 89 Through repeated queries that return NSEC records, it is possible to 90 retrieve all of the names in the zone, a process commonly called 91 "walking" the zone. Some zone owners have policies forbidding zone 92 transfers by arbitrary clients; this side-effect of the NSEC 93 architecture subverts those policies. 95 This document presents a way to prevent zone walking by constructing 96 NSEC records that cover fewer names. These records can make zone 97 walking take approximately as many queries as simply asking for all 98 possible names in a zone, making zone walking impractical. Some of 99 these records must be created and signed on demand, which requires 100 on-line private keys. Anyone contemplating use of this technique is 101 strongly encouraged to review the discussion of the risks of on-line 102 signing in Section 5. 104 The technique presented here may be useful to a zone owner that wants 105 to use DNSSEC, is concerned about exposure of its zone contents via 106 zone walking, and is willing to bear the costs of on-line signing. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [4]. 112 2. Minimally Covering NSEC Records 114 This mechanism involves changes to NSEC records for instantiated 115 names, which can still be generated and signed in advance, as well as 116 the on-demand generation and signing of new NSEC records whenever a 117 name must be proven not to exist. 119 In the 'next name' field of instantiated names' NSEC records, rather 120 than list the next instantiated name in the zone, list any name that 121 falls lexically after the NSEC's owner name and before the next 122 instantiated name in the zone, according to the ordering function in 123 RFC4034 [2] section 6.2. This relaxes the requirement in section 124 4.1.1 of RFC4034 that the 'next name' field contains the next owner 125 name in the zone. This change is expected to be fully compatible 126 with all existing DNSSEC validators. These NSEC records are returned 127 whenever proving something specifically about the owner name (e.g. 128 that no resource records of a given type appear at that name). 130 Whenever an NSEC record is needed to prove the non-existence of a 131 name, a new NSEC record is dynamically produced and signed. The new 132 NSEC record has an owner name lexically before the QNAME but 133 lexically following any existing name and a 'next name' lexically 134 following the QNAME but before any existing name. 136 The generated NSEC record's type bitmap SHOULD have the RRSIG and 137 NSEC bits set and SHOULD NOT have any other bits set. This relaxes 138 the requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at 139 names that did not exist before the zone wsa signed. 141 The functions to generate the lexically following and proceeding 142 names need not be perfect nor consistent, but the generated NSEC 143 records must not cover any existing names. Furthermore, this 144 technique works best when the generated NSEC records cover as few 145 names as possible. 147 An NSEC record denying the existence of a wildcard may be generated 148 in the same way. Since the NSEC record covering a non-existent 149 wildcard is likely to be used in response to many queries, 150 authoritative name servers using the techniques described here may 151 want to pregenerate or cache that record and its corresponding RRSIG. 153 For example, a query for an A record at the non-instantiated name 154 example.com might produce the following two NSEC records, the first 155 denying the existence of the name example.com and the second denying 156 the existence of a wildcard: 158 exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC ) 160 ).com 3600 IN NSEC +.com ( RRSIG NSEC ) 162 Before answering a query with these records, an authoritative server 163 must test for the existence of names between these endpoints. If the 164 generated NSEC would cover existing names (e.g. exampldd.com or 165 *bizarre.example.com), a better increment or decrement function may 166 be used or the covered name closest to the QNAME could be used as the 167 NSEC owner name or next name, as appropriate. If an existing name is 168 used as the NSEC owner name, that name's real NSEC record MUST be 169 returned. Using the same example, assuming an exampldd.com 170 delegation exists, this record might be returned from the parent: 172 exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC ) 174 Like every authoritative record in the zone, each generated NSEC 175 record MUST have corresponding RRSIGs generated using each algorithm 176 (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as 177 described in RFC4035 [3] section 2.2. To minimize the number of 178 signatures that must be generated, a zone may wish to limit the 179 number of algorithms in its DNSKEY RRset. 181 3. Better Increment & Decrement Functions 183 Section 6.2 of RFC4034 defines a strict ordering of DNS names. 184 Working backwards from that definition, it should be possible to 185 define increment and decrement functions that generate the 186 immediately following and preceding names, respectively. This 187 document does not define such functions. Instead, this section 188 presents functions that come reasonably close to the perfect ones. 189 As described above, an authoritative server should still ensure than 190 no generated NSEC covers any existing name. 192 To increment a name, add a leading label with a single null (zero- 193 value) octet. 195 To decrement a name, decrement the last character of the leftmost 196 label, then fill that label to a length of 63 octets with octets of 197 value 255. To decrement a null (zero-value) octet, remove the octet 198 -- if an empty label is left, remove the label. Defining this 199 function numerically: fill the left-most label to its maximum length 200 with zeros (numeric, not ASCII zeros) and subtract one. 202 In response to a query for the non-existent name foo.example.com, 203 these functions produce NSEC records of: 205 fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255 206 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 207 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 208 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 209 \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG ) 211 )\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 212 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 213 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 214 \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255 215 \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG ) 217 The first of these NSEC RRs proves that no exact match for 218 foo.example.com exists, and the second proves that there is no 219 wildcard in example.com. 221 Both of these functions are imperfect: they don't take into account 222 constraints on number of labels in a name nor total length of a name. 223 As noted in the previous section, though, this technique does not 224 depend on the use of perfect increment or decrement functions: it is 225 sufficient to test whether any instantiated names fall into the span 226 covered by the generated NSEC and, if so, substitute those 227 instantiated owner names for the NSEC owner name or next name, as 228 appropriate. 230 4. IANA Considerations 232 Per RFC4041, IANA should think carefully about the protection of 233 their immortal souls. 235 5. Security Considerations 237 This approach requires on-demand generation of RRSIG records. This 238 creates several new vulnerabilities. 240 First, on-demand signing requires that a zone's authoritative servers 241 have access to its private keys. Storing private keys on well-known 242 internet-accessible servers may make them more vulnerable to 243 unintended disclosure. 245 Second, since generation of public key signatures tends to be 246 computationally demanding, the requirement for on-demand signing 247 makes authoritative servers vulnerable to a denial of service attack. 249 Lastly, if the increment and decrement functions are predictable, on- 250 demand signing may enable a chosen-plaintext attack on a zone's 251 private keys. Zones using this approach should attempt to use 252 cryptographic algorithms that are resistant to chosen-plaintext 253 attacks. It's worth noting that while DNSSEC has a "mandatory to 254 implement" algorithm, that is a requirement on resolvers and 255 validators -- there is no requirement that a zone be signed with any 256 given algorithm. 258 The success of using minimally covering NSEC record to prevent zone 259 walking depends greatly on the quality of the increment and decrement 260 functions chosen. An increment function that chooses a name 261 obviously derived from the next instantiated name may be easily 262 reverse engineered, destroying the value of this technique. An 263 increment function that always returns a name close to the next 264 instantiated name is likewise a poor choice. Good choices of 265 increment and decrement functions are the ones that produce the 266 immediately following and preceding names, respectively, though zone 267 administrators may wish to use less perfect functions that return 268 more human-friendly names than the functions described in Section 3 269 above. 271 Another obvious but misguided concern is the danger from synthesized 272 NSEC records being replayed. It's possible for an attacker to replay 273 an old but still validly signed NSEC record after a new name has been 274 added in the span covered by that NSEC, incorrectly proving that 275 there is no record at that name. This danger exists with DNSSEC as 276 defined in [-bis]. The techniques described here actually decrease 277 the danger, since the span covered by any NSEC record is smaller than 278 before. Choosing better increment and decrement functions will 279 further reduce this danger. 281 6. Normative References 283 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 284 "DNS Security Introduction and Requirements", RFC 4033, 285 March 2005. 287 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 288 "Resource Records for the DNS Security Extensions", RFC 4034, 289 March 2005. 291 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 292 "Protocol Modifications for the DNS Security Extensions", 293 RFC 4035, March 2005. 295 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 296 Levels", BCP 14, RFC 2119, March 1997. 298 Authors' Addresses 300 Samuel Weiler 301 SPARTA, Inc 302 7075 Samuel Morse Drive 303 Columbia, Maryland 21046 304 US 306 Email: weiler@tislabs.com 308 Johan Ihren 309 Autonomica AB 310 Bellmansgatan 30 311 Stockholm SE-118 47 312 Sweden 314 Email: johani@autonomica.se 316 Appendix A. Acknowledgments 318 Many individuals contributed to this design. They include, in 319 addition to the authors of this document, Olaf Kolkman, Ed Lewis, 320 Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis, 321 Jakob Schlyter, Bill Manning, and Joao Damas. 323 The key innovation of this document, namely that perfect increment 324 and decrement functions are not necessary, arose during a discussion 325 among the above-listed people at the RIPE49 meeting in September 326 2004. 328 Intellectual Property Statement 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org. 352 Disclaimer of Validity 354 This document and the information contained herein are provided on an 355 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 356 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 357 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 358 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 359 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 360 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 Copyright Statement 364 Copyright (C) The Internet Society (2005). This document is subject 365 to the rights, licenses and restrictions contained in BCP 78, and 366 except as set forth therein, the authors retain all their rights. 368 Acknowledgment 370 Funding for the RFC Editor function is currently provided by the 371 Internet Society.