idnits 2.17.1 draft-ietf-dnsext-not-existing-rr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 18 instances of lines with control characters in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 170: '... The list MUST be sorted in RR type ...' RFC 2119 keyword, line 191: '...O RRs for a zone SHOULD be automatical...' RFC 2119 keyword, line 192: '...ed. The NO RR's TTL SHOULD NOT exceed...' RFC 2119 keyword, line 197: '... NO RR's MUST only be signed by zone level keys [7]....' RFC 2119 keyword, line 252: '..., "real", domains, all NO records MUST...' (6 more instances...) 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 (November 24, 2000) is 8553 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) == Unused Reference: '4' is defined on line 649, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. '1') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2538 (ref. '2') (Obsoleted by RFC 4398) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-04) exists of draft-josefsson-base-encoding-00 ** Downref: Normative reference to an Informational draft: draft-josefsson-base-encoding (ref. '6') == Outdated reference: A later version (-02) exists of draft-ietf-dnsext-signing-auth-01 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft RSA Security 4 Expires: May 25, 2001 November 24, 2000 6 Authenticating denial of existence in DNS with minimum disclosure 7 (or; An alternative to DNSSEC NXT records) 8 draft-ietf-dnsext-not-existing-rr-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 25, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This draft present an alternative to NXT records, used to achieve 40 authenticated denial of existence of a domain name, class and type. 41 Problems with NXT records, as specified in RFC 2535, are identified. 42 One solution, the NO record, is presented. 44 The NO record differ from the NXT record by using a cryptographic 45 hash value instead of the domain name. This prevent an adversery 46 from collecting information by "chaining" through a zone. It also 47 remove delegation point concerns that was a side effect of NXT 48 records. The document also describe hash truncation and record 49 merging that reduces storage/network load. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4 56 3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4 58 3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6 59 3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7 61 3.6 No Considerations at Delegation Points . . . . . . . . . . 7 62 3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8 63 3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9 64 3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9 65 3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9 66 3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10 67 3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10 68 3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10 70 3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11 71 3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11 72 3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11 73 3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12 74 4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13 75 4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13 76 4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13 77 4.3 Information disclosure (chain problem) . . . . . . . . . . 13 78 4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13 79 4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13 80 4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13 81 4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14 82 4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14 83 4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14 84 5. Security Considerations . . . . . . . . . . . . . . . . . 15 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 86 References . . . . . . . . . . . . . . . . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . 16 88 Full Copyright Statement . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 "Domain Name Security Extensions", RFC 2535 [1], specifies several 93 extensions to DNS that provides data integrity and authentication. 94 Among them is the NXT record, used to achieve authenticated denial 95 of existence of domains, and authenticated denial of existence on 96 certain class/types on existing domains. 98 As a consequence of NXT records it is possible to "chain" through a 99 zone secured by DNS security extensions, collecting all names and/or 100 records in the zone. NXT records also introduce a complication at 101 delegation points. These are the main problems that motivated this 102 draft. 104 2. Context 106 There have been arguments that the "chain" problem of NXT records is 107 a non-issue. Often used is the argument that information in DNS is 108 public, and if you wish to keep information private, you shouldn't 109 publish it in DNS. This might be true, but nonetheless major 110 service providers and companies are restricting access to zone 111 transfers. Also, people have debated whether NXT records should be 112 part of DNSSEC at all because of this problem [5]. 114 Another aspect exist. When DNS is used to store certificates, as 115 described in RFC 2538 [2], certificates can identify individuals 116 and/or carry authentication information for special purposes. This 117 context has been the motivation for developing this draft. 119 The "chain" problem is not the only concern with NXT records. The 120 delegation considerations for NXT records (different RRsets in the 121 parent and child for the same domain) has also been regarded as a 122 flaw of the NXT records. 124 3. The NO Resource Record 126 This section describe the NO Resource Record. 128 3.1 Idea 130 A straight-forward extension to the NXT record that minimize 131 disclosure of information is to store a one-way function value 132 instead of the actual domain name. This is similar to NXT records; 133 where NXT records secure a interval where no existing domain names 134 are to be found, NO records secure a interval where no one-way value 135 of existing domain names are to be found. 137 The benefit, of course, is that an adversary does not yield any 138 useful information from the record. Specifically, "chaining" 139 through a zone to collect all records is no longer possible. 141 This idea has been extended in this document into allowing (but not 142 requiring) one record to deny existence of several records, and 143 truncating the hash value to the shortest unique prefix to preserve 144 space. 146 3.2 NO RDATA Format 148 The RDATA for a NO RR consists of one or more fields with the 149 following structure. The structure have the following elements: a 150 zero-terminated list of RR types, a hash length specifier, and a 151 hash value, as shown below. Both the "RR type" list and the "next 152 hash value" fields are of variable width. 154 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 155 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 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | / 158 / owner RR type list / 159 / | 160 +---------------+-----------------------------------------------+ 161 | # hash octets | SHA-1 hash value / 162 +---------------+ / 163 / / 164 +---------------------------------------------------------------+ 166 Replacing the NXT RR "type bit map" field is a variable length list 167 of RR types. Each RR type is 16 bits. As the list is of variable 168 length, a end-of-list indicator is require. End of the list is 169 signalled by a all-zero RR type. Each element is a 2 byte RR type. 170 The list MUST be sorted in RR type order. The change from NXT's 171 bitmap field removes the limit of authenticating only the first 127 172 RR types. 174 The RR type list indicates what types exist at the previous hash 175 value -- i.e. the first RR type list in the RRdata of a NO record 176 indicate what RR types exist at the domain name that hashes to the 177 owner name of that NO record. The second RR type list, if any, in 178 the RRdata of a NO record indicate what RR types exist at the domain 179 name that hashes the first SHA-1 value in the RRdata. And so on. 180 See below for a complete example of the on-the-wire-format of a NO 181 record with hash truncation and record merging and its 182 interpretation. 184 Length of the hash value field is denoted by the # hash octets 185 fields, it is a unsigned integer ranging from 0 to 255. The meaning 186 of a zero length integer is reserved. 188 The SHA-1 hash value field is a variable length field containing the 189 actual hash value. 191 The NO RRs for a zone SHOULD be automatically calculated and added 192 to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed 193 the zone minimum TTL. 195 The type number for the NO RR is TBD. 197 NO RR's MUST only be signed by zone level keys [7]. 199 3.3 NO RDATA on-the-wire format example 201 The following is a example of the on-the-wire-format of a complete 202 NO resource record were hash truncation and record merging is used. 203 It is the on-the-wire format of the NO record in section 3.13.1.2. 205 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | RR type 1 (A) | RR type 0 (end-of-list) | 209 +---------------+-----------------------------------------------+ 210 | 1 hash octet | Hash 0x22 | RR type 2 (NS) | 211 +---------------+---------------+-------------------------------+ 212 | RR type 6 (SOA) | RR type 15 (MX) | 213 +-------------------------------+---------------+---------------+ 214 | RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 | 215 +-------------------------------+---------------+---------------+ 216 | RR type 1 (A) | RR type 0 (end-of-list) | 217 +---------------+-----------------------------------------------+ 218 | 1 hash octet | Hash 0x90 | RR type 1 (A) | 219 +---------------+---------------+-------------------------------+ 220 | RR type 16 (TXT) | RR type 0 (end-of-list) | 221 +---------------+---------------+-------------------------------+ 222 | 1 hash octet | Hash 0x1b | 223 +-------------------------------+ 225 The intepretation here is that the domain that corresponds with the 226 NO owner name ("1b._no.example.org.", not shown above) have a A 227 record, that the domain that hash to 0x22 (truncated to one octet) 228 have a NS, SOA and MX record, that the domain that hash to 0x83 229 (truncated to 1 octet) have a A record etc. Note that the last hash 230 value of NO RRdata does not have a RR type list in the same record. 232 3.4 Owner Names 234 As the previous NO RR format describe, the "next domain name" of NXT 235 records is replaced by its hash value. This removes the possibility 236 of chaining both backwards and forwards through a zone. 238 But without also modifying the owner names of NO records it is still 239 not difficult to chain through a zone. Consider querying a server 240 for (say) "m._no.example.org", the reply could contain a NO record 241 for "g._no.example.org", now an adversary can lookup records for 242 "g._no.example.org", and then issue a query for a domain that would 243 sort (in "the canonical order" described in RFC 2535) just before 244 "g._no.example.org". Applying the technique over and over again, all 245 records in the zone can still be collected. 247 To prevent this, the owner names of NO records is replaced by its 248 hash value. As DNS places limits on what characters can be used in 249 owner names, the owner name uses a base 16 "hex" encoding [6]. 251 In order to remove the (very small) chance of generated NO record 252 names colliding with existing, "real", domains, all NO records MUST 253 be stored directly in the "_no" domain of the zone. I.e., a zone 254 "example.org." store its NO records as, say, 255 "35a4d1._no.example.org.". 257 This change in owner names also make sure that the delegation point 258 concerns of NXT records does not occur in NO records. 260 3.5 Additional Complexity Due To Wildcards 262 Proving that a non-existent name response is correct, or that a 263 wildcard expansion response is correct, makes things a little more 264 complex. 266 In particular, when a non-existent name response is returned, an NO 267 must be returned showing that the exact name did not exist and, in 268 general, one or more additional NO need to be returned to also prove 269 that there wasn't a wildcard whose expansion should have been 270 returned. (There is no need to return multiple copies of the same 271 NO.) These NOs, if any, are returned in the authority section of the 272 response. 274 Furthermore, if a wildcard expansion is returned in a response, in 275 general one or more NOs needs to also be returned in the authority 276 section to prove that no more specific name (including possibly more 277 specific wildcards in the zone) existed on which the response should 278 have been based. 280 3.6 No Considerations at Delegation Points 282 When NXT records are used to deny existance, there exists a special 283 case at delegation points. Namely, that two distinct RRsets exist 284 for the same owner name, one in the parent zone and one in the child 285 zone. 287 $ORIGIN parent.example.org. 288 @ SOA 289 NS 290 NXT child SOA NS SIG NXT 291 child NS foo 292 NXT next NS SIG NXT 293 next A 127.0.0.2 294 $ORIGIN child.parent.example.org. 295 @ SOA 296 NS 297 NXT name SOA NS SIG NXT 298 name A 127.0.2.1 299 NXT child.parent.example.org. 301 With NO records, the parent would deny existance of domains in 302 "_no.parent.example" and the child in 303 "_no.child.parent.example.org". Thus no NO RRset collision occur. 305 3.7 Hash Truncation and Dynamic Updates 307 Entities that create NO records MAY truncate the hash field. It 308 MUST NOT truncate hash fields so they are no longer unique 309 throughout a zone. Hash truncations MUST only be done to octet 310 offsets. Truncation MUST be such that less significant bits are 311 truncated, i.e. higher-order bits are preserved (see the examples). 313 Zones that are dynamically updated will have to calculate and add NO 314 records on-the-fly. If hash truncation is used, adding a new name 315 to the zone will require updating (and signing) NO records for the 316 conflicting name(s). 318 Since truncation (and also "compression" described in the next 319 section) make it impossible to predict the corresponding NO record 320 given a domain name, resolvers should not ask for a hashed NO record 321 (aaaa._no.example.org. IN NO) for a known domain name if they want 322 to find out what types exist at the domain. Instead, a resolver 323 might ask for NO records on the original name (www.example.org. IN 324 NO). Such records will never exist, and the correct NO record will 325 be returned by the server. 327 To summarize, the behaviour of hash truncation should be 328 configurable in the entity that creates NO records, to accomodate 329 different usage-patterns. If the zone is intended to be dynamicly 330 updated, hash truncation may be considered not worth the extra 331 on-the-fly processing required. 333 3.8 Reducing Number of Records 335 Entitities that create NO records MAY deny existence for several 336 records per NO record. Entities that create NO records should take 337 care so that each resulting NO record is not "too large". [Comments 338 on this? Should there be a specific limit? It might be left as a 339 DNS Operational consideration] 341 Merging several NO records into one record also place more work on 342 the resolver. Instead of parsing two hash values for each NO record 343 to determine if it's applicaple, a resolver will have to parse 344 several hash values and compare each. 346 The NO RR record consist of one or more RR type list / hash values, 347 described above, and a resolver need to parse the entire record to 348 collect each individual field. I.e., a NO parse algorithm could 349 looke like: read RRs, stop when you read a zero RR type, read hash 350 length indicator, read hash size, if the entire record is read stop, 351 otherwise read RRs, stop when you read a zero RR type, etc.. 353 3.9 Hash Collisions 355 Hash value collisions are expected not to occur. For SHA-1, the 356 probability that this should happen is 1 out of 2^80 on average. 358 However, collisions are actually only a problem if the domain names 359 producing the same hash value have different sets of existing types. 361 Consider the following records 363 ; SHA-1(one.example.org) = SHA-1(two.example.org) 365 one.example.org. IN A 1.2.3.4 366 two.example.org. IN A 5.6.7.8 368 Given that no other RR types exist for neither domain, both 369 "one.example.org" and "two.example.org" would be authenticated not 370 to exist by the same NO record. 372 3.10 Authenticating Denial of NO Records 374 NO records (together with SIG records) authenticate denial for other 375 types in a zone. Unlike NXT records that re-use the namespace in 376 the zone, NO records are not intended to authenticate denial of 377 other NO records. 379 3.11 Case Considerations 381 Before calculating SHA-1 hash values, domain names MUST be converted 382 into canonical format as described in RFC 2535. This is to make hash 383 comparisons possible. 385 3.12 Presentation Format 387 NO RRs do not appear in original unsigned zone master files since 388 they should be derived from the zone as it is being signed. 390 If a signed file with NO records is printed or NO records are 391 printed by debugging code, they appear as a list of unsigned 392 integers or RR mnemonics, and the hash value in base 16 hex 393 representation [6] with "0x" prepended (to distinguish it from 394 integer RR codes). The zero RR that terminate the list of RR types, 395 and the hash value length indicator, does not appear. 397 See the next section for examples of printed NO RRs. 399 3.13 Examples 401 This section contain examples of NO records, using the reserved 402 domain exmaple.org [3]. 404 3.13.1 Adding NO Records to a Zone 406 Consider the following zone file. 408 $ORIGIN example.org. 409 @ IN SOA ... 410 @ IN NS ns 411 @ IN MX 0 server 412 ns IN A ... 413 www IN A ... 414 sERVEr IN A ... 415 sERVEr IN TXT "text" 417 ; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 418 ; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 419 ; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf 420 ; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f 422 Note that hash values are calculcated on the canonical form. 424 The following two sections describe two valid ways of adding NO 425 records to a zone. 427 3.13.2 Simple NO creating entity 429 A simple NO creator entity might not implement truncation or provide 430 the possibility to deny more than one records per NO record. In 431 this case, the following would be added to the zone file. 433 $ORIGIN _no.example.org. 434 1b7838c69a66eb50cc215f66ee4554d0c4c940a5 435 IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 436 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 437 IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf 438 839ebd4386c0b26d81f147421b5b7036e61438cf 439 IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f 440 906a0ad5e604b1905828499dc8672ecb8de73e2f 441 IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 443 3.13.3 Advanced NO creating entity 445 A more advanced NO creator entity might append the following 446 instead, using both truncation and "compression". 448 $ORIGIN _no.example.org 449 1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A 451 Note that this contain 5 hash values while the zone only contain 4 452 records, the last value in the line above is in fact the first hash 453 value in the zone, closing the circular NO chain. 455 3.13.4 Resolver Query for Non-existing Domain 457 Consider a client looking up the non-existant domain name 458 "baz.example.org.", using the zone file from the previous section. 459 First, we note the following calculations. 461 SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e 462 SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021 464 A server would reply with an RCODE of NXDOMAIN and the authority 465 section data including the following: 467 ; backwards compatibility 468 example.org. IN SOA 470 ; prove no baz.example.org 471 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. 472 IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 473 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO 475 ; prove no *.example.org: 476 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. 477 IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf 478 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO 480 In order for a client to verify the authenticity of this reply, in 481 addition of verifying the SIG record, it will also need to calculate 482 the one-way hash of "baz.example.org." and verify it is contained 483 inside the interval of any NO record in the authority section. 484 Also, to prove there are no wildcard records for baz.example.org., 485 NO records for possible wildcard expansions are returned. A client 486 should similarily calculate hash values of possible wildcards and 487 compare them to the authority section. 489 Of course, if the zone was generated with the more advanced NO 490 creating entity, only the NO record from the previous section would 491 have to be returned. 493 3.13.5 Resolver Query for Non-existing Type At Existing Domain 495 Consider a client looking up TXT records for the existing domain 496 "www.example.org.", again, using the same zone file as previous. A 497 server would reply with an authority section like the following: 499 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. 500 IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f 501 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO 503 The resolver verifies the signature and make sure 504 SHA-1("bar.example.org.") hashes correctly. 506 4. Comparing NO and NXT 508 To ease comparison between NXT and NO records, this section 509 summarize (mis-)features of the NXT and the NO record formats. The 510 intent here is to address all operational differences between NO and 511 NXT records. 513 4.1 Denial Of Existence Of Non-Existing Names 515 Both NXT and NO provide strong data non-existance for non-existing 516 names. 518 NXT records authenticate data non-existance up to the probability of 519 finding a collision in the signature algorithm (1 in 2^64 for 520 RSA/MD5). NO records authenticate data non-existance up to the 521 probability of finding a collision in the signature algorithm (1 in 522 2^64 for RSA/MD5) and the NO record hash value (varies due to 523 truncation). If the RSA/MD5 scheme is used, hash values in NO 524 records may be truncated to 64 bits. 526 4.2 Denial Of Types Of Existing Names 528 Both NXT and NO provide strong data non-existance of types for 529 existing names. The previous discussion also apply here. 531 4.3 Information disclosure (chain problem) 533 NXT records make it possible to collect all names (and records) in a 534 zone. NO records prohibit this. 536 4.4 Delegation problem 538 NXT records require a special case where two different RRsets exist 539 at the same owner name, class and type. NO records does not have 540 this problem. 542 4.5 Zone size (Bytes) 544 The size difference is due to changing complete domain names with 545 hash values (SHA1 20 bytes). Without truncation, NO records are 546 probably larger than most NXT records. With truncation, NO records 547 uses a few byte per hash value instead of the (possibly compressed) 548 complete owner name. 550 4.6 Zone size (Number Of Records) 552 When NO compression is not used, NXT and NO uses the same number of 553 records. 555 However, NO compression can greatly reduce the number of records. 556 As an example, considering a zone with records of 100.000 different 557 names. NXT uses 200.000 records (NXT+SIG). Using NO compression 558 with 10 hash values on each reduce this number to 20.000 records 559 (NO+SIG). 561 4.7 Zone size (Number Of Owner names) 563 NO uses twice the amount of owner names as NXT. 565 However, NO compression can be used to reduce this to a fraction of 566 the normal amount. From the previous example with 10 hash values 567 per NO record, it will uses 10.000 additional owner names in a zone 568 with 100.000 names 570 4.8 SIG Labels field and Wildcard records 572 It is marginally faster to verify signatures for NXT records when 573 wildcard records are involved -- the SIG "Label fields" hints can be 574 used to determine the canonical name. With NO records this hint 575 cannot be used, because it relies on knowing the full name whereas 576 only the hash is available. One need to try a few SHA1 hashes to 577 find the correct canonical name. The number of hashes required to 578 try depend on the number of labels in the name, and scale linearly. 580 N.B. This penalty only apply to wildcard records. 582 4.9 Dynamic Updates 584 Resigning dynamically updated records is required both with NXT and 585 NO records. 587 However, when NO truncation and compression is used, the additional 588 penalty of re-hashing might also be required. 590 5. Security Considerations 592 Chaining through all NO records is still technically possible, 593 altough it cannot be used to collect names and/or records in the 594 zone (other than NO records themself). 596 The security of NO record hash values is dependent on the security 597 of the SHA-1 hash functions used. Truncation may affect this, but 598 the birthday-paradox argument does not apply. One must find a hash 599 collision given an existing hash value -- not simply find any hash 600 collision. It is thus reasonably to truncate NO records to half the 601 hash length used in the signature scheme (this would mean 64 bits in 602 the RSA/MD5 case). 604 It should be pointed out that given this scheme, it is easy to 605 estimate the number of records within a zone, considering hash 606 values are supposed to be equally distributed. This can be foiled 607 by adding any number of bogus records in the zone. 609 The authentication of NO records is provided by DNS SIG records, as 610 specified in RFC 2535. The security considerations of RFC 2535 is 611 not affected by this document, and should also be considered. 613 6. IANA Considerations 615 The NO RR type number should be selected by the IANA from the normal 616 RR type space. 618 The meaning of a zero hash length value can only be assigned by a 619 standards action. 621 Acknowledgement 623 The idea of encrypting names, that later evolved into just hashing 624 them, was originally proposed by Jonas Holmerin in private 625 discussions about DNS Security. Magnus Nystr�m proposed truncating 626 the hash values. 628 Thanks to John Linn and Magnus Nystr�m for comments on a early 629 version of this draft. 631 Olafur Gudmundsson pointed out delegation point issues, suggested 632 the use of a "_no" subdomain, and suggested replacing the type bit 633 map field with a sorted list. From the namedroppers mailing list, 634 I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson, 635 Peter Koch and Brian Wellington for comments and suggestions. Ed 636 Lewis noted that truncation to shortest unique prefix would not work. 638 References 640 [1] Eastlake, D., "Domain Name System Security Extensions", RFC 641 2535, March 1999. 643 [2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 644 Domain Name System (DNS)", RFC 2538, March 1999. 646 [3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 647 2606, June 1999. 649 [4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995. 651 [5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in 652 the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt, 653 October 1999. 655 [6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D. 656 draft-josefsson-base-encoding-00.txt, August 2000. 658 [7] Wellington, B, "Domain Name System Security (DNSSEC) Signing 659 Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May 660 2000. 662 Author's Address 664 Simon Josefsson 665 RSA Security 666 Arenav�gen 29 667 Stockholm 121 29 668 Sweden 670 Phone: +46 8 7250914 671 EMail: sjosefsson@rsasecurity.com 673 Full Copyright Statement 675 Copyright (C) The Internet Society (2000). All Rights Reserved. 677 This document and translations of it may be copied and furnished to 678 others, and derivative works that comment on or otherwise explain it 679 or assist in its implementation may be prepared, copied, published 680 and distributed, in whole or in part, without restriction of any 681 kind, provided that the above copyright notice and this paragraph 682 are included on all such copies and derivative works. However, this 683 document itself may not be modified in any way, such as by removing 684 the copyright notice or references to the Internet Society or other 685 Internet organizations, except as needed for the purpose of 686 developing Internet standards in which case the procedures for 687 copyrights defined in the Internet Standards process must be 688 followed, or as required to translate it into languages other than 689 English. 691 The limited permissions granted above are perpetual and will not be 692 revoked by the Internet Society or its successors or assigns. 694 This document and the information contained herein is provided on an 695 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 696 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 697 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 698 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 699 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 701 Acknowledgement 703 Funding for the RFC editor function is currently provided by the 704 Internet Society.