idnits 2.17.1 draft-laurie-dnsext-nsec2v2-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 409 has weird spacing: '... Method for...' -- 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 (October 2004) is 7127 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) == Missing Reference: 'RFC2535' is mentioned on line 101, but not defined ** Obsolete undefined reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC2308' is mentioned on line 112, but not defined -- Looks like a reference, but probably isn't: '4' on line 193 -- Looks like a reference, but probably isn't: '5' on line 227 == Missing Reference: 'RFC2525' is mentioned on line 261, but not defined == Unused Reference: 'RFC2026' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC2418' is defined on line 404, but no explicit reference was found in the text Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Laurie 2 Internet-Draft G. Sission 3 Expires: April 1, 2005 Nominet 4 October 2004 6 DNSSEC NSEC2 Owner and RDATA Format 7 draft-laurie-dnsext-nsec2v2-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 April 1, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 The DNS Security (DNSSEC) NSEC resource record (RR) is intended to be 43 used to provide authenticated denial of existence of DNS owner names 44 and types; however, it also permits any user to obtain a listing of 45 all DNS owner names in a zone. This can accomplished via successive 46 DNS queries for all NSEC RRs in that zone. 48 A complete zone file can be used either directly as a source of 49 probable e-mail addresses for spam, or indirectly as a key for 50 multiple WHOIS queries to reveal registrant data which many 51 registries (particularly in Europe) may be under strict legal 52 obligations to protect. Many registries therefore prohibit copying 53 of their zone file; however the use of NSEC RRs makes renders 54 policies unenforceable. 56 This document proposes an alternate scheme which hides owner names 57 while permitting authenticated denial of existence of non-existent 58 names. The scheme uses two new RR types: NSEC2 and EXIST. 60 Table of Contents 62 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. The NSEC2 Resource Record . . . . . . . . . . . . . . . . . . 3 64 2.1 NSEC2 RDATA Wire Format . . . . . . . . . . . . . . . . . 3 65 2.1.1 The Hash Field . . . . . . . . . . . . . . . . . . . . 3 66 2.1.2 The Iterations field . . . . . . . . . . . . . . . . . 4 67 2.1.3 The Salt field . . . . . . . . . . . . . . . . . . . . 4 68 2.1.4 The Hash of Next Domain Name Field . . . . . . . . . . 4 69 2.1.5 The list of Type Bit Map(s) Field . . . . . . . . . . 4 70 2.2 Owner Name Wire Format . . . . . . . . . . . . . . . . . . 5 71 2.3 The NSEC2 RR Presentation Format . . . . . . . . . . . . . 5 72 3. The EXIST Resource Record . . . . . . . . . . . . . . . . . . 5 73 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 6 74 4.1 Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. Complications Caused by Wildcards . . . . . . . . . . . . . . 6 76 6. Performance Considerations . . . . . . . . . . . . . . . . . . 7 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 9. Requirements notation . . . . . . . . . . . . . . . . . . . . 8 80 10. Security Considerations . . . . . . . . . . . . . . . . . . 8 81 A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 84 11.2 Informative References . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 86 Intellectual Property and Copyright Statements . . . . . . . . 11 88 1. Terminology 90 Because the owner name must be modified (by hashing), the unmodified 91 owner name is referred to as the "actual owner name" in this draft. 93 2. The NSEC2 Resource Record 95 The NSEC2 resource record lists two separate things: the SHA-1 hash 96 of the owner name of the next RRset in the canonical ordering of the 97 zone, and the set of RR types present at the NSEC2 RR's actual owner 98 name. The complete set of NSEC2 RRs in a zone both indicate which 99 RRsets exist in a zone and also form a chain of hashed owner names in 100 the zone. This information is used to provide authenticated denial 101 of existence for DNS data, as described in RFC 2535 [RFC2535], except 102 that the range covered by the returned RR will span consist of two 103 hashed owner names between which the hash of the queried record would 104 lie in canonical order. 106 The type value for the NSEC2 RR is ??. 108 The NSEC2 RR RDATA format is class independent and defined for all 109 classes. 111 The NSEC2 RR SHOULD have the same TTL value as the SOA minimum TTL 112 field. This is in the spirit of negative caching [RFC2308]. 114 2.1 NSEC2 RDATA Wire Format 116 The RDATA of the NSEC2 RR is as shown below: 118 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Hash | Iterations | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Salt | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 / Hash of Next Domain Name / 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 / List of Type Bit Map(s) / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 2.1.1 The Hash Field 132 The Hash Type field identifies the hash algorithm used to hash the 133 owner name. Currently only one value is defined, 1, for the SHA-1 134 algorithm. All other values are reserved. 136 2.1.2 The Iterations field 138 The Iterations field defines the number of times the hash has been 139 iterated. More iterations results in greater resiliency of the hash 140 value to dictionary attacks, but at a higher cost. 142 2.1.3 The Salt field 144 The salt is prepended to the value to be hashed in order to defend 145 against precalculated dictionary attacks. 147 2.1.4 The Hash of Next Domain Name Field 149 The Hash of Next Domain Name field contains the hash of the owner 150 name of the next RR in the canonical ordering of the hashed names of 151 the zone. The value of the Hash of Next Domain Name field in the 152 last NSEC2 record in the zone is the hash of the owner of the first 153 NSEC2 RR in the zone. 155 A sender MUST NOT use DNS name compression on the Next Domain Name 156 field when transmitting an NSEC2 RR. [Not sure if this is still 157 required] 159 Hashed owner names of RRsets not authoritative for the given zone 160 (such as glue records) MUST NOT be listed in the Hash of Next Domain 161 Name unless at least one authoritative RRset exists at the same owner 162 name. 164 2.1.5 The list of Type Bit Map(s) Field 166 The RR type space is split into 256 window blocks, each representing 167 the low-order 8 bits of the 16-bit RR type space. Each block that 168 has at least one active RR type is encoded using a single octet 169 window number (from 0 to 255), a single octet bitmap length (from 1 170 to 32) indicating the number of octets used for the window block's 171 bitmap, and up to 32 octets (256 bits) of bitmap. 173 Blocks are present in the NSEC2 RR RDATA in increasing numerical 174 order. 176 "|" denotes concatenation 178 Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + 180 Each bitmap encodes the low-order 8 bits of RR types within the 181 window block, in network bit order. The first bit is bit 0. For 182 window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds 183 to RR type 2 (NS), and so forth. For window block 1, bit 1 184 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 185 1, it indicates that an RRset of that type is present for the NSEC2 186 RR's owner name. If a bit is set to 0, it indicates that no RRset of 187 that type is present for the NSEC2 RR's owner name. 189 Since bit 0 in window block 0 refers to the non-existing RR type 0, 190 it MUST be set to 0. After verification, the validator MUST ignore 191 the value of bit 0 in window block 0. 193 Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] 194 (section 3.1) or within the range reserved for assignment only to 195 QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in 196 zone data. If encountered, they must be ignored upon reading. 198 Blocks with no types present MUST NOT be included. Trailing zero 199 octets in the bitmap MUST be omitted. The length of each block's 200 bitmap is determined by the type code with the largest numerical 201 value, within that block, among the set of RR types present at the 202 NSEC2 RR's actual owner name. Trailing zero octets not specified 203 MUST be interpretted as zero octets. 205 2.2 Owner Name Wire Format 207 The owner name of the NSEC2 RR will be the SHA-1 hash represented in 208 hexadecimal of the owner's full domain name instead of the name 209 itself. There is no conflict if this happens to coincide with a real 210 domain name, since these hashed names will only appear in NSEC2 RRs. 212 2.3 The NSEC2 RR Presentation Format 214 The presentation format of the RDATA portion is as follows: 216 The Hash field is presented as the name of the hash. 218 The Iterations field is presented as a decimal number. 220 The Salt field is presented as a hexadecimal number. 222 The Hash of Next Domain Name field is represented as a hexadecimal 223 number. 225 The List of Type Bit Map(s) Field is represented as a sequence of RR 226 type mnemonics. When the mnemonic is not known, the TYPE 227 representation as described in RFC 3597 [5] (section 5) MUST be used. 229 3. The EXIST Resource Record 231 In order to prove the nonexistence of a record that might be covered 232 by a wildcard, it is necessary to prove the existence of its closest 233 encloser. This record does that. Its owner is the closest encloser. 234 It has no RDATA. If there is another RR that proves the existence of 235 the closest encloser, this SHOULD be used instead of an EXIST record. 237 EXIST records SHOULD NOT be returned in response to ANY queries (but 238 note that returning them does not do any real harm, since a query for 239 a domain within the existing domain will reveal it in any case). 241 4. Calculation of the Hash 243 Define H(x) to be the hash of x using the hash function selected by 244 the NSEC2 record and || to indicate concatenation. Then define: 246 IH(salt,x,0)=H(x || salt) 248 IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0 250 Then the calculated hash of a name is IH(salt,name,iterations-1). 252 4.1 Test Vectors 254 TBD 256 5. Complications Caused by Wildcards 258 If a wildcard owner name appears in a zone, the wildcard label ("*") 259 is treated as a literal symbol and is treated in the same way as any 260 other owner name for purposes of generating NSEC2 RRs. RFC 2535 261 [RFC2525] describes the impact of wildcards on authenticated denial 262 of existence. 264 In order to prove there are no wildcards for a domain, as well as no 265 RRs that match directly, an RR must be shown for the closest 266 encloser, and nonexistence must be shown for all enclosers that could 267 be closer. If there is no other RR for the closest encloser, the 268 EXIST RR MUST be used. 270 To illustrate, suppose a.b.c.d.e. does not exist in the d.e. zone, 271 and c.d.e. is the closest encloser, the proof would consist of: 273 a) Nonexistence of a.b.c.d.e (NSEC2) 275 b) Nonexistence of b.c.d.e (NSEC2) 277 c) Existence of c.d.e (EXIST or other RR) 279 d) Nonexistence of *.c.d.e (NSEC2) 281 6. Performance Considerations 283 Iterated hashes will obviously impose a performance penalty on both 284 servers and clients. However, servers already have to do public key 285 signatures for every record, which is far more costly than an 286 iterated hash (unless impractically large values are chosen for 287 iterations). Although checking a public key signature is 288 significantly cheaper than signing, at least for RSA, individual 289 clients should not be frequently required to check nonexistence of 290 RRs, and in any case values for iterations can still be chosen to 291 make the cost small compared to the cost of the signature checking. 293 [Note: clients may want limit the number of iterations (and fail if 294 too high) to avoid apparently hanging] 296 [Example: on a Pentium using OpenSSL, at least 1000 iterations of 297 SHA-1 can be done in the time it takes to check a 2048 bit RSA 298 signature] 300 7. IANA Considerations 302 Type values for NSEC2 and EXIST will have to be assigned. Value(s) 303 for hash algorithm(s) will have to be assigned. 305 8. Security Considerations 307 The NSEC2 records are still susceptible to dictionary attacks (i.e. 308 the attacker retrieves all the NSEC2 records, then calculates the 309 hashes of all likely domain names, comparing against the hashes found 310 in the NSEC2 records, and thus enumerating the zone). These are 311 substantially more expensive than traversing the original NSEC2 312 records would have been, and in any case, such an attack could also 313 be used directly against the name server itself by performing queries 314 for all likely names. The expense of this attack can be chosen by 315 setting the iterations in the NSEC2 RR. 317 High-value domains are also susceptible to a precalculated dictionary 318 attack - that is, a list of hashes for all likely names is computed 319 once, then NSEC2 is scanned periodically and compared against the 320 precomputed hashes. This attack is prevented by changing the salt on 321 a regular basis. 323 EXIST records may leak information. If a.b.c.d.e exists and 324 f.b.c.d.e does not, then a query for f.b.c.d.e will reveal the fact 325 that b.c.d.e exists, even if there is no RR for it. In practice, 326 this rarely matters, since usually b.c.d.e will be a delegated domain 327 and hence have at least an SOA record. 329 Walking the NSEC2 RRs will reveal the total number of records in the 330 zone, and also what types they are. This could be mitigated by 331 adding dummy entries, but certainly an upper limit can always be 332 found. 334 Hash collisions may occur. If they do, it will be impossible to 335 prove the nonexistence of the colliding domain - however, this is 336 fantastically unlikely, and, in any case, DNSSEC already relies on 337 SHA-1 to not collide. 339 9. Requirements notation 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in [RFC2119]. 345 10. Security Considerations 347 Appendix A. Example Zone 349 This is a zone showing its NSEC2 records. They can also be used as 350 test vectors for the hash algorithm. RRSIG records have been elided. 352 example.com. 1000 IN SOA localhost. 353 postmaster.localhost.example.com. ( 354 1 ; serial 355 3600 ; refresh (1 hour) 356 1800 ; retry (30 minutes) 357 604800 ; expire (1 week) 358 3600 ; minimum (1 hour) 359 ) 360 1000 NS ns1.example.com. 361 1000 NS ns2.example.com. 362 f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC2 \ 363 SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ 364 NS SOA RRSIG DNSKEY NSEC2 365 a.example.com. 1000 IN A 1.2.3.4 366 1000 IN A 1.2.3.5 367 1000 TXT "An example" 368 bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC2 \ 369 SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ 370 A TXT RRSIG NSEC2 371 b.example.com. 1000 IN A 1.2.3.7 372 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC2 \ 373 SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ 374 A RRSIG NSEC2 375 a.b.c.example.com. 1000 IN A 1.2.3.6 376 a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC2 \ 377 SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ 378 A RRSIG NSEC2 379 ns1.example.com. 1000 IN A 1.2.3.8 380 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC2 \ 381 SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ 382 A RRSIG NSEC2 383 ns2.example.com. 1000 IN A 1.2.3.9 384 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC2 \ 385 SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ 386 A RRSIG NSEC2 388 11. References 390 11.1 Normative References 392 [dnssecbis-protocol] 393 "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some 394 Month 2004. 396 11.2 Informative References 398 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 399 3", BCP 9, RFC 2026, October 1996. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 405 Procedures", BCP 25, RFC 2418, September 1998. 407 [rollover] 408 Ihren, J., Kolkman, O. and B. Manning, "An In-Band 409 Rollover Algorithm and a Out-Of-Band Priming Method for 410 DNS Trust Anchors.", July 2004. 412 Authors' Addresses 414 Ben Laurie 415 Nominet 416 17 Perryn Road 417 London W3 7LR 418 England 420 Phone: +44 (20) 8735 0686 421 EMail: ben@algroup.co.uk 423 Geoffrey Sisson 424 Nominet 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Disclaimer of Validity 452 This document and the information contained herein are provided on an 453 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 454 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 455 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 456 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 457 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 458 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Copyright Statement 462 Copyright (C) The Internet Society (2004). This document is subject 463 to the rights, licenses and restrictions contained in BCP 78, and 464 except as set forth therein, the authors retain all their rights. 466 Acknowledgment 468 Funding for the RFC Editor function is currently provided by the 469 Internet Society.