Network Working Group B. Laurie Internet-Draft G. Sisson Intended status: Standards Track R. Arends Expires: July 5, 2007 Nominet D. Blacka VeriSign, Inc. January 2007 DNSSEC Hashed Authenticated Denial of Existence draft-ietf-dnsext-nsec3-10 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Domain Name System Security Extensions (DNSSEC) introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual Laurie, et al. Expires July 5, 2007 [Page 1] Internet-Draft nsec3 January 2007 expansion of delegation-centric zones. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 7 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 8 3.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 9 3.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.6. Hash Length . . . . . . . . . . . . . . . . . . . . . 9 3.1.7. Next Hashed Owner Name . . . . . . . . . . . . . . . . 9 3.1.8. Type Bit Maps . . . . . . . . . . . . . . . . . . . . 10 3.2. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 10 3.2.1. Type Bit Maps Encoding . . . . . . . . . . . . . . . . 11 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 12 4. The NSEC3PARAM Record . . . . . . . . . . . . . . . . . . . . 12 4.1. RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Hash Algorithm . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Flag Fields . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. Iterations . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Salt Length . . . . . . . . . . . . . . . . . . . . . 13 4.1.5. Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 14 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 14 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 15 6. Opt-Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Authoritative Server Considerations . . . . . . . . . . . . . 16 7.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 18 7.2.1. Closest Encloser Proof . . . . . . . . . . . . . . . . 18 7.2.2. Name Error Responses . . . . . . . . . . . . . . . . . 19 7.2.3. No Data Responses, QTYPE is not DS . . . . . . . . . . 19 7.2.4. No Data Responses, QTYPE is DS . . . . . . . . . . . . 19 7.2.5. Wildcard No Data Responses . . . . . . . . . . . . . . 20 7.2.6. Wildcard Answer Responses . . . . . . . . . . . . . . 20 7.2.7. Referrals to Unsigned Subzones . . . . . . . . . . . . 20 7.2.8. Responding to Queries for NSEC3 Owner Names . . . . . 20 7.2.9. Server Response to a Run-time Collision . . . . . . . 21 7.3. Secondary Servers . . . . . . . . . . . . . . . . . . . . 21 7.4. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 21 Laurie, et al. Expires July 5, 2007 [Page 2] Internet-Draft nsec3 January 2007 7.5. Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21 8. Validator Considerations . . . . . . . . . . . . . . . . . . . 23 8.1. Responses with Unknown Hash Types . . . . . . . . . . . . 23 8.2. Verifying NSEC3 RRs . . . . . . . . . . . . . . . . . . . 23 8.3. Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23 8.4. Validating Name Error Responses . . . . . . . . . . . . . 24 8.5. Validating No Data Responses, QTYPE is not DS . . . . . . 24 8.6. Validating No Data Responses, QTYPE is DS . . . . . . . . 24 8.7. Validating Wildcard No Data Responses . . . . . . . . . . 25 8.8. Validating Wildcard Answer Responses . . . . . . . . . . . 25 8.9. Validating Referrals to Unsigned Subzones . . . . . . . . 25 9. Resolver Considerations . . . . . . . . . . . . . . . . . . . 25 9.1. NSEC3 Resource Record Caching . . . . . . . . . . . . . . 26 9.2. Use of the AD Bit . . . . . . . . . . . . . . . . . . . . 26 10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26 10.1. Domain Name Length Restrictions . . . . . . . . . . . . . 26 10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 26 10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27 10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28 10.5. Transitioning a Signed Zone From NSEC3 to NSEC . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 12. Security Considerations . . . . . . . . . . . . . . . . . . . 29 12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 29 12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 29 12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 30 12.1.3. Using New or Unknown Hash Algorithms . . . . . . . . . 30 12.1.4. Using High Iteration Values . . . . . . . . . . . . . 30 12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 31 12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 13.1. Normative References . . . . . . . . . . . . . . . . . . . 32 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 33 Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 38 B.1. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 38 B.2. No Data Error . . . . . . . . . . . . . . . . . . . . . . 40 B.2.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 41 B.3. Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 42 B.4. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 44 B.5. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46 B.6. DS Child Zone No Data Error . . . . . . . . . . . . . . . 47 Appendix C. Special Considerations . . . . . . . . . . . . . . . 48 C.1. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 48 C.2. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49 C.2.1. Avoiding Hash Collisions During Generation . . . . . . 49 C.2.2. Second Preimage Requirement Analysis . . . . . . . . . 49 C.2.3. Possible Hash Value Truncation Method . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Laurie, et al. Expires July 5, 2007 [Page 3] Internet-Draft nsec3 January 2007 Intellectual Property and Copyright Statements . . . . . . . . . . 52 Laurie, et al. Expires July 5, 2007 [Page 4] Internet-Draft nsec3 January 2007 1. Introduction 1.1. Rationale The DNS Security Extensions included the NSEC RR to provide authenticated denial of existence. Though the NSEC RR meets the requirements for authenticated denial of existence, it introduces a side-effect in that the contents of a zone can be enumerated. This property introduces undesired policy issues. An enumerated zone can be used, for example, as a source of probable e-mail addresses for spam, or as a key for multiple WHOIS queries to reveal registrant data which many registries may have legal obligations to protect. Many registries therefore prohibit copying of their zone data; however, the use of NSEC RRs renders these policies unenforceable. A second problem is that the cost to cryptographically secure delegations to unsigned zones is high for large delegation-centric zones and zones where insecure delegations will be updated rapidly. For these zones, the costs of maintaining the NSEC RR chain may be extremely high relative to the gain of cryptographically authenticating existence of unsecured zones. This document presents the NSEC3 Resource Record which can be used as an alternative to NSEC to mitigate these issues. Earlier work to address these issues include [I-D.jas-dnsext-no], [I-D.ietf-dnsext-dnssec-opt-in] and [I-D.laurie-dnsext-nsec2v2]. 1.2. Reserved Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Terminology The reader is assumed to be familiar with the basic DNS and DNSSEC concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], [RFC4035] and subsequent RFCs that update them: [RFC2136], [RFC2181] and [RFC2308]. The following terminology is used throughout this document: Laurie, et al. Expires July 5, 2007 [Page 5] Internet-Draft nsec3 January 2007 Zone enumeration: the practice of discovering the full content of a zone via successive queries. Zone enumeration was non-trivial prior to the introduction of DNSSEC. Original owner name: the owner name corresponding to a hashed owner name. Hashed owner name: the owner name created after applying the hash function to an owner name. Hash order: the order in which hashed owner names are arranged according to their numerical value, treating the leftmost (lowest numbered) octet as the most significant octet. Note that this order is the same as the canonical DNS name order specified in [RFC4034] when the hashed owner names are in base32 encoded with Extended Hex Alphabet [RFC4648]. Empty non-terminal: a domain name that owns no resource records, but has one or more subdomains that do. Delegation: an NS RRSet with a name different from the current zone apex (non-zone-apex), signifying a delegation to a child zone. Secure delegation: a name containing a delegation (NS RRSet), and a signed DS RRSet, signifying a delegation to a signed child zone. Insecure delegation: a name containing a delegation (NS RRSet), but lacking a DS RRSet, signifying a delegation to an unsigned child zone. Opt-Out NSEC3 resource record: an NSEC3 resource record which has the Opt-Out flag set to 1. Opt-Out zone: a zone with at least one Opt-Out NSEC3 RR. Closest encloser: the longest existing ancestor of a name. See also section 3.3.1 of [RFC4592]. Closest provable encloser: the longest ancestor of a name that can be proven to exist. Note that this is only different from the closest encloser in an Opt-Out zone. Next closer name: the name one label longer than the closest provable encloser of a name. Laurie, et al. Expires July 5, 2007 [Page 6] Internet-Draft nsec3 January 2007 Base32: the "Base 32 Encoding with Extended Hex Alphabet" as specified in [RFC4648]. Note that trailing padding characters ("=") are not used in the NSEC3 specification. To cover: An NSEC3 RR is said to "cover" a name if the hash of the name or "next closer" name falls between the owner name and the next hashed owner name of the NSEC3. In other words, if it proves the nonexistence of the name, either directly or by proving the nonexistence of an ancestor of the name. To match: An NSEC3 RR is said to "match" a name if the owner name of the NSEC3 RR is the same as the hashed owner name of that name. 2. Backwards Compatibility This specification describes a protocol change that is not generally backwards compatible with [RFC4033], [RFC4034] and [RFC4035]. In particular, security-aware resolvers that are unaware of this specification (NSEC3-unaware resolvers) may fail to validate the responses introduced by this document. In order to aid deployment, this specification uses a signaling technique to prevent NSEC3-unaware resolvers from attempting to validate responses from NSEC3-signed zones. This specification allocates two new DNSKEY algorithm identifiers for this purpose. Algorithm XX, DSA-NSEC3 [### RFC-editor update required, temporarily, XX=131] is an alias for algorithm 3, DSA. Algorithm YY, RSASHA1-NSEC3 [### RFC-editor update required, temporarily, YY=133] is an alias for algorithm 5, RSASHA1. These are not new algorithms, they are simply additional identifiers for the existing algorithms. Zones signed according to this specification MUST only use these algorithm identifiers for their DNSKEY RRs. Because these new identifiers will be unknown algorithms to existing, NSEC3-unaware resolvers, those resolvers will then treat responses from the NSEC3 signed zone as insecure, as detailed in [RFC4035], section 5.2. Security aware resolvers that are aware of this specification MUST recognize the new algorithm identifiers and treat them as equivalent to the algorithms that they alias. A methodology for transitioning from a DNSSEC signed zone to a zone signed using NSEC3 is discussed in Section 10.4. Laurie, et al. Expires July 5, 2007 [Page 7] Internet-Draft nsec3 January 2007 3. The NSEC3 Resource Record The NSEC3 Resource Record (RR) provides authenticated denial of existence for DNS Resource Record Sets. The NSEC3 RR lists RR types present at the original owner name of the NSEC3 RR. It includes the next hashed owner name in the hash order of the zone. The complete set of NSEC3 RRs in a zone indicates which RRSets exist for the original owner name of the RR and form a chain of hashed owner names in the zone. This information is used to provide authenticated denial of existence for DNS data. To provide protection against zone enumeration, the owner names used in the NSEC3 RR are cryptographic hashes of the original owner name prepended as a single label to the name of the zone. The NSEC3 RR indicates which hash function is used to construct the hash, which salt is used, and how many iterations of the hash function are performed over the original owner name. The hashing technique is described fully in Section 5. Hashed owner names of unsigned delegations may be excluded from the chain. An NSEC3 RR whose span covers the hash of an owner name or "next closer" name of an unsigned delegation is referred to as an Opt-Out NSEC3 RR and is indicated by the presence of a flag. The owner name for the NSEC3 RR is the base32 encoding of the hashed owner name prepended as a single label to the name of the zone. The type value for the NSEC3 RR is NN. [### RFC-editor update required, temporarily, NN=65324.] The NSEC3 RR RDATA format is class independent and is described below. The class MUST be the same as the class of the original owner name. The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching [RFC2308]. 3.1. RDATA Fields 3.1.1. Hash Algorithm The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value. The values for this field are defined in the NSEC3 hash algorithm registry, described in Section 11. Laurie, et al. Expires July 5, 2007 [Page 8] Internet-Draft nsec3 January 2007 3.1.2. Flags The Flags field contains 8 one-bit flags that can be used to indicate different processing. All undefined flags must be zero. The only flag defined by this specification is the Opt-Out flag. 3.1.2.1. Opt-Out Flag The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned delegations. It is the least significant bit in the Flags field. See Section 6 for details about the use of this flag. 3.1.3. Iterations The Iterations field defines the number of additional times the hash function has been performed. More iterations result in greater resiliency of the hash value against dictionary attacks, but at a higher computational cost for both the server and resolver. See Section 5 for details of the use of this field, and Section 10.3 for limitations on the value. 3.1.4. Salt Length The Salt Length field defines the length of the Salt field in octets, ranging in value from 0 to 255. 3.1.5. Salt The Salt field is appended to the original owner name before hashing in order to defend against pre-calculated dictionary attacks. See Section 5 for details on how the salt is used. 3.1.6. Hash Length The Hash Length field defines the length of the Next Hashed Owner Name field, ranging in value from 1 to 255 octets. 3.1.7. Next Hashed Owner Name The Next Hashed Owner Name field contains the next hashed owner name in hash order. This value is in binary format. Given the ordered set of all hashed owner names, the Next Hashed Owner Name field contains the hash of an owner name that immediately follows the owner name of the given NSEC3 RR. The value of the Next Hashed Owner Name field in the last NSEC3 RR in the zone is the same as the hashed owner name of the first NSEC3 RR in the zone in hash order. Note that, unlike the owner name of the NSEC3 RR, the value of this field does not contain the appended zone name. Laurie, et al. Expires July 5, 2007 [Page 9] Internet-Draft nsec3 January 2007 3.1.8. Type Bit Maps The Type Bit Maps field identifies the RRSet types which exist at the original owner name of the NSEC3 RR. 3.2. NSEC3 RDATA Wire Format The RDATA of the NSEC3 RR is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Alg. | Flags | Iterations | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt Length | Salt / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Length | Next Hashed Owner Name / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Type Bit Maps / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hash Algorithm is a single octet. Flags field is a single octet, the Opt-Out flag is the least significant bit, as shown below: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | |O| +-+-+-+-+-+-+-+-+ Iterations is represented as a 16-bit unsigned integer, with the most significant bit first. Salt Length is represented as an unsigned octet. Salt Length represents the length of the Salt field in octets. If the value is zero, the following Salt field is omitted. Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field. Hash Length is represented as an unsigned octet. Hash Length represents the length of the Next Hashed Owner Name field in octets. The next hashed owner name is not base32 encoded, unlike the owner name of the NSEC3 RR. It is the unmodified binary hash value. It does not include the name of the containing zone. The length of this Laurie, et al. Expires July 5, 2007 [Page 10] Internet-Draft nsec3 January 2007 field is determined by the preceding Hash Length field. 3.2.1. Type Bit Maps Encoding The encoding of the Type Bit Maps field is the same as that used by the NSEC RR, described in [RFC4034]. It is explained and clarified here for clarity. The RR type space is split into 256 window blocks, each representing the low-order 8 bits of the 16-bit RR type space. Each block that has at least one active RR type is encoded using a single octet window number (from 0 to 255), a single octet bitmap length (from 1 to 32) indicating the number of octets used for the bitmap of the window block, and up to 32 octets (256 bits) of bitmap. Blocks are present in the NSEC3 RR RDATA in increasing numerical order. Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ where "|" denotes concatenation. Each bitmap encodes the low-order 8 bits of RR types within the window block, in network bit order. The first bit is bit 0. For window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS), and so forth. For window block 1, bit 1 corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to 1, it indicates that an RRSet of that type is present for the original owner name of the NSEC3 RR. If a bit is set to 0, it indicates that no RRSet of that type is present for the original owner name of the NSEC3 RR. Since bit 0 in window block 0 refers to the non-existing RR type 0, it MUST be set to 0. After verification, the validator MUST ignore the value of bit 0 in window block 0. Bits representing Meta-TYPEs or QTYPEs as specified in [RFC2929] (section 3.1) or within the range reserved for assignment only to QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in zone data. If encountered, they must be ignored upon reading. Blocks with no types present MUST NOT be included. Trailing zero octets in the bitmap MUST be omitted. The length of the bitmap of each block is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the original owner name of the NSEC3 RR. Trailing octets not specified MUST be interpreted as zero octets. Laurie, et al. Expires July 5, 2007 [Page 11] Internet-Draft nsec3 January 2007 3.3. Presentation Format The presentation format of the RDATA portion is as follows: o The Hash Algorithm field is represented as an unsigned decimal integer. The value has a maximum of 255. o The Flags field is represented as an unsigned decimal integer. The value has a maximum of 255. o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive. o The Salt Length field is not represented. o The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequence. The Salt field is represented as "-" (without the quotes) when the Salt Length field has value 0. o The Hash Length field is not represented. o The Next Hashed Owner Name field is represented as an unpadded sequence of case-insensitive base32 digits, without whitespace. o The Type Bit Maps field is represented as a sequence of RR type mnemonics. When the mnemonic is not known, the TYPE representation as described in [RFC3597] (section 5) MUST be used. 4. The NSEC3PARAM Record The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm, flags, iterations and salt) needed to calculate hashed owner names. The presence of an NSEC3PARAM RR at a zone apex indicates that the specified parameters may be used by authoritative servers to choose an appropriate set of NSEC3 RRs for negative responses. If an NSEC3PARAM RR is present at the apex of a zone with a Flags field value of zero, then there MUST be an NSEC3 using the same hash algorithm, iterations and salt parameters present at every hashed owner name in the zone. That is, the zone MUST contain a complete set of NSEC3 RRs with the same hash algorithm, iterations and salt parameters. The owner name for the NSEC3PARAM RR is the name of the zone apex. The type value for the NSEC3PARAM RR is MM. [### RFC-editor update Laurie, et al. Expires July 5, 2007 [Page 12] Internet-Draft nsec3 January 2007 required, temporarily, MM=65325.] The NSEC3PARAM RR RDATA format is class independent and is described below. The class MUST be the same as the NSEC3 RRs to which this RR refers. 4.1. RDATA Fields The RDATA for this RR mirrors the first four fields in the NSEC3 RR. 4.1.1. Hash Algorithm The Hash Algorithm field identifies the cryptographic hash algorithm used to construct the hash-value. The acceptable values are the same as the corresponding field in the NSEC3 RR. 4.1.2. Flag Fields The Opt-Out flag is not used and is set to zero. All other flags reserved are for future use, and must be zero. NSEC3PARAM RRs with a Flags field value other than zero MUST be ignored. 4.1.3. Iterations The Iterations field defines the number of additional times the hash is performed. Its acceptable values are the same as the corresponding field in the NSEC3 RR. 4.1.4. Salt Length The Salt Length field defines the length of the salt in octets, ranging in value from 0 to 255. 4.1.5. Salt The Salt field is appended to the original owner name before hashing. Laurie, et al. Expires July 5, 2007 [Page 13] Internet-Draft nsec3 January 2007 4.2. NSEC3PARAM RDATA Wire Format The RDATA of the NSEC3PARAM RR is as shown below: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash Alg. | Flags | Iterations | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt Length | Salt / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hash Algorithm is a single octet. Flags field is a single octet. Iterations is represented as a 16-bit unsigned integer, with the most significant bit first. Salt Length is represented as an unsigned octet. Salt Length represents the length of the following Salt field in octets. If the value is zero, the Salt field is omitted. Salt, if present, is encoded as a sequence of binary octets. The length of this field is determined by the preceding Salt Length field. 4.3. Presentation Format The presentation format of the RDATA portion is as follows: o The Hash Algorithm field is represented as an unsigned decimal integer. The value has a maximum of 255. o The Flags field is represented as an unsigned decimal integer. The value has a maximum value of 255. o The Iterations field is represented as an unsigned decimal integer. The value is between 0 and 65535, inclusive. o The Salt Length field is not represented. o The Salt field is represented as a sequence of case-insensitive hexadecimal digits. Whitespace is not allowed within the sequences. This field is represented as "-" (without the quotes) when the Salt Length field is zero. Laurie, et al. Expires July 5, 2007 [Page 14] Internet-Draft nsec3 January 2007 5. Calculation of the Hash The hash calculation uses three of the NSEC3 RDATA fields: Hash Algorithm, Salt, and Iterations. Define H(x) to be the hash of x using the Hash Algorithm selected by the NSEC3 RR, k to be the number of Iterations, and || to indicate concatenation. Then define: IH(salt, x, 0) = H(x || salt), and IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0 Then the calculated hash of an owner name is IH(salt, owner name, iterations), where the owner name is in the canonical form, defined as: The wire format of the owner name where: 1. The owner name is fully expanded (no DNS name compression) and fully qualified; 2. All uppercase US-ASCII letters are replaced by the corresponding lowercase US-ASCII letters; 3. If the owner name is a wildcard name, the owner name is in its original unexpanded form, including the "*" label (no wildcard substitution); This form is as defined in section 6.2 of [RFC4034]. 6. Opt-Out In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS RRSets at delegation points are not signed and may be accompanied by a DS RRSet. With the Opt-Out bit clear, the security status of the child zone is determined by the presence or absence of this DS RRSet, cryptographically proven by the signed NSEC3 RR at the hashed owner name of the delegation. Setting the Opt-Out flag modifies this by allowing insecure delegations to exist within the signed zone without a corresponding NSEC3 RR at the hashed owner name of the delegation. An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the owner name or "next closer" name of the delegation is between the owner name of the NSEC3 RR and the next hashed owner name. Laurie, et al. Expires July 5, 2007 [Page 15] Internet-Draft nsec3 January 2007 An Opt-Out NSEC3 RR does not assert the existence or non-existence of the insecure delegations that it may cover. This allows for the addition or removal of these delegations without recalculating or re- signing RRs in the NSEC3 RR chain. However, Opt-Out NSEC3 RRs do assert the (non)existence of other, authoritative RRSets. An Opt-Out NSEC3 RR MAY have the same original owner name as an insecure delegation. In this case, the delegation is proven insecure by the lack of a DS bit in the type map and the signed NSEC3 RR does assert the existence of the delegation. Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and non-Opt-Out NSEC3 RRs. If an NSEC3 RR is not Opt-Out, there MUST NOT be any hashed owner names of insecure delegations (nor any other RRs) between it and the name indicated by the next hashed owner name in the NSEC3 RDATA. If it is Opt-Out, it MUST only cover hashed owner names or hashed "next closer" names of insecure delegations. The effects of the Opt-Out flag on signing, serving, and validating responses are covered in following sections. 7. Authoritative Server Considerations 7.1. Zone Signing Zones using NSEC3 must satisfy the following properties: o Each owner name within the zone that owns authoritative RRSets MUST have a corresponding NSEC3 RR. Owner names that correspond to unsigned delegations MAY have a corresponding NSEC3 RR. However, if there is not a corresponding NSEC3 RR, there MUST be an Opt-Out NSEC3 RR that covers the "next closer" name to the delegation. Other non-authoritative RRs are not represented by NSEC3 RRs. o Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR. o The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL value field in the zone SOA RR. o The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, except for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps. Laurie, et al. Expires July 5, 2007 [Page 16] Internet-Draft nsec3 January 2007 The following steps describe a method of proper construction of NSEC3 RRs. This is not the only such possible method. 1. For each unique original owner name in the zone add an NSEC3 RR. * If Opt-Out is being used, owner names of unsigned delegations MAY be excluded. * The owner name of the NSEC3 RR is the hash of the original owner name, prepended as a single label to the zone name. * The Next Hashed Owner Name field is left blank for the moment. * If Opt-Out is being used, set the Opt-Out bit to one. * For collision detection purposes, optionally keep track of the original owner name with the NSEC3 RR. * Additionally, for collision detection purposes, optionally create an additional NSEC3 RR corresponding to the original owner name with the asterisk label prepended (i.e., as if a wildcard existed as a child of this owner name) and keep track of this original owner name. Mark this NSEC3 RR as temporary. 2. For each RRSet at the original owner name, set the corresponding bit in the Type Bit Maps field. 3. If the difference in number of labels between the apex and the original owner name is greater than 1, additional NSEC3 RRs need to be added for every empty non-terminal between the apex and the original owner name. This process may generate NSEC3 RRs with duplicate hashed owner names. Optionally, for collision detection, track the original owner names of these NSEC3 RRs and create temporary NSEC3 RRs for wildcard collisions in a similar fashion to step 1. 4. Sort the set of NSEC3 RRs into hash order. 5. Combine NSEC3 RRs with identical hashed owner names by replacing them with a single NSEC3 RR with the Type Bit Maps field consisting of the union of the types represented by the set of NSEC3 RRs. If the original owner name was tracked, then collisions may be detected when combining, as all of the matching NSEC3 RRs should have the same original owner name. Discard any possible temporary NSEC3 RRs. 6. In each NSEC3 RR, insert the next hashed owner name by using the value of the next NSEC3 RR in hash order. The next hashed owner Laurie, et al. Expires July 5, 2007 [Page 17] Internet-Draft nsec3 January 2007 name of the last NSEC3 RR in the zone contains the value of the hashed owner name of the first NSEC3 RR in the hash order. 7. Finally, add an NSEC3PARAM RR with the same Hash Algorithm, Iterations and Salt fields to the zone apex. If a hash collision is detected, then a new salt has to be chosen and the signing process restarted. 7.2. Zone Serving This specification modifies DNSSEC-enabled DNS responses generated by authoritative servers. In particular, it replaces the use of NSEC RRs in such responses with NSEC3 RRs. In the following response cases, the NSEC RRs dictated by DNSSEC [RFC4035] are replaced with NSEC3 RRs that prove the same facts. Responses that would not contain NSEC RRs are unchanged by this specification. When returning responses containing multiple NSEC3 RRs, all of the NSEC3 RRs MUST use the same hash algorithm, iteration, and salt values. The Flags field value MUST be either zero or one. 7.2.1. Closest Encloser Proof For many NSEC3 responses a proof of the closest encloser is required. This is a proof that some ancestor of the QNAME is the closest encloser of QNAME. This proof consists of (up to) two different NSEC3 RRs: o An NSEC3 RR that matches the closest (provable) encloser. o An NSEC3 RR that covers the "next closer" name to the closest encloser. The first NSEC3 RR essentially proposes a possible closest encloser, and proves that the particular encloser does, in fact, exist. The second NSEC3 RR proves that the possible closest encloser is the closest, and proves that QNAME (and any ancestors between QNAME and the closest encloser) do not exist. These NSEC3 RRs are collectively referred to as the "closest encloser proof" in the subsequent descriptions. For example, the closest encloser proof for the nonexistent "alpha.beta.gamma.example." owner name might prove that Laurie, et al. Expires July 5, 2007 [Page 18] Internet-Draft nsec3 January 2007 "gamma.example." is the closest encloser. This response would contain the NSEC3 RR that matches "gamma.example.", and would also contain the NSEC3 RR that covers "beta.gamma.example." (which is the "next closer" name.) It is possible, when using Opt-Out (Section 6), to not be able to prove the actual closest encloser because it is, or is part of an insecure delegation covered by an Opt-Out span. In this case, instead of proving the actual closest encloser, the closest provable encloser is used. That is, the closest enclosing authoritative name is used instead. In this case, the set of NSEC3 RRs used for this proof is referred to as the "closest provable encloser proof." 7.2.2. Name Error Responses To prove the nonexistence of QNAME a closest encloser proof and an NSEC3 RR covering the (nonexistent) wildcard RR at the closest encloser MUST be included in the response. This collection of (up to) three NSEC3 RRs proves both that QNAME does not exist and that a wildcard that could have matched QNAME also does not exist. For example, if "gamma.example." is the closest provable encloser to QNAME, then a NSEC3 RR covering "*.gamma.example." is included in the authority section of the response. 7.2.3. No Data Responses, QTYPE is not DS The server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field. 7.2.4. No Data Responses, QTYPE is DS If there is an NSEC3 RR that matches QNAME, the server MUST return it in the response. The bits corresponding with DS and CNAME MUST NOT be set in the Type Bit Maps field of this NSEC3 RR. If no NSEC3 RR matches QNAME, the server MUST return a closest provable encloser proof for QNAME. The NSEC3 RR that covers the "next closer" name MUST have the Opt-Out bit set (note that this is true by definition - if the Opt-Out bit is not set, something has gone wrong). If a server is authoritative for both sides of a zone cut at QNAME, the server MUST return the proof from the parent side of the zone cut. Laurie, et al. Expires July 5, 2007 [Page 19] Internet-Draft nsec3 January 2007 7.2.5. Wildcard No Data Responses If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response MUST include a closest encloser proof for QNAME and MUST include the NSEC3 RR that matches the wildcard. This combination proves both that QNAME itself does not exist and that a wildcard that matches QNAME does exist. Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone wrong). 7.2.6. Wildcard Answer Responses If there is a wildcard match for QNAME and QTYPE, then, in addition to the expanded wildcard RRSet returned in the answer section of the response, proof that the wildcard match was valid must be returned. This proof is accomplished by proving that both QNAME does not exist, and that the closest encloser of the QNAME and the immediate ancestor of the wildcard are the same (i.e., the correct wildcard matched). To this end, the NSEC3 RR that covers the "next closer" name of the immediate ancestor of the wildcard MUST be returned. It is not necessary to return an NSEC3 RR that matches the closest encloser, as the existence of this closest encloser is proven by the presence of the expanded wildcard in the response. 7.2.7. Referrals to Unsigned Subzones If there is an NSEC3 RR that matches the delegation name, then that NSEC3 RR MUST be included in the response. The DS bit in the type bit maps of the NSEC3 RR MUST NOT be set. If the zone is Opt-Out, then there may not be an NSEC3 RR corresponding to the delegation. In this case, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. (Note that this will be the case unless something has gone wrong). 7.2.8. Responding to Queries for NSEC3 Owner Names The owner names of NSEC3 RRs are not represented in the NSEC3 RR chain like other owner names. As a result, each NSEC3 owner name is covered by another NSEC3 RR, effectively negating the existence of the NSEC3 RR. This is a paradox, since the existence of an NSEC3 RR can be proven by its RRSIG RRSet. If the following conditions are all true: Laurie, et al. Expires July 5, 2007 [Page 20] Internet-Draft nsec3 January 2007 o The QNAME equals the owner name of an existing NSEC3 RR, and o No RR types exist at the QNAME, nor at any descendant of QNAME. Then the response MUST be constructed as a Name Error response (Section 7.2.2). Or, in other words, the authoritative name server will act, as if the owner name of the NSEC3 RR did not exist. Note that NSEC3 RRs are returned as a result of an AXFR or IXFR query. 7.2.9. Server Response to a Run-time Collision If the hash of a non-existing QNAME collides with the owner name of an existing NSEC3 RR, then the server will be unable to return a response that proves that QNAME does not exist. In this case, the server MUST return a response with an RCODE of 2 (server failure). Note that with the hash algorithm specified in this document, SHA-1, such collisions are highly unlikely. 7.3. Secondary Servers Secondary servers (and perhaps other entities) need to reliably determine which NSEC3 parameters (i.e., hash, salt and iterations) are present at every hashed owner name, in order to be able to choose an appropriate set of NSEC3 RRs for negative responses. This is indicated by an NSEC3PARAM RR present at the zone apex. If there are multiple NSEC3PARAM RRs present, there are multiple valid NSEC3 chains present. The server must choose one of them, but may use any criteria to do so. 7.4. Zones Using Unknown Hash Algorithms Zones that are signed according to this specification, but are using an unrecognized NSEC3 hash algorithm value, cannot be effectively served. Such zones SHOULD be rejected when loading. Servers SHOULD respond with RCODE=2 (server failure) responses when handling queries that would fall under such zones. 7.5. Dynamic Update A zone signed using NSEC3 may accept dynamic updates [RFC2136]. However, NSEC3 introduces some special considerations for dynamic updates. Adding and removing names in a zone MUST account for the creation or Laurie, et al. Expires July 5, 2007 [Page 21] Internet-Draft nsec3 January 2007 removal of empty non-terminals. o When removing a name with a corresponding NSEC3, checks must be made to remove any NSEC3 RRs corresponding with possible empty non-terminals created by the name. Note that more than one name may be asserting the existence of a particular empty non-terminal. o When adding a name that requires adding an NSEC3 RR, NSEC3 RRs MUST also be added for any empty non-terminals that are created. That is, if there is not an existing NSEC3 RR matching an empty non-terminal, it must be created and added. The presence of Opt-Out in a zone means that some additions or delegations of names will not require changes to the NSEC3 RRs in a zone. o When removing a delegation RRSet, if that delegation does not have a matching NSEC3 RR, then it was opted out. In this case, nothing further needs to be done. o When adding a delegation RRSet, if the "next closer" name of the delegation is covered by an existing Opt-Out NSEC3 RR, then the delegation MAY be added without modifying the NSEC3 RRs in the zone. The presence of Opt-Out in a zone means that when adding or removing NSEC3 RRs, the value of the Opt-Out flag that should be set in new or modified NSEC3 RRs is ambiguous. Servers SHOULD follow this set of basic rules to resolve the ambiguity. The central concept to these rules is that the state of the Opt-Out flag of the covering NSEC3 RR is preserved. o When removing an NSEC3 RR, the value of the Opt-Out flag for the previous NSEC3 RR (the one whose next hashed owner name is modified) should not be changed. o When adding an NSEC3 RR, the value of the Opt-Out flag is set to the value of the Opt-Out flag of the NSEC3 RR that previously covered the owner name of the NSEC3 RR. That is, the now previous NSEC3 RR. If the zone in question is consistent with its use of the Opt-Out flag (that is, all NSEC3 RRs in the zone have the same value for the flag) then these rules will retain that consistency. If the zone is not consistent in the use of the flag (i.e., a partially Opt-Out zone), then these rules will not retain the same pattern of use of the Opt-Out flag. Laurie, et al. Expires July 5, 2007 [Page 22] Internet-Draft nsec3 January 2007 For zones that partially use the Opt-Out flag, if there is a logical pattern for that use, the pattern could be maintained by using a local policy on the server. 8. Validator Considerations 8.1. Responses with Unknown Hash Types A validator MUST ignore NSEC3 RRs with unknown hash types. The practical result of this is that responses containing only such NSEC3 RRs will generally be considered bogus. 8.2. Verifying NSEC3 RRs A validator MUST ignore NSEC3 RRs with a Flag fields value other than zero or one. A validator MAY treat a response as bogus if the response contains NSEC3 RRs that contain different values for hash algorithm, iterations, or salt from each other. 8.3. Closest Encloser Proof In order to verify a closest encloser proof, the validator MUST find the longest name, X, such that o X is an ancestor of QNAME that is matched by an NSEC3 RR present in the response. This is a candidate for the closest encloser. And: o The name one label longer than X (but still an ancestor of--or equal to--QNAME) is covered by an NSEC3 RR present in the response. One possible algorithm for verifying this proof is as follows: 1. Set SNAME=QNAME. Clear the flag. 2. Check whether SNAME exists: * If there is no NSEC3 RR in the response that matches SNAME (i.e., an NSEC3 RR whose owner name is the same as the hash of SNAME, prepended as a single label to the zone name), clear the flag. * If there is an NSEC3 RR in the response that covers SNAME, set the flag. Laurie, et al. Expires July 5, 2007 [Page 23] Internet-Draft nsec3 January 2007 * If there is a matching NSEC3 RR in the response and the flag was set, then the proof is complete, and SNAME is the closest encloser. * If there is a matching NSEC3 RR in the response, but the flag is not set, then the response is bogus. 3. Truncate SNAME by one label from the left, go to step 2. Once the closest encloser has been discovered, the validator MUST check that the NSEC3 RR that has the closest encloser as the original owner name is from the proper zone. The DNAME type bit must not be set and the NS type bit may only be set if the SOA type bit is set. If this is not the case, it would be an indication that an attacker is using them to falsely deny the existence of RRs for which the server is not authoritative. In the following descriptions, the phrase "a closest (provable) encloser proof for X" means that the algorithm above (or an equivalent algorithm) proves that X does not exist by proving that an ancestor of X is its closest encloser. 8.4. Validating Name Error Responses A validator MUST verify that there is a closest encloser proof for QNAME present in the response and that there is an NSEC3 RR that covers the wildcard at the closest encloser (i.e., the name formed by prepending the asterisk label to the closest encloser.) 8.5. Validating No Data Responses, QTYPE is not DS The validator MUST verify that an NSEC3 RR that matches QNAME is present and that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field. 8.6. Validating No Data Responses, QTYPE is DS If there is an NSEC3 RR that matches QNAME present in the response, then that NSEC3 RR MUST NOT have the bits corresponding to DS and CNAME set in its Type Bit Maps field. If there is no such NSEC3 RR, then the validator MUST verify that a closest provable encloser proof for QNAME is present in the response, and that the NSEC3 RR that covers the "next closer" name has the Opt- Laurie, et al. Expires July 5, 2007 [Page 24] Internet-Draft nsec3 January 2007 Out bit set. 8.7. Validating Wildcard No Data Responses The validator MUST verify a closest encloser proof for QNAME and MUST find an NSEC3 RR present in the response that matches the wildcard name generated by prepending the asterisk label to the closest encloser. Furthermore, the bits corresponding to both QTYPE and CNAME MUST NOT be set in the wildcard matching NSEC3 RR. 8.8. Validating Wildcard Answer Responses The verified wildcard answer RRSet in the response provides the validator with a (candidate) closest encloser for QNAME. This closest encloser is the immediate ancestor to the generating wildcard. Validators MUST verify that there is an NSEC3 RR that covers the "next closer" name to QNAME present in the response. This proves that QNAME itself did not exist and that the correct wildcard was used to generate the response. 8.9. Validating Referrals to Unsigned Subzones The delegation name in a referral is the owner name of the NS RRSet present in the authority section of the referral response. If there is an NSEC3 RR present in the response that matches the delegation name, then the validator MUST ensure that the NS bit is set and that the DS bit is not set in the Type Bit Maps field of the NSEC3 RR. The validator MUST also ensure that the NSEC3 RR is from the correct (i.e., parent) zone. This is done by ensuring that the SOA bit is not set in the Type Bit Maps field of this NSEC3 RR. Note that the presence of an NS bit implies the absence of a DNAME bit, so there is no need to check for the DNAME bit in the Type Bit Maps field of the NSEC3 RR. If there is no NSEC3 RR present that matches the delegation name, then the validator MUST verify a closest provable encloser proof for the delegation name. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. 9. Resolver Considerations Laurie, et al. Expires July 5, 2007 [Page 25] Internet-Draft nsec3 January 2007 9.1. NSEC3 Resource Record Caching Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs when returning responses that contain them. In DNSSEC [RFC4035], in many cases it is possible to find the correct NSEC RR to return in a response by name (e.g., when returning a referral, the NSEC RR will always have the same owner name as the delegation.) With this specification, that will not be true, nor will a cache be able to calculate the name(s) of the appropriate NSEC3 RR(s). Implementations may need to use new methods for caching and retrieving NSEC3 RRs. 9.2. Use of the AD Bit The AD bit, as defined by [RFC4035], MUST NOT be set when returning a response containing a closest (provable) encloser proof in which the NSEC3 RR that covers the "next closer" name has the Opt-Out bit set. This rule is based on what this closest encloser proof actually proves: names that would be covered by the Opt-Out NSEC3 RR may or may not exist as insecure delegations. As such, not all the data in responses containing such closest encloser proofs will have been cryptographically verified, so the AD bit cannot be set. 10. Special Considerations 10.1. Domain Name Length Restrictions Zones signed using this specification have additional domain name length restrictions imposed upon them. In particular, zones with names that, when converted into hashed owner names, exceed the 255 octet length limit imposed by [RFC1035] cannot use this specification. The actual maximum length of a domain name in a particular zone depends on both the length of the zone name (versus the whole domain name) and the particular hash function used. 10.2. DNAME at the Zone Apex The DNAME specification [RFC2672] section 3 has a 'no-descendants' limitation. If a DNAME RR is present at node N, there MUST be no data at any descendant of N. If N is the apex of the zone, there will be NSEC3 and RRSIG types present at descendants of N. This specification updates the DNAME specification to allow NSEC3 and RRSIG types at descendants of the Laurie, et al. Expires July 5, 2007 [Page 26] Internet-Draft nsec3 January 2007 apex regardless of the existence of DNAME at the apex. 10.3. Iterations Setting the number of iterations used allows the zone owner to choose the cost of computing a hash, and so the cost of generating a dictionary. Note that this is distinct from the effect of salt, which prevents the use of a single precomputed dictionary for all time. Obviously the number of iterations also affects the zone owner's cost of signing and serving the zone as well as the validator's cost of verifying responses from the zone. We therefore impose an upper limit on the number of iterations. We base this on the number of iterations that approximates the cost of verifying an RRSet. The limits, therefore, are based on the size of the smallest zone signing key, rounded up to the nearest table value (or rounded down if the key is larger than the largest table value.) A zone owner MUST NOT use a value higher than shown in the table below for iterations for the given key size. A resolver MAY treat a response with a higher value as insecure, after the validator has verified that the signature over the NSEC3 RR is correct. +--------------+------------+ | RSA Key Size | Iterations | +--------------+------------+ | 1024 | 150 | | 2048 | 500 | | 4096 | 2,500 | +--------------+------------+ +--------------+------------+ | DSA Key Size | Iterations | +--------------+------------+ | 1024 | 1,500 | | 2048 | 5,000 | +--------------+------------+ This table is based on 150,000 SHA-1 calculations per second, 1000 RSA verifications per second for 1024 bit keys, 300 verifications per second for 2048 bit keys, 60 verifications per second for 4096 bit keys, 100 DSA verifications per second for 1024 bit keys and 30 verifications per second for 2048 bit keys. Laurie, et al. Expires July 5, 2007 [Page 27] Internet-Draft nsec3 January 2007 10.4. Transitioning a Signed Zone from NSEC to NSEC3 When transitioning an already signed and trusted zone to this specification, care must be taken to prevent client validation failures during the process. The basic procedure is as follows: 1. Transition all DNSKEYs to DNSKEYs using the algorithm aliases described in Section 2. The actual method for safely and securely changing the DNSKEY RRSet of the zone is outside the scope of this specification. However, the end result MUST be that all DS RRs in the parent use the specified algorithm aliases. After this transition is complete, all NSEC3-unaware clients will treat the zone as insecure. At this point, the authoritative server still returns negative and wildcard responses that contain NSEC RRs. 2. Add signed NSEC3 RRs to the zone, either incrementally or all at once. If adding incrementally, then the last RRSet added MUST be the NSEC3PARAM RRSet. 3. Upon the addition of the NSEC3PARAM RRSet, the server switches to serving negative and wildcard responses with NSEC3 RRs according to this specification. 4. Remove the NSEC RRs either incrementally or all at once. 10.5. Transitioning a Signed Zone From NSEC3 to NSEC To safely transition back to a DNSSEC [RFC4035] signed zone, simply reverse the procedure above: 1. Add NSEC RRs incrementally or all at once. 2. Remove the NSEC3PARAM RRSet. This will signal the server to use the NSEC RRs for negative and wildcard responses. 3. Remove the NSEC3 RRs either incrementally or all at once. 4. Transition all of the DNSKEYs to DNSSEC algorithm identifiers. After this transition is complete, all NSEC3-unaware clients will treat the zone as secure. Laurie, et al. Expires July 5, 2007 [Page 28] Internet-Draft nsec3 January 2007 11. IANA Considerations This document updates the IANA registry "DOMAIN NAME SYSTEM PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub- registry "TYPES", by defining two new types. Section 3 defines the NSEC3 RR type NN, (value 50 suggested). Section 4 defines the NSEC3PARAM RR type MM (value 51 suggested). This document updates the IANA registry "DNS SECURITY ALGORITHM NUMBERS - per [RFC4035]" http://www.iana.org/assignments/dns-sec-alg-numbers]. Section 2 defines the aliases DSA-NSEC3 (XX) and RSASHA1-NSEC3 (YY) for respectively existing registrations DSA and RSASHA1. [### IMPORTANT RFC EDITOR INSTRUCTION: After the IANA allocation has been done the examples in the Appendix will need to be updated. The signature generation algorithm includes the requested RR types as input. The RFC editor should not edit the Appendices before the IANA typecode has been assigned and the examples have been regenerated by the editor.] Finally, this document creates a new IANA registry for NSEC3 hash algorithms. This registry should be named "DNSSEC NSEC3 Hash Algorithms". The initial contents of this registry are: 0 is Reserved 1 is SHA-1. 2-255 Available for assignment Assignment of additional NSEC3 hash algorithms in this registry requires IETF Standards Action [RFC2434]. 12. Security Considerations 12.1. Hashing Considerations 12.1.1. Dictionary Attacks The NSEC3 RRs are still susceptible to dictionary attacks (i.e. the attacker retrieves all the NSEC3 RRs, then calculates the hashes of all likely domain names, comparing against the hashes found in the NSEC3 RRs, and thus enumerating the zone). These are substantially Laurie, et al. Expires July 5, 2007 [Page 29] Internet-Draft nsec3 January 2007 more expensive than enumerating the original NSEC RRs would have been, and in any case, such an attack could also be used directly against the name server itself by performing queries for all likely names, though this would obviously be more detectable. The expense of this off-line attack can be chosen by setting the number of iterations in the NSEC3 RR. Zones are also susceptible to a pre-calculated dictionary attack -- that is, a list of hashes for all likely names is computed once, then NSEC3 RR is scanned periodically and compared against the precomputed hashes. This attack is prevented by changing the salt on a regular basis. 12.1.2. Collisions Hash collisions between QNAME and the owner name of an NSEC3 RR may occur. When they do, it will be impossible to prove the non- existence of the colliding QNAME. However, with SHA-1, this is highly unlikely (on the order of 1 in 2^160). Note that DNSSEC already relies on the presumption that a cryptographic hash function is second pre-image resistant, since these hash functions are used for generating and validating signatures and DS RRs. 12.1.3. Using New or Unknown Hash Algorithms Since validators are instructed to ignore NSEC3 RRs with unknown hash algorithms, simply using a new or unknown hash algorithm directly will lead to validation failures with clients that understand NSEC3 but do not understand the hash algorithm. To prevent this, care must be taken to protect such clients. It is suggested that a similar technique to the one being used in this specification to protect older clients be employed (see Section 2.) 12.1.4. Using High Iteration Values Since validators should treat responses containing NSEC3 RRs with high iteration values as insecure, presence of just one signed NSEC3 RR with a high iteration value in a zone provides attackers with a possible downgrade attack. The attack is simply to remove any existing NSEC3 RRs from a response, and replace or add a single (or multiple) NSEC3 RR that uses a high iterations value to the response. Validators will then be forced to treat the response as insecure. This attack would be effective only when all of following conditions are met: Laurie, et al. Expires July 5, 2007 [Page 30] Internet-Draft nsec3 January 2007 o There is at least one signed NSEC3 RR that uses a high iterations value present in the zone. o The attacker has access to one or more of these NSEC3 RRs. This is trivially true when the NSEC3 RRs with high iterations values are being returned in typical responses, but may also be true if the attacker can access the zone via AXFR or IXFR queries, or any other methodology. Using a high number of iterations also introduces an additional denial-of-service opportunity against servers, since servers must calculate several hashes per negative or wildcard response. 12.2. Opt-Out Considerations The Opt-Out Flag (O) allows for unsigned names, in the form of delegations to unsigned zones, to exist within an otherwise signed zone. All unsigned names are, by definition, insecure, and their validity or existence cannot be cryptographically proven. In general: o Resource records with unsigned names (whether existing or not) suffer from the same vulnerabilities as RRs in an unsigned zone. These vulnerabilities are described in more detail in [RFC3833] (note in particular sections 2.3, "Name Chaining" and 2.6, "Authenticated Denial of Domain Names"). o Resource records with signed names have the same security whether or not Opt-Out is used. Note that with or without Opt-Out, an insecure delegation may be undetectably altered by an attacker. Because of this, the primary difference in security when using Opt-Out is the loss of the ability to prove the existence or nonexistence of an insecure delegation within the span of an Opt-Out NSEC3 RR. In particular, this means that a malicious entity may be able to insert or delete RRs with unsigned names. These RRs are normally NS RRs, but this also includes signed wildcard expansions (while the wildcard RR itself is signed, its expanded name is an unsigned name). Note that being able to add a delegation is functionally equivalent to being able to add any RR type: an attacker merely has to forge a delegation to name server under his/her control and place whatever RRs needed at the subzone apex. While in particular cases, this issue may not present a significant Laurie, et al. Expires July 5, 2007 [Page 31] Internet-Draft nsec3 January 2007 security problem, in general it should not be lightly dismissed. Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. In particular, zone signing tools SHOULD NOT default to using Opt- Out, and MAY choose to not support Opt-Out at all. 12.3. Other Considerations Walking the NSEC3 RRs will reveal the total number of RRs in the zone (plus empty non-terminals), and also what types there are. This could be mitigated by adding dummy entries, but certainly an upper limit can always be found. 13. References 13.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000. [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Laurie, et al. Expires July 5, 2007 [Page 32] Internet-Draft nsec3 January 2007 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. 13.2. Informative References [I-D.ietf-dnsext-dnssec-opt-in] Blacka, D., "DNSSEC Opt-In", draft-ietf-dnsext-dnssec-opt-in-09 (work in progress), June 2006. [I-D.jas-dnsext-no] Josefsson, S., "Authenticating denial of existence in DNS with minimum disclosure", draft-jas-dnsext-no-00 (work in progress), July 2000. [I-D.laurie-dnsext-nsec2v2] Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format", draft-laurie-dnsext-nsec2v2-00 (work in progress), December 2004. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. Appendix A. Example Zone This is a zone showing its NSEC3 RRs. They can also be used as test vectors for the hash algorithm. The overall TTL and class are specified in the SOA RR, and are subsequently omitted for clarity. Laurie, et al. Expires July 5, 2007 [Page 33] Internet-Draft nsec3 January 2007 [### RFC-editor: the examples below needs to be regenerated once IANA has completed its allocations, the document editors will supply the modified text ] example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) NS ns1.example. NS ns2.example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( 62827 example. D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 JpiZcff2Cj2B0w== ) MX 1 xx.example. RRSIG MX 133 1 3600 20150420235959 20051021000000 ( 62827 example. jsGuTpXTTrZHzUKnViUpJ8YyGNpDd6n/sy2g HnSC0nj2jPxTC5VENLo3GxSpCSA5DlAz57p+ RllUJk3DWktkjw== ) DNSKEY 256 3 133 ( AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL ExXT48OGGdbfIme5 ) DNSKEY 257 3 133 ( AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1 zsYKWJ7BvR2894hX ) RRSIG DNSKEY 133 1 3600 20150420235959 ( 20051021000000 22088 example. Xpo9ptByXb8M1JR1i0KuRmKGc/YeOLcc6Ptn RJOx6ADLSL2mU6AYX5tAJRMTKTXk6waLIaxu liqUBOkCjLUZMw== ) NSEC3PARAM 1 0 12 aabbccdd RRSIG NSEC3PARAM 133 1 3600 20150420235959 ( 20051021000000 62827 example. LIDOPjIUc2DtDpXUlOaLnJkHKbacDvXZlhRm g4eFGnaEd794HnjRjeT9w5QwtLDpLyyMRbGt 4L0XlqhGJCcAsA== ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. Laurie, et al. Expires July 5, 2007 [Page 34] Internet-Draft nsec3 January 2007 Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu +tM22fPvu7lfXQ== ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. GtJTFlvT5eYaK3rNUPQjpCKoIefvWZxQrDxU jYsmoIWdLOVOuD5ZSDDQA3anDctOHdA/XbXn o2uyWso1OzVlgg== ) NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS Y2gIduy/7FVk0g== ) 2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd ( 35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. oBio/cYM5olvRWV3zW+IToAT3mU0gqbU+gZu 7VysaXXufogv2B0ciYH29jdrRjvcCadsy/5E Yj/THQIqFXEdOw== ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 Si8JqvOk+TRYqA== ) a.example. NS ns1.a.example. NS ns2.a.example. DS 58470 5 1 ( 3079F1593EBAD6DC121E202A8B766A6A4837206C ) RRSIG DS 133 2 3600 20150420235959 20051021000000 ( 62827 example. qxw4j5LNe70UDu121YqAaqQjyjYbdKNd/4bE nH0kjQswuiGs9EuArCBhcWocWQDBku+A4HMH JdLqJr5p4JctLg== ) ns1.a.example. A 192.0.2.5 ns2.a.example. A 192.0.2.6 ai.example. A 192.0.2.9 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 BXfXAqURwLqznA== ) HINFO "KLH-10" "ITS" Laurie, et al. Expires July 5, 2007 [Page 35] Internet-Draft nsec3 January 2007 RRSIG HINFO 133 2 3600 20150420235959 ( 20051021000000 62827 example. BuDv+No06VEcIsEnvBdjdKm6kxQGrhOgKEKb Gsb8DJRjY7Lia+YG2//s6OlOIfxPmLlLiYpA i3q2sEjTJhocGQ== ) AAAA 2001:db8:0:0:0:0:f00:baa9 RRSIG AAAA 133 2 3600 20150420235959 ( 20051021000000 62827 example. m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x 2ruyuN0zC+PABA== ) b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 xDdGSZkZZ7Np+w== ) c.example. NS ns1.c.example. NS ns2.c.example. ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd ( ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. PC6xuuhgRizxo+NWTAL4BqOyRwGdjJNjdu7G +s8PPW9M1/FObcnaxvrFqnKVIzIOIkD66U/K 09DKQD9ILCfOlw== ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 bJwVGJ6LFzD1fA== ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU h7mwmVDRXopnDw== ) kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd ( q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. Laurie, et al. Expires July 5, 2007 [Page 36] Internet-Draft nsec3 January 2007 BHESCxzi1TT5+G1b5add7PkBqh+8UhIM2m4w mrOam5jM443iKviA2oGTYtdawPB0xTIoHZe7 SbrvmdDe+bjCNg== ) ns1.example. A 192.0.2.1 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. ratEKfeWD/pJJHO/XqEINvOp3so7pn9Pphxn fRiCOVsa527M/ucRcQqGYCF0CN4jAXhW+6BS ZzT0om+VdioRmg== ) ns2.example. A 192.0.2.2 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. mW/DJMbQyD5y5C+a70vWyIWZyQ+Xg1zzkWHX w3jfqmePgpdJnMrpGOcRIpy5irCFWiCwTp2o cPT+k0ccpxtkLQ== ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu W7Zo0HsSFJJLIw== ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ FEmSZ39hZpTN0w== ) t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd ( 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA RRSIG ) RRSIG NSEC3 133 2 3600 20150420235959 ( 20051021000000 62827 example. U7hZiI+Vxmcn9JLSxyOs0p4nf6+0ckmzLKX2 hCte/8EVLibUfvzyN8sP1k4nIYmMfciwV+dB 1HnaArgp+4wgOw== ) *.w.example. MX 1 ai.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( 62827 example. DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq a7Xfz/f9xzvSTw== ) x.w.example. MX 1 xx.example. RRSIG MX 133 3 3600 20150420235959 20051021000000 ( 62827 example. BLSDMos8kYR7+2U7iwwdqdhU82hzq0s57xtw F08tWU/d19jrNO6LdWfBL/FJ8zL8ZpEjhh6b Laurie, et al. Expires July 5, 2007 [Page 37] Internet-Draft nsec3 January 2007 8cj0f5yQOUyShw== ) x.y.w.example. MX 1 xx.example. RRSIG MX 133 4 3600 20150420235959 20051021000000 ( 62827 example. GPzELyUCxrnyep8uMcqthUXjTqYBmgeaveb9 2vQgzUyPLLamNN/YqMHr6tGQNxeMAhclxUSQ eoCggUBVhFfB1Q== ) xx.example. A 192.0.2.10 RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. Sz+fPqY8II1VDq+dY48Q40dq1aoBR2RAuhKg QNKXEYcULtJo/hxxfEAkJSNBKU5QnHpnnT9L jqaSdob7ZhdxHg== ) HINFO "KLH-10" "TOPS-20" RRSIG HINFO 133 2 3600 20150420235959 ( 20051021000000 62827 example. YJFwmD0By0NpGEvO1nE1ZTH10XrmpKnVuAEI cAxLLHyPs3qyGQdDEG7sQX5+PfiOGZrNmZef 8NgQhW8kGEgN1Q== ) AAAA 2001:db8:0:0:0:0:f00:baaa RRSIG AAAA 133 2 3600 20150420235959 ( 20051021000000 62827 example. VAJBlXoTOScrIM6yPlDsd9o05v39qIzFnemR 2vgw1s4l8maJVWi9IHEg8oiypJvGwSCP1nFs EOlXyNFQJ0fWGA== ) Appendix B. Example Responses [### RFC-editor: the example below needs to be regenerated once IANA has completed its allocations, the document editors will supply the modified text ] The examples in this section show response messages using the signed zone example in Appendix A. B.1. Name Error An authoritative name error. The NSEC3 RRs prove that the name does not exist and that there is no wildcard RR that should have been expanded. ;; Header: QR AA DO RCODE=3 ;; ;; Question a.c.x.w.example. IN A ;; Answer Laurie, et al. Expires July 5, 2007 [Page 38] Internet-Draft nsec3 January 2007 ;; (empty) ;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) ;; NSEC3 RR that covers the "next closer" name (c.x.w.example) ;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu +tM22fPvu7lfXQ== ) ;; NSEC3 RR that matches the closest encloser (x.w.example) ;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995 b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd ( gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG ) b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. E1RiKYSYiN2U5t1h29o63vWwg++iOyJxNhtp K0FRNe1uc/ZMElEuSOl1mj7n7hoZExR4j7J4 xDdGSZkZZ7Np+w== ) ;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example) ;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 Si8JqvOk+TRYqA== ) ;; Additional Laurie, et al. Expires July 5, 2007 [Page 39] Internet-Draft nsec3 January 2007 ;; (empty) The query returned three NSEC3 RRs that prove that the requested data does not exist and that no wildcard expansion applies. The negative response is authenticated by verifying the NSEC3 RRs. The corresponding RRSIGs indicate that the NSEC3 RRs are signed by an "example" DNSKEY of algorithm 133 and with key tag 62827. The resolver needs the corresponding DNSKEY RR in order to authenticate this answer. One of the owner names of the NSEC3 RRs matches the closest encloser. One of the NSEC3 RRs prove that there exists no longer name. One of the NSEC3 RRs prove that there exists no wildcard RRSets that should have been expanded. The closest encloser can be found by applying the algorithm in section Section 8.3. In the above example, the name 'x.w.example' hashes to 'b4um86eghhds6nea196smvmlo4ors995'. This indicates that this might be the closest encloser. To prove that 'c.x.w.example' and '*.x.w.example' do not exist, these names are hashed to, respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and '92pqneegtaue7pjatc3l3qnk738c6v5m'. The first and last NSEC3 RRs prove that these hashed owner names do not exist. B.2. No Data Error A "no data" response. The NSEC3 RR proves that the name exists and that the requested RR type does not. Laurie, et al. Expires July 5, 2007 [Page 40] Internet-Draft nsec3 January 2007 ;; Header: QR AA DO RCODE=0 ;; ;; Question ns1.example. IN MX ;; Answer ;; (empty) ;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) ;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set. 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd ( 2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG ) 2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. MOyKYIjbWDwnme6WV5R9kY9WWCjTPxcjYo+c vWgJRnmXYZtz0bYqqELIalZtHsT2W0BOtCxS Y2gIduy/7FVk0g== ) ;; Additional ;; (empty) The query returned an NSEC3 RR that proves that the requested name exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"), but the requested RR type does not exist (type MX is absent in the type code list of the NSEC3 RR), and was not a CNAME (type CNAME is also absent in the type code list of the NSEC3 RR.) B.2.1. No Data Error, Empty Non-Terminal A "no data" response because of an empty non-terminal. The NSEC3 RR proves that the name exists and that the requested RR type does not. Laurie, et al. Expires July 5, 2007 [Page 41] Internet-Draft nsec3 January 2007 ;; Header: QR AA DO RCODE=0 ;; ;; Question y.w.example. IN A ;; Answer ;; (empty) ;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set. ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd ( k8udemvp1j2f7eg6jebps17vp3n8i58h ) ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. JbIr0ml7CyVwid1WyNbXlxmZ4s0ZPZOjSbQI wZEky0ImECHZLpa9/dASklriA6Yg8lgUzsj4 bJwVGJ6LFzD1fA== ) ;; Additional ;; (empty) The query returned an NSEC3 RR that proves that the requested name exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"), but the requested RR type does not exist (Type A is absent in the Type Bit Maps field of the NSEC3 RR). Note that, unlike an empty non-terminal proof using NSECs, this is identical to a No Data Error. This example is solely mentioned to be complete. B.3. Referral to an Opt-Out Unsigned Zone The NSEC3 RRs prove that nothing for this delegation was signed. There is no proof that the unsigned delegation exists. Laurie, et al. Expires July 5, 2007 [Page 42] Internet-Draft nsec3 January 2007 ;; Header: QR DO RCODE=0 ;; ;; Question mc.c.example. IN MX ;; Answer ;; (empty) ;; Authority c.example. NS ns1.c.example. NS ns2.c.example. ;; NSEC3 RR that covers the "next closer" name (c.example) ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck 35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd ( b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG ) 35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. G4QLzK5ATuLzQOOJ8xt198+BiKLvhtkYb4jM UiL/Hz+1AWpJ1EdfzbgNR30wNqb25ua4a6G8 Si8JqvOk+TRYqA== ) ;; NSEC3 RR that matches the closest encloser (example) ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu +tM22fPvu7lfXQ== ) ;; Additional ns1.c.example. A 192.0.2.7 ns2.c.example. A 192.0.2.8 The query returned a referral to the unsigned "c.example." zone. The response contains the closest provable encloser of "c.example" to be "example", since the hash of "c.example" ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR and its Opt-Out bit is set. Laurie, et al. Expires July 5, 2007 [Page 43] Internet-Draft nsec3 January 2007 B.4. Wildcard Expansion A query that was answered with a response containing a wildcard expansion. The label count in the RRSIG RRSet in the answer section indicates that a wildcard RRSet was expanded to produce this response, and the NSEC3 RR proves that no "next closer" name exists in the zone. Laurie, et al. Expires July 5, 2007 [Page 44] Internet-Draft nsec3 January 2007 ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN MX ;; Answer a.z.w.example. MX 1 ai.example. a.z.w.example. RRSIG MX 133 2 3600 20150420235959 20051021000000 ( 62827 example. DnT0Y6dRBM8f3v8HdKmZUsGVkXh+b+htujCR c423x6c8erEMGVnxcrmcrZ53qGXcMYJ+TDkq a7Xfz/f9xzvSTw== ) ;; Authority example. NS ns1.example. example. NS ns2.example. example. RRSIG NS 133 1 3600 20150420235959 20051021000000 ( 62827 example. D9+iBwcbeKL5+TorTfYn4/pLr2lSFwyGYCyM gfq4TpFaZpxrCJPLxHbKjdkR18jAt7+SR7B5 JpiZcff2Cj2B0w== ) ;; NSEC3 RR that covers the "next closer" name (z.w.example) ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu W7Zo0HsSFJJLIw== ) ;; Additional ai.example. A 192.0.2.9 ai.example. RRSIG A 133 2 3600 20150420235959 20051021000000 ( 62827 example. qfXAvKr5o3Jixy5KXnVMEhABo3DDHYSR5+Ag lVxWCExWGMokdkafjW8Hb54+GrOFp/xmDoj5 BXfXAqURwLqznA== ) ai.example. AAAA 2001:db8:0:0:0:0:f00:baa9 ai.example. RRSIG AAAA 133 2 3600 20150420235959 ( 20051021000000 62827 example. m65zc0A16Xbx3jYb0t5vPwMzE2xS15mKh76M hSuKfiFVhBFcQ9IilEM0pXnLzt3ozrM/3X0x 2ruyuN0zC+PABA== ) Laurie, et al. Expires July 5, 2007 [Page 45] Internet-Draft nsec3 January 2007 The query returned an answer that was produced as a result of wildcard expansion. The answer section contains a wildcard RRSet expanded as it would be in a traditional DNS response. The RRSIG Labels field value of 2 indicates that the answer is the result of wildcard expansion, as the "a.z.w.example" name contains 4 labels. This also shows that "w.example" exists, so there is no need for an NSEC3 RR that matches the closest encloser. The NSEC3 RR proves that no closer match could have been used to answer this query. B.5. Wildcard No Data Error A "no data" response for a name covered by a wildcard. The NSEC3 RRs prove that the matching wildcard name does not have any RRs of the requested type and that no closer match exists in the zone. ;; Header: QR AA DO RCODE=0 ;; ;; Question a.z.w.example. IN AAAA ;; Answer ;; (empty) ;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) ;; NSEC3 RR that matches the closest encloser (w.example) ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd ( kohar7mbb8dc2ce8a9qvl8hon4k53uhi ) k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. chrf07zCt7K33AE6ZeF4Ti7CtaGePugS+I8t bEzAbluRk3BzLtCKxqDUFVl1FVgq8KrQPLgU h7mwmVDRXopnDw== ) ;; NSEC3 RR that covers the "next closer" name (z.w.example) ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03 Laurie, et al. Expires July 5, 2007 [Page 46] Internet-Draft nsec3 January 2007 q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd ( r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG ) q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. Tm6xntXYtTu0QNyC7JoDkBwLQ6alu+lboU/6 tM86JqIJIe65XWUfSm1MTvyteWILp96LxzEu W7Zo0HsSFJJLIw== ) ;; NSEC3 RR that matches a wildcard at the closest encloser. ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd ( t644ebqk9bibcna874givr6joj62mlhv MX RRSIG ) r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. OFXtK7DkTcIHFNeChJbdCgz5lX8ZOXVE4WeU RGHgiz9VfmLiN18+S7ucSt/UXNhX2ZpYWchJ FEmSZ39hZpTN0w== ) ;; Additional ;; (empty) The query returned the NSEC3 RRs that prove that the requested data does not exist and no wildcard RR applies. B.6. DS Child Zone No Data Error A "no data" response for a QTYPE=DS query that was mistakenly sent to a name server for the child zone. Laurie, et al. Expires July 5, 2007 [Page 47] Internet-Draft nsec3 January 2007 ;; Header: QR AA DO RCODE=0 ;; ;; Question example. IN DS ;; Answer ;; (empty) ;; Authority example. SOA ns1.example. bugs.x.w.example. 1 3600 300 ( 3600000 3600 ) example. RRSIG SOA 133 1 3600 20150420235959 20051021000000 ( 62827 example. hNIkW1xzn+c+9P3W7PUVVptI72xEmOtn+eqQ ux0BE7Pfc6ikx4m7ivOVWETjbwHjqfY0X5G+ rynLZNqsbLm40Q== ) ;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set. 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd ( 2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS SOA NSEC3PARAM RRSIG ) 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 133 2 3600 ( 20150420235959 20051021000000 62827 example. Oq4uXtk4yF7nd/o/+M4h+6zGyIxS+pUcqdV7 DKnF/tFkBJs0PMfwm9OdxdB+6cFv0LLYAzHu +tM22fPvu7lfXQ== ) ;; Additional ;; (empty) The query returned an NSEC3 RR showing that the requested was answered by the server authoritative for the zone "example". The NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3 RR is from the apex of the child, not from the zone cut of the parent. Queries for the "example" DS RRSet should be sent to the parent servers (which are in this case the root servers). Appendix C. Special Considerations The following paragraphs clarify specific behavior and explain special considerations for implementations. C.1. Salting Augmenting original owner names with salt before hashing increases the cost of a dictionary of pre-generated hash-values. For every bit Laurie, et al. Expires July 5, 2007 [Page 48] Internet-Draft nsec3 January 2007 of salt, the cost of a precomputed dictionary doubles (because there must be an entry for each word combined with each possible salt value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of salt, multiplying the cost by 2^2040. This means that an attacker must, in practice, recompute the dictionary each time the salt is changed. There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value. The salt SHOULD be changed periodically to prevent pre-computation using a single salt. It is RECOMMENDED that the salt be changed for every re-signing. Note that this could cause a resolver to see RRs with different salt values for the same zone. This is harmless, since each RR stands alone (that is, it denies the set of owner names whose hashes, using the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 RR) - it is only the server that needs a complete set of NSEC3 RRs with the same salt in order to be able to answer every possible query. There is no prohibition with having NSEC3 RRs with different salts within the same zone. However, in order for authoritative servers to be able to consistently find covering NSEC3 RRs, the authoritative server MUST choose a single set of parameters (algorithm, salt, and iterations) to use when selecting NSEC3 RRs. C.2. Hash Collision Hash collisions occur when different messages have the same hash value. The expected number of domain names needed to give a 1 in 2 chance of a single collision is about 2^(n/2) for a hash of length n bits (i.e. 2^80 for SHA-1). Though this probability is extremely low, the following paragraphs deal with avoiding collisions and assessing possible damage in the event of an attack using hash collisions. C.2.1. Avoiding Hash Collisions During Generation During generation of NSEC3 RRs, hash values are supposedly unique. In the (academic) case of a collision occurring, an alternative salt MUST be chosen and all hash values MUST be regenerated. C.2.2. Second Preimage Requirement Analysis A cryptographic hash function has a second-preimage resistance property. The second-preimage resistance property means that it is Laurie, et al. Expires July 5, 2007 [Page 49] Internet-Draft nsec3 January 2007 computationally infeasible to find another message with the same hash value as a given message, i.e. given preimage X, to find a second preimage X' != X such that hash(X) = hash(X'). The work factor for finding a second preimage is of the order of 2^160 for SHA-1. To mount an attack using an existing NSEC3 RR, an adversary needs to find a second preimage. Assuming an adversary is capable of mounting such an extreme attack, the actual damage is that a response message can be generated which claims that a certain QNAME (i.e. the second pre-image) does exist, while in reality QNAME does not exist (a false positive), which will either cause a security aware resolver to re-query for the non- existent name, or to fail the initial query. Note that the adversary can't mount this attack on an existing name but only on a name that the adversary can't choose and does not yet exist. C.2.3. Possible Hash Value Truncation Method The previous sections outlined the low probability and low impact of a second-preimage attack. When impact and probability are low, while space in a DNS message is costly, truncation is tempting. Truncation might be considered to allow for shorter owner names and RDATA for hashed labels. In general, if a cryptographic hash is truncated to n bits, then the expected number of domains required to give a 1 in 2 probability of a single collision is approximately 2^(n/2) and the work factor to produce a second preimage is 2^n. An extreme hash value truncation would be truncating to the shortest possible unique label value. This would be unwise, since the work factor to produce second preimages would then approximate the size of the zone (sketch of proof: if the zone has k entries, then the length of the names when truncated down to uniqueness should be proportional to log_2(k). Since the work factor to produce a second pre-image is 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where C is some constant), i.e. C'k - a work factor of k). Though the mentioned truncation can be maximized to a certain extreme, the probability of collision increases exponentially for every truncated bit. Given the low impact of hash value collisions and limited space in DNS messages, the balance between truncation profit and collision damage may be determined by local policy. Of course, the size of the corresponding RRSIG RR is not reduced, so truncation is of limited benefit. Truncation could be signaled simply by reducing the length of the first label in the owner name. Note that there would have to be a corresponding reduction in the length of the Next Hashed Owner Name field. Laurie, et al. Expires July 5, 2007 [Page 50] Internet-Draft nsec3 January 2007 Authors' Addresses Ben Laurie Nominet 17 Perryn Road London W3 7LR England Phone: +44 20 8735 0686 Email: ben@algroup.co.uk Geoffrey Sisson Nominet Sandford Gate Sandy Lane West Oxford OX4 6LB UNITED KINGDOM Phone: +44 1865 332211 Email: geoff@nominet.org.uk Roy Arends Nominet Sandford Gate Sandy Lane West Oxford OX4 6LB UNITED KINGDOM Phone: +44 1865 332211 Email: roy@nominet.org.uk David Blacka VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US Phone: +1 703 948 3200 Email: davidb@verisign.com Laurie, et al. Expires July 5, 2007 [Page 51] Internet-Draft nsec3 January 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Laurie, et al. Expires July 5, 2007 [Page 52]