idnits 2.17.1 draft-jas-dnsext-no-00.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 38 instances of lines with control characters in the document. == There are 9 instances of lines with non-RFC2606-compliant FQDNs 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 134: '...O RRs for a zone SHOULD be automatical...' RFC 2119 keyword, line 135: '...ed. The NO RR's TTL SHOULD NOT exceed...' 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 (July 14, 2000) is 8686 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: 'RFC 2434' on line 432 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2535 (ref. '2') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2538 (ref. '3') (Obsoleted by RFC 4398) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S.A. Josefsson 3 Internet-Draft RSA Security 4 Expires: January 12, 2001 July 14, 2000 6 Authenticating denial of existence in DNS with minimum disclosure 7 (or; An alternative to DNSSEC NXT records) 8 draft-jas-dnsext-no-00 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 January 12, 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 and one solution is presented. 44 1. Introduction 46 "Domain Name Security Extensions", RFC 2535 [2], specifies several 47 extensions to DNS that provides data integrity and authentication. 48 Among them is the NXT record, used to achieve authenticated denial 49 of existence of domains, and authenticated denial of existence on 50 certain class/types on existing domains. 52 As a consequence of NXT records it is possible to "chain" through a 53 zone secured by DNS security extensions, collecting all records in 54 the zone. This is the main problem that motivated this draft. 56 2. Context 58 There have been arguments that the "chain" problem of NXT records is 59 a non-issue. Often used is the argument that information in DNS is 60 public, and if you wish to keep information private, you shouldn't 61 publish it in DNS. This might be true, but nonetheless major 62 service providers and companies are restricting access to zone 63 transfers. Also, people have debated whether NXT records should be 64 part of DNSSEC at all because of this problem [1]. 66 Another aspect exist. When DNS is used to store certificates, as 67 described in RFC 2538 [3], certificates can identify individuals 68 and/or carry authentication information for special purposes. This 69 context has been the motivation for developing this draft. 71 3. The NO Resource Record 73 This section describe the NO Resource Record. 75 3.1 Idea 77 A straight-forward extension to the NXT record that minimize 78 disclosure of information is to store a one-way function value 79 instead of the actual domain name. This is similar to NXT records; 80 where NXT records secure a interval where no existing domain names 81 are to be found, NO records secure a interval where no one-way value 82 of existing domain names are to be found. 84 The benefit, of course, is that an adversary does not yield any 85 useful information from the record. Specifically, "chaining" 86 through a zone to collect all records is no longer possible. 88 3.2 NO RDATA Format 90 The RDATA for an NO RR consists of a hash function identifier, a 91 hash value and a bit map, as shown below. Both the "next hash 92 value" and the "type bit map" are variable width fields. 94 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 95 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 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | hash alg. | / 98 +---------------+ next hash value / 99 / / 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | / 102 / type bit map / 103 / / 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 The hash algorithm identifier indicate the hash algorithm used to 107 hash domain names. It is also used to infer the "next hash value" 108 field length, besides it's use in verifying the actual hash value. 110 The hash value field is a variable length field containing the 111 actual hash value. Interpretation of the data is specific to each 112 hash function, see the next section for currently defined hash 113 functions. 115 Like the NXT RR type bit map, the NO RR type bit map format 116 currently defined is one bit per RR type present for the domain name 117 that hash to the owner name of the RDATA. A one bit indicates that 118 at least one RR of that type is present for the owner name. A zero 119 indicates that no such RR is present. All bits not specified because 120 they are beyond the end of the bit map are assumed to be zero. Note 121 that bit TBD, for NO, will always be on so the minimum bit map 122 length is actually 6 octets. Trailing zero octets are prohibited in 123 this format. The first bit represents RR type zero (an illegal type 124 which can not be present) and so will be zero in this format. This 125 format is not used if there exists an RR with a type number greater 126 than 127. If the zero bit of the type bit map is a one, it 127 indicates that a different format is being used which will always be 128 the case if a type number greater than 127 is present. 130 The size of the bit map can be inferred from the RDLENGTH and the 131 length of the hash value field, that depend on the hash algorithm 132 identifier. 134 The NO RRs for a zone SHOULD be automatically calculated and added 135 to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed 136 the zone minimum TTL. 138 The type number for the NO RR is TBD. 140 NO RRs are only signed by zone level keys. 142 3.3 The Hash Algorithm Identifier 144 Hash algorithms should be chosen to minimize collisions and make it 145 impractical to infer input given output. Cryptographic hash 146 functions are fine. 148 This octet is the hash algorithm. The following values are assigned: 150 VALUE Algorithm 152 0 - reserved, see Section 7 153 1 MD5, RFC 1321 [4], recommended 154 2 SHA-1 [5], MANDATORY 155 3 reserved for SHA-2 156 4-250 - available, see Section 7 157 251-254 private 158 255 - reserved, see Section 7 160 As noted above, the size of the hash value field is infered from 161 this identifier. For example, SHA-1 produces 160 bit long size. 163 If a hash function does not return values of length in multiples of 164 octets, the value should be zero-padded to the next octet boundary. 166 3.4 Owner names 168 As the previous NO RR format describe, the "next domain name" field 169 is replaced by its hash value. This removes the possibility of 170 chaining both backwards and forwards through a zone. 172 But it is still not difficult to chain through a zone; consider 173 querying a server for (say) "m.dom.org", the reply could contain a 174 NO record for "g.dom.org", now an adversary can lookup records for 175 "g.dom.org", and then issue a query for a domain that would sort (in 176 "the canonical order" described in RFC 2535) just before 177 "g.dom.org". Applying the technique over and over again, all 178 records in the zone can still be downloaded. 180 To prevent this, the owner names of NO records should also be 181 replaced by its hash value. As DNS places limits on what characters 182 can be used in owner names, a base-32 encoding is used (see Appendix 183 A). Since DNS domains need to begin with a alphabetic character, 184 the string "no-" should be prepended to the base32 value. 186 3.5 Additional Complexity Due To Wildcards 188 Proving that a non-existent name response is correct or that a 189 wildcard expansion response is correct makes things a little more 190 complex. 192 In particular, when a non-existent name response is returned, an NO 193 must be returned showing that the exact name queried did not exist 194 and, in general, one or more additional NO need to be returned to 195 also prove that there wasn't a wildcard whose expansion should have 196 been returned. (There is no need to return multiple copies of the 197 same NO.) These NOs, if any, are returned in the authority section 198 of the response. 200 Furthermore, if a wildcard expansion is returned in a response, in 201 general one or more NOs needs to also be returned in the authority 202 section to prove that no more specific name (including possibly more 203 specific wildcards in the zone) existed on which the response should 204 have been based. 206 3.6 Considerations at Delegation Points 208 When NXT records are used to deny existance, there exists a special 209 case at delegation points. Namely, that two distinct RRsets exist 210 for the same owner name, one in the parent zone and one in the child 211 zone. 213 $ORIGIN parent.example. 214 @ SOA 215 NS 216 NXT child SOA NS SIG NXT 217 child NS foo 218 NXT next NS SIG NXT 219 next A 127.0.0.2 221 $ORIGIN child.parent.example. 222 @ SOA 223 NS 224 NXT name SOA NS SIG NXT 225 name A 127.0.2.1 226 NXT child.parent.example. 228 With NO records instead, the "child.parent.example" domain would 229 have NO records "no-1234.parent.example" and 230 "no-1234.child.parent.example" respectively. Thus there will not be 231 two distinct RRsets at delegation points if NO records are used. 233 3.7 Hash Value Collisions 235 Hash value collisions are expected not to occur. For MD5, the 236 probability that this should happen is 1 out of 2^64. 238 However, collisions are actually only a problem if the domain names 239 producing the same hash value have different sets of existing types. 241 Consider the following records 243 ; 244 ; OWH(one.dom.org) = OWH(two.dom.org) 245 ; 246 one.dom.org. IN A 1.2.3.4 247 two.dom.org. IN A 5.6.7.8 249 Given that no other RRs exist for neither domain, both "one.dom.org" 250 and "two.dom.org" would be authenticated not to exist by the same NO 251 record. 253 However, the (academic) problem of hash collisions can be solved 254 completely within the framework of NO records, should the need 255 arise, by defining a "hash" algorithm that uses public key 256 encryption to encrypt domain names, with the zone's public key. 257 Collisions cannot happen, and a resolver can verify the "hash" value 258 by resolving the zone's key and performing the encryption. 260 This document does not describe such one-way functions, since they 261 are not expected to be necessary. 263 3.8 ASCII presentation 265 NO RRs do not appear in original unsigned zone master files since 266 they should be derived from the zone as it is being signed. 268 If a signed file with NO added is printed or NOs are printed by 269 debugging code, they appear as the hash algorithm identifier (see 270 below), and the next hash value, and followed by the RR type present 271 bits as an unsigned integer or sequence of RR mnemonics. 273 The hash algorithm field can be represented as either an unsigned 274 integer or symbolicly. The following initial symbols are defined as 275 indicated: 277 Value Symbol 279 001 MD5 280 002 SHA1 282 The hash value is represented in base64 [2] and may be divided up 283 into any number of white space separated substrings, down to single 284 base 64 digits, which are concatenated to obtain the full hash 285 value. These substrings can span lines using the standard 286 parenthesis. 288 3.9 Examples 290 This section contain examples of NO records. For readability, all 291 base32/base64 encoded hash values are, unless otherwise stated, 292 small integers. Also, the contrived one-way function identifier OWH 293 is used. 295 3.9.1 Adding NO records to a zone 297 Consider the following zone file. 299 $ORIGIN dom.org 300 @ IN SOA ... ; OWH(dom.org) = 50 301 @ IN NS foo ; OWH(dom.org) = 50 302 foo IN A ... ; OWH(foo.dom.org) = 80 303 bar IN A ... ; OWH(bar.dom.org) = 30 304 gee IN A ... ; OWH(gee.dom.org) = 60 305 gee IN TXT ... ; OWH(gee.dom.org) = 60 306 zoo IN A ... ; OWH(moo.dom.org) = 10 308 Now, the following NO records would be added to the zone. A NO 309 record for the fictious wildcard name "*.dom.org" will have to be 310 added, unless it's already present in the zone. Here, assume 311 OWH(*.dom.org) = 40. 313 no-10 IN NO OWH 30 A 314 no-30 IN NO OWH 40 A 315 no-40 IN NO OWH 50 ; wildcard domain 316 no-50 IN NO OWH 60 SOA NS 317 no-60 IN NO OWH 80 A TXT 318 no-80 IN NO OWH 10 A 320 3.9.2 Resolver query for non-existant domain 322 Consider a client looking up the non-existant domain name 323 "baz.dom.org", using the zone file from the previous section. 325 Assume OWH(baz.dom.org) = 17. A server would reply with an RCODE of 326 NXDOMAIN and the authority section data including something like the 327 following: 329 dom.org. IN SOA ... ; backwards compatibility 330 no-10.dom.org. IN NO OWH 30 A ; prove no baz.dom.org 331 no-10.dom.org. IN SIG NO ... 332 no-40.dom.org. IN NO OWH 50 ; prove no *.dom.org 333 no-40.dom.org. IN SIG NO ... 335 In order for a client to verify the authenticity of this reply, in 336 addition of verifying the SIG record, it will also need to calculate 337 the one-way hash of "baz.dom.org" and verify it is contained inside 338 the interval of 10 ... 30. Also, to prove there are no wildcard 339 records for baz.dom.org, NO records for possible wildcard expansions 340 are returned. 342 3.9.3 Resolver query for non-existing type in existing domain 344 Consider a client looking up TXT records for "bar.dom.org", again, 345 using the same zone file as previous. A server would reply with an 346 authority section like the following: 348 no-30.dom.org. IN NO OWH 40 A 349 no-30.dom.org. IN SIG NO ... 351 The resolver verifies the signature and make sure OWH(bar.dom.org) 352 hash to 30. 354 4. Savings on size of records (further work) 356 To reduce the size of NO records, it is possible to use a scheme to 357 truncate hash values to the shortest unique (within the zone file 358 being generated) prefix value. If this is done, the size of the 359 hash value field can't be infered from RDLENGTH and the hash 360 algorithm, and it will be required to introduce a new field in the 361 NO RR data format to specify hash field size. 363 When NO records are generated for a zone, instead of printing the 364 complete hash value field (128 bits with MD5), the generator should 365 print to shortest unique prefix in the zone, together with a length 366 indicator. The length should only be truncated into multiples of 367 octets, so that standard base64 and base32 code can be used. 369 A resolver verifying that domain "a.dom.org" is contained within the 370 interval in a NO record, should calculate the hash value, and 371 compare it against both hash values in the record to make sure it is 372 indeed contained in the interval. The comparison should be such 373 that lack of bits in the owner name hash value is treated as 0's, 374 and lack of bits in the RR data hash value is treated as 1's. (Also, 375 the SIG record need to be verified.) 377 The size of NO records should, with this modification, be a function 378 of the zone file size. An estimate for a zone with 100.000 domains 379 would be that the hash value length could be reduced from 128 bits 380 (for MD5) or 160 bits (for SHA1) to a mean of about 16-17 bits. (Not 381 all NO records in a zone are required to have equal hash field 382 length, but in practice it is likely because of properties in 383 cryptographic hash functions.) 385 It should be noted, however, that the size of even untruncated NO 386 records are much lesser than the size of standard SIG and KEY 387 records. 389 5. Savings on number of records (further work) 391 If there are requirements to trade on-line message size for smaller 392 number of NO records (say, in a large zone), it would be possible to 393 "compress" several contiguous NO records into one, larger, record. 394 Imagine the following records. 396 no-10 IN NO OWH 30 A 50 SOA NS 397 no-50 IN NO OWH 60 A TXT 80 A 398 no-80 IN NO OWH 10 A 400 The client will then need to perform a binary search within the 401 RRdata of the NO record to verify that the queried domain is located 402 between two other one-way hash values. 404 6. Security Considerations 406 Chaining through all NO records is still technically possible, 407 altough it cannot be used for collecting records in the zone. The 408 security is dependent on the security of the one-way functions used. 410 Using base32 encoded owner names place an implicit limit on the 411 output size of hash algorithms to 300 bits. 413 It should be pointed out that given this scheme, it is easy to 414 estimate the number of records within a zone, considering hash 415 values are supposed to be equally distributed. This can be foiled 416 by computing any number of bogus records in the zone. 418 Calculcation of DNS SIG records of NO records, to provide data 419 authority, is specified in RFC 2535 and is not affected by this 420 draft. 422 The security considerations in RFC 2535 still apply to DNS. 424 7. IANA Considerations 426 The NO RR type number should be selected by the IANA from the normal 427 RR type space. 429 Hash algorithm numbers 4 through 250 are available for assignment 430 should sufficient reason arise. However, the designation of a new 431 algorithm could have a major impact on interoperability and requires 432 an IETF Standards Action [RFC 2434]. The existence of the private 433 algorithm types 251 through 254 should satisfy most needs for 434 private or proprietary algorithms. 436 The meaning of the first bit of the NO RR "type bit map", described 437 in section 3.2 paragraph 4, being a one can only be assigned by a 438 standards action. 440 Acknowledgement 442 The idea was originally proposed by Jonas Holmerin in private 443 discussions about DNS Security. Magnus Nystr�m proposed truncating 444 the hash fields to reduce record size. Olafur Gudmundsson pointed 445 out delegation point issues. 447 Thanks to John Linn and Magnus Nystr�m for comments on a early 448 version of this draft. 450 References 452 [1] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in 453 the CAIRN Testbed.", October 1999. 455 [2] Eastlake, D., "Domain Name System Security Extensions", RFC 456 2535, March 1999. 458 [3] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 459 Domain Name System (DNS)", RFC 2538, March 1999. 461 [4] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 462 1992. 464 [5] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995. 466 [6] Myers, J., "SASL GSSAPI mechanisms", May 2000. 468 Author's Address 470 Simon Josefsson 471 RSA Security 472 Arenav�gen 29 473 Stockholm 121 29 474 Sweden 476 Phone: +46 8 7250914 477 EMail: sjosefsson@rsasecurity.com 479 Appendix A. Base 32 Encoding 481 The following description of base32 is due to [6], the padding 482 section was updated to fix two typos. 484 The Base32 encoding is designed to represent arbitrary sequences of 485 octets in a form that needs to be case insensitive but need not be 486 humanly readable. 488 A 33-character subset of US-ASCII is used, enabling 5 bits to be 489 represented per printable character. (The extra 33rd character, "=", 490 is used to signify a special processing function.) 492 The encoding process represents 40-bit groups of input bits as 493 output strings of 8 encoded characters. Proceeding from left to 494 right, a 40-bit input group is formed by concatenating 5 8bit input 495 groups. These 40 bits are then treated as 8 concatenated 5-bit 496 groups, each of which is translated into a single digit in the 497 base32 alphabet. When encoding a bit stream via the base32 498 encoding, the bit stream must be presumed to be ordered with the 499 most-significant-bit first. That is, the first bit in the stream 500 will be the high-order bit in the first 8bit byte, and the eighth 501 bit will be the low-order bit in the first 8bit byte, and so on. 503 Each 5-bit group is used as an index into an array of 32 printable 504 characters. The character referenced by the index is placed in the 505 output string. These characters, identified in Table 1, below, are 506 selected from US-ASCII digits and uppercase letters. 508 Table 1: The Base32 Alphabet 510 Value Encoding Value Encoding Value Encoding Value Encoding 511 0 A 9 J 18 S 27 3 512 1 B 10 K 19 T 28 4 513 2 C 11 L 20 U 29 5 514 3 D 12 M 21 V 30 6 515 4 E 13 N 22 W 31 7 516 5 F 14 O 23 X 517 6 G 15 P 24 Y (pad) = 518 7 H 16 Q 25 Z 519 8 I 17 R 26 2 521 Special processing is performed if fewer than 40 bits are available 522 at the end of the data being encoded. A full encoding quantum is 523 always completed at the end of a body. When fewer than 40 input bits 524 are available in an input group, zero bits are added (on the right) 525 to form an integral number of 5-bit groups. Padding at the end of 526 the data is performed using the "=" character. Since all base32 527 input is an integral number of octets, only the following cases can 528 arise: 530 (1) the final quantum of encoding input is an integral multiple of 531 40 bits; here, the final unit of encoded output will be an integral 532 multiple of 8 characters with no "=" padding, 534 (2) the final quantum of encoding input is exactly 8 bits; here, the 535 final unit of encoded output will be two characters followed by six 536 "=" padding characters, 538 (3) the final quantum of encoding input is exactly 16 bits; here, 539 the final unit of encoded output will be four characters followed by 540 four "=" padding characters, 542 (4) the final quantum of encoding input is exactly 24 bits; here, 543 the final unit of encoded output will be five characters followed by 544 three "=" padding characters, or 546 (5) the final quantum of encoding input is exactly 32 bits; here, 547 the final unit of encoded output will be seven characters followed 548 by one "=" padding character. 550 Because it is used only for padding at the end of the data, the 551 occurrence of any "=" characters may be taken as evidence that the 552 end of the data has been reached (without truncation in transit). 553 No such assurance is possible, however, when the number of octets 554 transmitted was a multiple of three and no "=" characters are 555 present. 557 Any characters outside of the base32 alphabet are to be ignored in 558 base32-encoded data. 560 Full Copyright Statement 562 Copyright (C) The Internet Society (2000). All Rights Reserved. 564 This document and translations of it may be copied and furnished to 565 others, and derivative works that comment on or otherwise explain it 566 or assist in its implementation may be prepared, copied, published 567 and distributed, in whole or in part, without restriction of any 568 kind, provided that the above copyright notice and this paragraph 569 are included on all such copies and derivative works. However, this 570 document itself may not be modified in any way, such as by removing 571 the copyright notice or references to the Internet Society or other 572 Internet organizations, except as needed for the purpose of 573 developing Internet standards in which case the procedures for 574 copyrights defined in the Internet Standards process must be 575 followed, or as required to translate it into languages other than 576 English. 578 The limited permissions granted above are perpetual and will not be 579 revoked by the Internet Society or its successors or assigns. 581 This document and the information contained herein is provided on an 582 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 583 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 584 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 585 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 586 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 588 Acknowledgement 590 Funding for the RFC editor function is currently provided by the 591 Internet Society.