idnits 2.17.1 draft-arends-dnsnr-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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 590), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (June 2004) is 7254 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: 'RFC2535' is defined on line 537, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Arends 3 Internet-Draft Telematica Instituut 4 Expires: November 30, 2004 June 2004 6 DNSSEC Non-Repudiation Resource Record 7 draft-arends-dnsnr-00 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes the DNSNR Resource Record (RR) for the 41 Non-Repudiation (NR) of Existence service in the context of the DNS 42 Security Extensions (DNSSEC). The DNSNR is an alternative to NSEC or 43 "Authenticated Denial of Existence" Resource Records. 45 A signed DNSNR RR protects security-aware DNS components against 46 false denial of existence of RRsets by providing the RR types that 47 exist for its ownername, which optionally includes a 48 non-authoritative delegation point NS RR type. Labels in the 49 ownername and the RDATA may be a hash-value as a defense against zone 50 traversal. 52 The DNSNR is an alternative to current NSEC or "Authenticated Denial 53 of Existence" records. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The DNSNR Resource Record . . . . . . . . . . . . . . . . . . 4 61 2.1 DNSNR RDATA Wire Format . . . . . . . . . . . . . . . . . 4 62 2.1.1 The Authoritative Only Flag Field . . . . . . . . . . 4 63 2.1.2 The Hash Function Field . . . . . . . . . . . . . . . 5 64 2.1.3 The Salt Field . . . . . . . . . . . . . . . . . . . . 5 65 2.1.4 The Next Ownername Field . . . . . . . . . . . . . . . 5 66 2.1.5 The Type Bit Maps Field . . . . . . . . . . . . . . . 6 67 2.1.6 Inclusion of Wildcard Names in DNSNR RDATA . . . . . . 7 68 2.2 The DNSNR RR Presentation Format . . . . . . . . . . . . . 8 69 2.3 DNSNR RR Example . . . . . . . . . . . . . . . . . . . . . 8 70 3. Special Considerations . . . . . . . . . . . . . . . . . . . . 10 71 3.1 Delegation points . . . . . . . . . . . . . . . . . . . . 10 72 3.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 73 3.1.2 Salting . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.2 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 75 3.2.1 Avoiding Hash Collisions during generation . . . . . . 11 76 3.2.2 Second Preimage Requirement Analysis . . . . . . . . . 11 77 3.2.3 Possible Hash Value Truncation Method . . . . . . . . 12 78 3.3 Future Hash Functions . . . . . . . . . . . . . . . . . . 12 79 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 82 5.2 Informative References . . . . . . . . . . . . . . . . . . . 14 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 84 Intellectual Property and Copyright Statements . . . . . . . . 15 86 1. Introduction 88 The DNS Security Extensions (DNSSEC) introduced the NSEC Resource 89 Record (RR) for authenticated denial of existence. This document 90 introduces a new RR as an alternative to NSEC that allows for gradual 91 expansion of delegation-centric zones and provides measures against 92 zone traversal. 94 1.1 Rationale 96 The DNS Security Extensions included the NSEC RR to provide 97 authenticated denial of existence. Though the NSEC RR meets the 98 requirements for authenticated denial of Existence, it introduced a 99 side-effect in that the contents of a zone can be enumerated. This 100 side-effect may introduce undesired policy issues. 102 A second requirement was that the existence of all record types in a 103 zone -including delegation point NS record types- can be accounted 104 for, despite the fact that delegation point NS RRsets are not 105 authoritative and not signed. This requirement has a side-effect 106 that the overhead of delegation centric signed zones is not related 107 to the increase in security of subzones. This requirement does not 108 allow delegation centric zones size to grow in relation to the grow 109 of signed subzones. 111 In the past, solutions have been proposed as a measure against these 112 side effects but at the time were regarded as secondary over the need 113 to have a stable DNSSEC specification. With (draft-vixie-dnssec-ter) 114 a graceful transition path to future enhancements is introduced, 115 while current DNSSEC deployment can continue. This document 116 accumulates measures against the side effects introduced by NSEC, and 117 presents the DNS Non-Repudiation Record. 119 The reader is assumed to be familiar with the basic DNS concepts 120 described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs 121 that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 122 [RFC2308]. 124 1.2 Reserved Words 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. The DNSNR Resource Record 132 The DNSNR RR provides Non-repudiation of existence of DNS Resource 133 Record Sets. 135 The DNSNR resource record lists RR types present at the DNSNR RR's 136 ownername. It includes the ownername of the next authoritative, 137 optionally hashed, ownername in the canonical ordering of the zone. 138 A set of DNSNR RRs in a zone indicate which authoritative RRsets 139 exist, while delegation point NS records can optionally be included 140 to proof existence of an unsigned delegation. To provide protection 141 against zone traversal, the labels used in the DNSNR RR may be a 142 cryptographic hash-value. 144 The type value for the DNSNR RR is XX. 146 The DNSNR RR is class independent. 148 The DNSNR RR has no special TTL requirements. 150 2.1 DNSNR RDATA Wire Format 152 The RDATA of the DNSNR RR is as shown below: 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 |A|Hash Function| Salt | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 / Next Ownername / 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 / Type Bit Maps / 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 2.1.1 The Authoritative Only Flag Field 166 The Authoritative Only Flag field indicates whether the Type Bit Maps 167 include delegation point NS record types. 169 If the flag is set to 0, the NS RR type bit for a delegation point 170 ownername SHOULD be clear when the DNSNR RR is generated. The NS RR 171 type bit MUST be ignored during processing of the DNSNR RR. The NS 172 RR type bit has no meaning in this context (it is not authoritative), 173 hence the DNSNR does not contest the existence of a NS RR type record 174 for this ownername. When a delegation is not secured, there exist no 175 DS RR type nor any other authoritative types for this delegation, 176 hence the unsecured delegation has no DNSNR record associated. 178 Please see the Special Consideration section for implications for 179 unsigned delegations 181 If the flag is set to 1, the NS RR type bit for a delegation point 182 ownername MUST be set if the DNSNR covers a delegation, eventhough 183 the NS RR itself is not authoritative. This implies that all 184 delegations, signed or unsigned have a DNSNR record associated. This 185 behaviour is identical to NSEC behaviour with regards to interprating 186 the Type Bit Maps 188 2.1.2 The Hash Function Field 190 The Hash Funtion field identifies the cryptographic hash function 191 used to construct the hash-value. 193 If the Hash Function field has value 0, no hash function was used, 194 and the ownername is a set of plain labels. 196 If the Hash Function field has a value other the 0, a cryptographic 197 hash function has been used to create a hash-value for each 198 individual label under the apex ownername, prepended with the Salt 199 field value, and is presented by a base32 value. 201 The hashed label of a DNSNR RR associated with the apex is a hash of 202 the salt field value. Logically, the salt field is prepended to 203 non-existent label and the hashed result is a label prepended to the 204 apex. 206 This document defines Value 0 (no Hash Function) and Value 1 (SHA-1). 207 All other values are reserved. 209 On reception, a resolver MUST discard DNSNR RR with an unknown Hash 210 Function value. 212 2.1.3 The Salt Field 214 When the Hash Function field value is not zero, a hash funtion is 215 used. In that case, the label is prepended with the salt field value 216 before hashing in order to defend against precalculated dictionary 217 attacks. The Salt field value must be the same for every DNSNR 218 generated in the zone. 220 When the Hash Function field value is zero, the Salt field SHOULD 221 have all bits set to zero, and MUST be ignored during processing. 223 2.1.4 The Next Ownername Field 225 If the Hash Function field has value 0, the Next Ownername field 226 contains the ownername of the next authoritative RRset in the 227 canonical ordering of the zone; see ... for an explanation of 228 canonical ordering. The value of the Next Owner Name field in the 229 last DNSNR record in the zone is the name of the zone apex (the 230 ownername of the zone's SOA RR). 232 If the Hash Function field has a value other then 0, the Next 233 Ownername field contains the next hash-value of an ownername of an 234 authoritative RRset in the canonical ordering of hash values for 235 ownernames. The value of the Next Ownername field in the last DNSNR 236 record in the zone is the value of the first hash value in canonical 237 ordering of the zone. 239 A sender MUST NOT use DNS name compression on the Next Ownername 240 field when transmitting an DNSNR RR. 242 A receiver which receives an DNSNR RR containing a compressed Next 243 Ownername field SHOULD decompress the field value. 245 Ownernames of RRsets not authoritative for the given zone (such as 246 glue records) MUST NOT be listed in the Next Ownername unless either 247 authoritative RRset exists at the same ownername, or the 248 Authortiative Only flag is clear and the ownername is an unsigned 249 delegation point. 251 2.1.5 The Type Bit Maps Field 253 The Type Bit Maps field identifies the RRset types which exist at the 254 DNSNR RR's ownername. 256 The Type bit for the DNSNR and RRSIG MUST be set during generation, 257 and MUST be ignored during processing. 259 The RR type space is split into 256 window blocks, each representing 260 the low-order 8 bits of the 16-bit RR type space. Each block that 261 has at least one active RR type is encoded using a single octet 262 window number (from 0 to 255), a single octet bitmap length (from 1 263 to 32) indicating the number of octets used for the window block's 264 bitmap, and up to 32 octets (256 bits) of bitmap. 266 Blocks are present in the DNSNR RR RDATA in increasing numerical 267 order. 269 Type Bit Maps field = ( Window Block # | Bitmap Length | Bitmap )+ 271 where "|" denotes concatenation. 273 Each bitmap encodes the low-order 8 bits of RR types within the 274 window block, in network bit order. The corresponds to RR type 1 275 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window 276 block 1, bit 1 corresponds to RR type 257, bit 2 to RR type 258. If 277 a bit is set to 1, it indicates that an RRset of that type is present 278 for the DNSNR RR's ownername. If a bit is set to 0, it indicates 279 that no RRset of that type is present for the DNSNR RR's ownername. 281 The RR type 2 (NS) is authoritative at the apex of a zone and is not 282 authoritative at a delegation point. If the Authoritative Only Flag 283 is clear, the delegation point NS RR type MUST NOT be included in the 284 type bit maps. If the Authoritative Only Flag is set, the NS RR type 285 at a delegation point MUST be included in the type bit maps. 287 Since bit 0 in window block 0 refers to the non-existent RR type 0, 288 it MUST be set to 0. After verification, the validator MUST ignore 289 the value of bit 0 in window block 0. 291 Bits representing pseudo-types MUST be set to 0, since they do not 292 appear in zone data. If encountered, they MUST be ignored upon 293 reading. 295 Blocks with no types present MUST NOT be included. Trailing zero 296 octets in the bitmap MUST be omitted. The length of each block's 297 bitmap is determined by the type code with the largest numerical 298 value, within that block, among the set of RR types present at the 299 DNSNR RR's ownername. Trailing zero octets not specified MUST be 300 interpreted as zero octets. 302 A zone MAY include a DNSNR RR for ownernames at unsigned delegation 303 points with Authoritative Only flag set to 1. 305 A zone MUST include a DNSNR RR for ownernames at unsigned delegation 306 points with Authoritative Only flag set to 0. 308 Signed delegation points have an authoritative DS record for the 309 ownername, and has therefor always a DNSNR record associated with the 310 ownername. 312 Signed delegation point DNSNR records may have the NS type bit set in 313 the type bit maps, depending on the MNR bit 0. 315 A zone MUST NOT generate an DNSNR RR for any domain name that only 316 holds glue records. 318 2.1.6 Inclusion of Wildcard Names in DNSNR RDATA 320 If a wildcard ownername appears in a zone, the wildcard label ("*") 321 is treated as a literal symbol and is treated the same as any other 322 ownername for purposes of generating DNSNR RRs. Wildcard owner names 323 appear in the Next Ownername field without any wildcard expansion. 325 2.2 The DNSNR RR Presentation Format 327 The presentation format of the RDATA portion is as follows: 329 The NRM field is represented as a unsigned decimal integer. The 330 value has a maximum of 3. 332 The Hash Function field is represented as an unsigned decimal 333 integer. The value has a maximum of 127. 335 The Salt field is represented as a sequence of case-insensitive 336 hexadecimal digits. Whitespace is allowed within the hexadecimal 337 text. 339 The Next Ownername field is represented as a domain name. 341 The Type Bit Maps field is represented as a sequence of RR type 342 mnemonics. When the mnemonic is not known, the TYPE representation 343 as described in ... MUST be used. 345 2.3 DNSNR RR Example 347 The following DNSNR RR identifies the RRsets associated with 348 alfa.example.com. and identifies the next authoritative name after 349 alfa.example.com. 351 alfa.example.com. 86400 IN DNSNR 1 0 0 host.example.com. ( 352 A MX RRSIG DNSNR TYPE1234 ) 354 The first four text fields specify the name, TTL, Class, and RR type 355 (DNSNR). The first RDATA value (1) indicate that the DNSNR RR 356 includes non-authoritative NS types. The second value (0) indicate 357 that the labels in the ownernames are not hash-values. The third 358 value (0) is the Salt value and is ignored, since no Hash Function 359 has been indicated. The entry host.example.com. is the next 360 authoritative name after alfa.example.com. in canonical order. The 361 A, MX, RRSIG and DNSNR mnemonics indicate there are A, MX, RRSIG, 362 DNSNR, and TYPE1234 RRsets associated with the name alfa.example.com. 364 The RDATA section of the DNSNR RR above would be encoded as: 366 0x00 0x80 0x00 0x00 0x00 367 0x04 'h' 'o' 's' 't' 368 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' 369 0x03 'c' 'o' 'm' 0x00 370 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 371 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 372 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 373 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 374 0x00 0x00 0x00 0x00 0x20 376 Assuming that the resolver can authenticate this DNSNR record, it 377 could be used to prove that beta.example.com does not exist, or could 378 be used to prove there is no AAAA record associated with 379 alfa.example.com. 381 3. Special Considerations 383 The following paragraphs clarify specific behaviour explain special 384 considerations for implementations. 386 3.1 Delegation points 388 This proposal introduces the Authoritative Only Flag which indicates 389 wether non authoritative delegation point NS records are included in 390 the type bit Maps. As discussed in paragraph 2.1.1, a flag value of 391 1 indicates that the interpration of the type bit maps is identical 392 to NSEC records 394 The following subsections describe behaviour when the flag value is 395 0. 397 3.1.1 Unsigned Delegations 399 Unsigned Delegation point NS records are not authoritative. They are 400 authoritative in the delegated zone. There exist also no other data 401 at the ownername of an unsigned delegation point. 403 Since no authoritative data exist at this ownername, it is excluded 404 from the DNSNR chain. This is an optimisation since it relieves the 405 zone of including an DNSNR record and its associated signature for 406 this name. 408 A DNSNR that denies existence of ownernames between X and X' with the 409 Authoritative Only Flag clear can not be used to proof presence nor 410 absence of the delegation point NS records in the interval X, X'. 411 The Authoritative Only Flag effectively states No Contest on the 412 presence of delegation point NS resource records 414 Since proof is absent, there exist a new attack vector. Unsigned 415 delegation point NS records can be deleted during a man in the middle 416 attack, effectively dnying existence of the delegation. This is a 417 form of Denial of Service, where the victim has no information it is 418 under attack, since all signatures are valid and the fabricated 419 response form is a known type of response. 421 The only possible mittigation is to either not use this method, hence 422 proving existence or absence of unsigned delegations, or signing the 423 delegated zone, changing the unsigned delegation into a signed 424 delegation. 426 A second attack vector exists in that an adversary is able to 427 succesfully fabricate a response claiming a not existant delegation 428 to exist, though unsigned. 430 The only possible mittigation is to either not use this method, hence 431 proving absence of unsigned delegations. 433 3.1.2 Salting 435 Augmenting labels with salt before hashing increases the cost of a 436 dictionary of pre-generated hash-values. For every bit of salt, the 437 cost of the dictionary doubles. The DNSNR RR uses 24 bits of salt, 438 multiplying the cost with 2^24. 440 The salt value for each DNSNR RR MUST be equal for a single version 441 of the zone. 443 3.2 Hash Collision 445 This section is relevant when the Hash Function field value is not 446 zero, which indicates the use of a hash function. 448 Hash collisions occur when different messages have the same hash 449 value. The probability that this happens during the generation of 450 hash values is for SHA1 about 1 in 2^80 on average. Though this 451 probability is low, the following paragraphs deal with avoiding 452 Collisions and assessing possible damage in the event of an attack 453 using Hash collisions. 455 3.2.1 Avoiding Hash Collisions during generation 457 During generation of DNSNR RRs, hash values are supposedly unique. 458 In the (academic) case a collision does occur, an alternative salt 459 SHOULD be chosen and all hash values SHOULD be regenerated. 461 In case hash values are not regenerated on collision, the DNSNR RR 462 MUST list all authoritative RR types that exist for both messages, to 463 avoid a replay attack, spoofing an existing type as non-existent. 465 3.2.2 Second Preimage Requirement Analysis 467 A collision resistant hash function has a second-preimage resistance 468 property. The second-preimage resistance property means that it is 469 computationally infeasible to find another message with the same hash 470 value as a given message, i.e, given x, to find a second-preimage X' 471 <> X such that hash(X) = hash(X'). The probability of finding a 472 second preimage is 1 in 2^160 for SHA-1 on average. To mount an 473 attack using an existing DNSNR RR, an adversary needs to find a 474 second preimage. 476 Assuming an adversary is capable of mounting such an extreme, the 477 actual damage is that a response message can be generated which 478 claims that a certain QNAME (i.e. the second pre-image) does exist, 479 while in reality QNAME does not exist (aka false positive), which 480 will either cause a security aware resolver to re-query for the 481 non-existent name, or to fail the initial query. Note that the 482 adversary can't mount this attack on an existing name, solely on a 483 name that the adversary can't choose and does not yet exist. 485 3.2.3 Possible Hash Value Truncation Method 487 The previous sections outlined the low probability and low impact of 488 a second-preimage attack. When impact and probability are low, while 489 space in a DNS message is costly, truncation is tempting. Truncation 490 might be considered to allow for shorter ownernames and rdata in case 491 of labels with hash values. The author seeks comfirmation on the 492 assumption that truncation decreases resilliance on colliding hash 493 values though the overall security model does not significantly 494 deteriorate. 496 An extreme hash value truncation would be truncating to the shortest 497 possible unique label value. Considering that hash values are 498 presented in base32, which represents 5 bits per label character, 499 truncation must be done on a 5 bit boundary. 501 Though the mentioned truncation can be maximised to a certain 502 extreme, the probability of collision increases exponentially for 503 every truncated bit. Given the low impact of hash value collisions 504 and limited space in DNS messages, the balance between truncation 505 profit and collision damage may be determined by local policy (but 506 see first paragraph where 'the author seeks'). 508 3.3 Future Hash Functions 509 4. Acknowledgements 511 Thanks to Mark Kosters, David Blacka, Simon Josefsson, Paul Vixie and 512 Ben Laurie for their time, review and input. 514 5. References 516 5.1 Normative References 518 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 519 STD 13, RFC 1034, November 1987. 521 [RFC1035] Mockapetris, P., "Domain names - implementation and 522 specification", STD 13, RFC 1035, November 1987. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 528 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 529 April 1997. 531 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 532 Specification", RFC 2181, July 1997. 534 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 535 NCACHE)", RFC 2308, March 1998. 537 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 538 RFC 2535, March 1999. 540 5.2 Informative References 542 Author's Address 544 Roy Arends 545 Telematica Instituut 546 Drienerlolaan 5 547 7522 NB Enschede 548 NL 550 EMail: roy.arends@telin.nl 552 Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Disclaimer of Validity 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Copyright Statement 588 Copyright (C) The Internet Society (2004). This document is subject 589 to the rights, licenses and restrictions contained in BCP 78, and 590 except as set forth therein, the authors retain all their rights. 592 Acknowledgment 594 Funding for the RFC Editor function is currently provided by the 595 Internet Society.