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