idnits 2.17.00 (12 Aug 2021) /tmp/idnits55506/draft-vcelak-nsec5-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 21, 2015) is 2433 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Vcelak 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track S. Goldberg 5 Expires: March 24, 2016 Boston University 6 September 21, 2015 8 NSEC5, DNSSEC Authenticated Denial of Existence 9 draft-vcelak-nsec5-01 11 Abstract 13 The Domain Name System Security (DNSSEC) Extensions introduced the 14 NSEC resource record (RR) for authenticated denial of existence and 15 the NSEC3 for hashed authenticated denial of existence. The NSEC RR 16 allows for the entire zone contents to be enumerated if a server is 17 queried for carefully chosen domain names; N queries suffice to 18 enumerate a zone containing N names. The NSEC3 RR adds domain-name 19 hashing, which makes the zone enumeration harder, but not impossible. 20 This document introduces NSEC5, which provides an cryptographically- 21 proven mechanism that prevents zone enumeration. NSEC5 has the 22 additional advantage of not requiring private zone-signing keys to be 23 present on all authoritative servers for the zone. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 24, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 64 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 6 66 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 7 67 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 7 68 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 7 69 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 7 70 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 7 71 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 8 72 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 9 73 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 9 74 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 9 75 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 10 76 8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 10 78 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 11 79 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 11 80 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 12 81 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 12 82 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 12 83 9. Authoritative Server Considerations . . . . . . . . . . . . . 13 84 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 13 85 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 14 86 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 15 87 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 16 88 9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 16 89 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 16 90 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 16 91 11. Validator Considerations . . . . . . . . . . . . . . . . . . 16 92 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 16 93 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 17 94 11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 17 95 12. Special Considerations . . . . . . . . . . . . . . . . . . . 18 96 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 18 97 12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 18 98 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 18 99 13. Performance Considerations . . . . . . . . . . . . . . . . . 19 100 13.1. Performance of Cryptographic Operations . . . . . . . . 19 101 13.2. Authoritative Server Startup . . . . . . . . . . . . . . 20 102 13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 21 103 14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 104 14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 24 105 14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 24 106 14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 24 107 14.4. Key Length Considerations . . . . . . . . . . . . . . . 25 108 14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 25 109 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 110 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 111 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 112 17.1. Normative References . . . . . . . . . . . . . . . . . . 26 113 17.2. Informative References . . . . . . . . . . . . . . . . . 27 114 Appendix A. Full Domain Hash Algorithm . . . . . . . . . . . . . 28 115 A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 28 116 A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 29 117 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 29 118 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 30 120 1. Introduction 122 1.1. Rationale 124 The DNS Security Extensions (DNSSEC) provides data integrity 125 protection using public-key cryptography, while not requiring that 126 authoritative servers compute signatures on-the-fly. The content of 127 the zone is usually pre-computed and served as is. The evident 128 advantages of this approach are reduced performance requirements per 129 query, as well as not requiring private zone-signing keys to be 130 present on nameservers facing the network. 132 With DNSSEC, each resource record (RR) set in the zone is signed. 133 The signature is retained as an RRSIG RR directly in the zone. This 134 enables response authentication for data existing in the zone. To 135 ensure integrity of denying answers, an NSEC chain of all existing 136 domain names in the zone is constructed. The chain is made of RRs, 137 where each RR represents two consecutive domain names in canonical 138 order present in the zone. The NSEC RRs are signed the same way as 139 any other RRs in the zone, and each NSEC can be used to prove that a 140 given name does not existing in a part of the domain name space. 142 As side-effect, however, the NSEC chain allows for enumeration of the 143 zone's contents by sequentially querying for the names immediately 144 following those in the most-recently retrieved NSEC record; N queries 145 suffice to enumerate a zone containing N names. As such, the NSEC3 146 hashed denial of existence was introduced to prevent zone 147 enumeration. In NSEC3, the original domain names in the NSEC chain 148 are replaced by their cryptographic hashes. While NSEC3 makes zone 149 enumeration more difficult, offline dictionary attacks are still 150 possible and have been demonstrated; this is because hashes may be 151 computed offline and the space of possible domain names is restricted 152 [nsec3walker][nsec3gpu]. 154 Zone enumeration can be prevented with NSEC3 if having the 155 authoritative server compute NSEC3 RRs on-the-fly, in response to 156 queries with denying responses. Usually, this is done with Minimally 157 Covering NSEC Records or NSEC3 White Lies [RFC7129]. One of the most 158 significant disadvantage of this approach is a required presence of 159 the private key on all authoritative servers for the zone. This is 160 often undesirable, as the holder of the private key can tamper with 161 the zone content, and having private keys on many network-facing 162 servers increases the risk that keys can be compromised. 164 To prevent zone content enumeration without keeping private keys on 165 all authoritative servers, NSEC5 replaces the unkeyed cryptographic 166 hash function used in NSEC3 with a public-key hashing scheme. 167 Hashing in NSEC5 is performed with a separate NSEC5 key. The public 168 portion of this key is distributed in an NSEC5KEY RR, and is used to 169 validate NSEC5 hash values. The private portion of the NSEC5 key is 170 present on all authoritative servers for the zone, and is used to 171 compute hash values. 173 Importantly, the NSEC5KEY key cannot be used to modify the contents 174 of the zone. Thus, any compromise of the private NSEC5 key does not 175 lead to a compromise of zone contents; all that is lost is privacy 176 against zone enumeration, effectively downgrading the security of 177 NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of 178 security, available in [nsec5]. 180 The NSEC5 is not intended to replace NSEC or NSEC3. It is designed 181 as an alternative mechanism for authenticated denial of existence. 183 1.2. Requirements 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 1.3. Terminology 191 The reader is assumed to be familiar with the basic DNS and DNSSEC 192 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 194 [RFC4035], and subsequent RFCs that update them: [RFC2136], 195 [RFC2181], [RFC2308], and [RFC5155]. 197 The following terminology is used through this document: 199 Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as 200 specified in [RFC4648]. The padding characters ("=") are not used 201 in NSEC5 specification. 203 Base64: The "Base 64 Encoding" as specified in [RFC4648]. 205 NSEC5 proof: A signed hash of a domain name (hash-and-sign 206 paradigm). A holder of the private key (e.g., authoritative 207 server) can compute the proof. Anyone knowing the public key 208 (e.g., client) can verify it's validity. 210 NSEC5 hash: A cryptographic hash (digest) of an NSEC5 proof. If the 211 NSEC5 proof is known, anyone can compute and verify it's NSEC5 212 hash. 214 NSEC5 algorithm: A pair of algorithms used to compute NSEC5 proofs 215 and NSEC5 hashes. 217 2. Backward Compatibility 219 The specification describes a protocol change that is not backward 220 compatible with [RFC4035] and [RFC5155]. NSEC5-unaware resolver will 221 fail to validate responses introduced by this document. 223 To prevent NSEC5-unaware resolvers from attempting to validate the 224 responses, new DNSSEC algorithms identifiers are introduced, the 225 identifiers alias with existing algorithm numbers. The zones signed 226 according to this specification MUST use only these algorithm 227 identifiers, thus NSEC5-unaware resolvers will treat the zone as 228 insecure. 230 The new algorithm identifiers defined by this document are listed in 231 Section 15. 233 3. How NSEC5 Works 235 To prove non-existence of a domain name in a zone, NSEC uses a chain 236 built from domain names present in the zone. NSEC3 replaces the 237 original domain names by their cryptographic hashes. NSEC5 is very 238 similar to NSEC3, however a public-key based hashing scheme is used. 240 In NSEC5, the original domain name is hashed twice: 242 1. First, the domain name is hashed using the NSEC5 private key; the 243 result is called the NSEC5 proof. Only an authoritative server 244 that knows the private NSEC5 key can compute the NSEC5 proof. 245 Any client that knows the public NSEC5 key can validate the NSEC5 246 proof. 248 2. Second, the NSEC5 proof is hashed using a cryptographic hash 249 function; the result is called the NSEC5 hash. This hash can be 250 computed by any party that knows the input NSEC5 proof. 252 The NSEC5 hash determines the position of a domain name in an NSEC5 253 chain. That is, all the NSEC5 hashes for a zone are sorted in their 254 canonical order, and each consecutive pair forms an NSEC5 RR. 256 To prove an non-existence of a particular domain name in response to 257 a query, the server computes on the fly, the NSEC5 proof (using the 258 private NSEC5 key). Then it uses the NSEC5 proof to compute the 259 corresponding NSEC5 hash. It then identifies the NSEC5 RR that 260 covers the hash. In the response message, the server returns the 261 NSEC5 RR, it's corresponding signature (RRSIG RRset), and synthesized 262 NSEC5PROOF RR containing the NSEC5 proof it computed on the fly. 264 To validate the response, the client first uses the public NSEC5 key 265 (stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof 266 corresponds with the domain name to be disproved. Then, the client 267 computes the NSEC5 hash from the NSEC5 proof and checks if the NSEC5 268 RR content and it's signature are valid. 270 4. NSEC5 Algorithms 272 The algorithms used for NSEC5 authenticated denial are independent of 273 the algorithms used for DNSSEC signing. An NSEC5 algorithm defines 274 how the NSEC5 proof and the NSEC5 hash is computed and validated. 276 The input for the NSEC5 proof computation is an RR owner name in the 277 canonical form in the wire format and an NSEC5 private key; the 278 output is an octet string. 280 The input for the NSEC5 hash computation is the corresponding NSEC5 281 proof; the output is an octet string. 283 This document defines FDH-SHA256-SHA256 NSEC5 algorithm as follows: 285 o NSEC5 proof is an RSA based Full Domain Hash (FDH) with SHA-256 286 hash function used internally for input preprocessing. The FDH 287 signature and verification is formally specified in Appendix A. 289 o NSEC5 hash is an SHA-256 hash function as specified in [RFC6234]. 291 o The public key format to be used in NSEC5KEY RR is defined in 292 Section 2 of [RFC3110] and thus is the same as the format used to 293 store RSA public keys in DNSKEY RRs. 295 The NSEC5 algorithm identifier for FDH-SHA256-SHA256 is 1. 297 5. The NSEC5KEY Resource Record 299 The NSEC5KEY RR stores an NSEC5 public key. The key allows clients 300 to verify a validity of NSEC5 proof sent by a server. 302 5.1. NSEC5KEY RDATA Wire Format 304 The RDATA for NSEC5KEY RR is as shown below: 306 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Algorithm | Public Key / 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Algorithm is a single octet identifying NSEC5 algorithm. 314 Public Key is a variable sized field holding public key material for 315 NSEC5 proof verification. 317 5.2. NSEC5KEY RDATA Presentation Format 319 The presentation format of the NSEC5KEY RDATA is as follows: 321 The Algorithm field is represented as an unsigned decimal integer. 323 The Public Key field is represented in Base64 encoding. Whitespace 324 is allowed within the Base64 text. 326 6. The NSEC5 Resource Record 328 The NSEC5 RR provides authenticated denial of existence for an RRset. 329 One NSEC5 RR represents one piece of an NSEC5 chain, proving 330 existence of RR types present at the original domain name and also 331 non-existence of other domain names in a part of the hashed domain 332 name space. 334 6.1. NSEC5 RDATA Wire Format 336 The RDATA for NSEC5 RR is as shown below: 338 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Key Tag | Flags | Next Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Next Hashed Owner Name / 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 / Type Bit Maps / 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Key Tag field contains the key tag value of the NSEC5KEY RR that 349 validates the NSEC5 RR, in network byte order. The value is computed 350 from the NSEC5KEY RDATA using the same algorithm, which is used to 351 compute key tag values for DNSKEY RRs. The algorithm is defined in 352 [RFC4034]. 354 Flags field is a single octet. The meaning of individual bits of the 355 field is defined in Section 6.2. 357 Next length is an unsigned single octet specifying the length of the 358 Next Hashed Owner Name field in octets. 360 Next Hashed Owner Name field is a sequence of binary octets. It 361 contains an NSEC5 hash of the next domain name in the NSEC5 chain. 363 Type Bit Maps is a variable sized field encoding RR types present at 364 the original owner name matching the NSEC5 RR. The format of the 365 field is equivalent to the format used in NSEC3 RR, described in 366 [RFC5155]. 368 6.2. NSEC5 Flags Field 370 The following one-bit NSEC5 flags are defined: 372 0 1 2 3 4 5 6 7 373 +-+-+-+-+-+-+-+-+ 374 | |W|O| 375 +-+-+-+-+-+-+-+-+ 377 O - Opt-Out flag 379 W - Wildcard flag 381 All the other flags are reserved for future use and MUST be zero. 383 The Opt-Out flag has the same semantics as in NSEC3. The definition 384 and considerations in [RFC5155] are valid, except that NSEC3 is 385 replaced by NSEC5. 387 The Wildcard flag indicates that a wildcard synthesis is possible at 388 the original domain name level (i.e., there is a wildcard node 389 immediately descending from the immediate ancestor of the original 390 domain name). The purpose of the Wildcard flag is to reduce a 391 maximum number of RRs required for authenticated denial of existence 392 proof. 394 6.3. NSEC5 RDATA Presentation Format 396 The presentation format of the NSEC5 RDATA is as follows: 398 The Key Tag field is represented as an unsigned decimal integer. 400 The Flags field is represented as an unsigned decimal integer. 402 The Next Length field is not represented. 404 The Next Hashed Owner Name field is represented as a sequence of 405 case-insensitive Base32hex digits without any whitespace and without 406 padding. 408 The Type Bit Maps representation is equivalent to the representation 409 used in NSEC3 RR, described in [RFC5155]. 411 7. The NSEC5PROOF Resource Record 413 The NSEC5PROOF record is synthesized by the authoritative server on- 414 the-fly. The record contains the NSEC5 proof, proving a position of 415 the owner name in an NSEC5 chain. 417 7.1. NSEC5PROOF RDATA Wire Format 419 The RDATA for NSEC5PROOF is as as shown below: 421 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Key Tag | Owner Name Hash / 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Key Tag field contains the key tag value of the NSEC5KEY RR that 428 validates the NSEC5PROOF RR, in network byte order. 430 Owner Name Hash is a variable sized sequence of binary octets 431 encoding the NSEC5 proof of the owner name of the RR. 433 7.2. NSEC5PROOF RDATA Presentation Format 435 The presentation format of the NSEC5PROOF RDATA is as follows: 437 The Key Tag field is represented as an unsigned decimal integer. 439 The Owner Name Hash is represented in Base64 encoding. Whitespace is 440 allowed within the Base64 text. 442 8. NSEC5 Proofs 444 This section summarizes all possible types of authenticated denial of 445 existence. For each type the following lists are included: 447 1. Facts to prove. The minimum amount of information an 448 authoritative server must provide to a client to assure the 449 client that the response content is valid. 451 2. Authoritative server proofs. NSEC5 RRs an authoritative server 452 must include in a response to prove the listed facts. 454 3. Validator checks. Individual checks a validating server is 455 required to perform on a response. The response content is 456 considered valid only if all the checks pass. 458 If NSEC5 is said to match a domain name, the owner name of the NSEC5 459 has to be equivalent to an NSEC5 hash of that domain name. If NSEC5 460 is said to cover a domain name, the NSEC5 hash of that name must lay 461 strictly between the NSEC5 owner name and the NSEC5 Next Hashed Owner 462 Name. 464 8.1. Name Error Responses 466 Facts to prove: 468 No RRset matching the QNAME exactly exists. 470 No RRset matching the QNAME via wildcard expansion exists. 472 The QNAME does not fall into a delegation. 474 The QNAME does not fall into a DNAME redirection. 476 Authoritative server proofs: 478 Closest encloser. 480 Next closer name. 482 Validator checks: 484 Closest encloser belongs to the zone. 486 Closest encloser has the Wildcard flag cleared. 488 Closest encloser does not have NS without SOA in the Type Bit Map. 490 Closest encloser does not have DNAME in the Type Bit Maps. 492 Next closer name is derived correctly. 494 8.2. No Data Responses 496 The processing of a No Data response for DS QTYPE differs if the Opt- 497 Out is in effect. For DS QTYPE queries, the validator has two 498 possible checking paths. The correct path can be simply decided by 499 inspecting if the NSEC5 RR in the response matches the QNAME. 501 Note that the Opt-Out is valid only for DS QTYPE queries. 503 8.2.1. No Data Response, Opt-Out Not In Effect 505 Facts to prove: 507 An RRset matching the QNAME exists. 509 No QTYPE RRset matching the QNAME exists. 511 No CNAME RRset matching the QNAME exists. 513 Authoritative server proofs: 515 QNAME. 517 Validator checks: 519 The NSEC5 RR exactly matches the QNAME. 521 The NSEC5 RR does not have QTYPE in the Type Bit Map. 523 The NSEC5 RR does not have CNAME in the Type Bit Map. 525 8.2.2. No Data Response, Opt-Out In Effect 527 Facts to prove: 529 The delegation is not covered by the NSEC5 chain. 531 Authoritative server proofs: 533 Closest provable encloser. 535 Validator checks: 537 Closest provable encloser is in zone. 539 Closest provable encloser covers (not matches) the QNAME. 541 Closest provable encloser has the Opt-Out flag set. 543 8.3. Wildcard Responses 545 Facts to prove: 547 No RRset matching the QNAME exactly exists. 549 No wildcard closer to the QNAME exists. 551 Authoritative server proofs: 553 Next closer name. 555 Validator checks: 557 Next closer name is derived correctly. 559 Next closer name covers (not matches). 561 8.4. Wildcard No Data Responses 563 Facts to prove: 565 No RRset matching the QNAME exactly exists. 567 No QTYPE RRset exists at the wildcard matching the QNAME. 569 No CNAME RRset exists at the wildcard matching the QNAME. 571 No wildcard closer to the QNAME exists. 573 Authoritative server proofs: 575 Source of synthesis (i.e., wildcard at closest encloser). 577 Next closer name. 579 Validator checks: 581 Source of synthesis matches exactly the QNAME. 583 Source of synthesis does not have QTYPE in the Type Bit Map. 585 Source of synthesis does not have CNAME in the Type Bit Map. 587 Next closer name is derived correctly. 589 Next closer name covers (not matches). 591 9. Authoritative Server Considerations 593 9.1. Zone Signing 595 Zones using NSEC5 MUST satisfy the same properties as described in 596 Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition, 597 the following conditions MUST be satisfied as well: 599 o If the original owner name has a wildcard label immediately 600 descending from the original owner name, the corresponding NSEC5 601 RR MUST have the Wildcard flag set in the Flags field. Otherwise, 602 the flag MUST be cleared. 604 o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5 605 public key allowing verification of the current NSEC5 chain. 607 The following steps describe one possible method to properly add 608 required NSEC5 related records into a zone. This is not the only 609 such existing method. 611 1. Select an algorithm for NSEC5. Generate the public and private 612 NSEC5 keys. 614 2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5 615 key. 617 3. For each unique original domain name in the zone and each empty 618 non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names 619 of unsigned delegations MAY be excluded. 621 a. The owner name of the NSEC5 RR is the NSEC5 hash of the 622 original owner name encoded in Base32hex without padding, 623 prepended as a single label to the zone name. 625 b. Set the Key Tag field to be the key tag corresponding to the 626 public NSEC5 key. 628 c. Clear the Flags field. If Opt-Out is being used, set the 629 Opt-Out flag. If there is a wildcard label directly 630 descending from the original domain name, set the Wildcard 631 flag. Note that the wildcard can be an empty non-terminal 632 (i.e., the wildcard synthesis does not take effect and 633 therefore the flag is not to be set). 635 d. Set the Next Length field to a value determined by the used 636 NSEC5 algorithm. Leave the Next Hashed Owner Name field 637 blank. 639 e. Set the Type Bit Maps field based on the RRsets present at 640 the original owner name. 642 4. Sort the set of NSEC5 RRs into canonical order. 644 5. For each NSEC5 RR, set the Next Hashed Owner Name field by using 645 the owner name of the next NSEC5 RR in the canonical order. If 646 the updated NSEC5 is the last NSEC5 RR in the chain, the owner 647 name of the first NSEC5 RR in the chain is used instead. 649 The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA 650 RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA 651 minimum TTL field. 653 Notice that a use of Opt-Out is not indicated in the zone. This does 654 not affect the ability of a server to prove insecure delegations. 655 The Opt-Out MAY be part of the zone-signing tool configuration. 657 9.2. Zone Serving 659 This specification modifies DNSSEC-enabled DNS responses generated by 660 authoritative servers. In particular, it replaces use of NSEC or 661 NSEC3 RRs in such responses with NSEC5 RRs and adds on-the-fly 662 computed NSEC5PROOF RRs. 664 The authenticated denial of existence proofs in NSEC5 are almost the 665 same as in NSEC3. However, due to introduction of Wildcard flag in 666 NSEC5 RRs, the NSEC5 proof consists from (up to) two NSEC5 RRs, 667 instead of (up to) three. 669 According to a type of a response, an authoritative server MUST 670 include NSEC5 RRs in a response as defined in Section 8. For each 671 NSEC5 RR in the response a matching RRSIG RRset and a synthesized 672 NSEC5PROOF MUST be added as well. 674 A synthesized NSEC5PROOF RR has the owner name set to a domain name 675 exactly matching the name required for the proof. The class and TTL 676 of the RR MUST be the same as the class and TTL value of the 677 corresponding NSEC5 RR. The RDATA are set according to the 678 description in Section 7.1. 680 Notice, that the NSEC5PROOF owner name can be a wildcard (e.g., 681 source of synthesis proof in wildcard No Data responses). The name 682 also always matches the domain name required for the proof while the 683 NSEC5 RR may only cover (not match) the name in the proof (e.g., 684 closest encloser in Name Error responses). 686 If NSEC5 is used, an answering server MUST use exactly one NSEC5 687 chain for one signed zone. 689 NSEC5 MUST NOT be used in parallel with NSEC, NSEC3, or any other 690 authenticated denial of existence mechanism that allows for 691 enumeration of zone contents. 693 Similarly to NSEC3, the owner names of NSEC5 RRs are not represented 694 in the NSEC5 chain and therefore NSEC5 records deny their own 695 existence. The desired behavior caused by this paradox is the same 696 as described in Section 7.2.8 of [RFC5155]. 698 9.3. NSEC5KEY Rollover Mechanism 700 Replacement of the NSEC5 key implies generating a new NSEC5 chain. 701 The NSEC5KEY rollover mechanism is similar to "Pre-Publish Zone 702 Signing Key Rollover" as specified in [RFC6781]. The NSEC5KEY 703 rollover MUST be performed as a sequence of the following steps: 705 1. A new public NSEC5 key is added into the NSEC5KEY RRset in the 706 zone apex. 708 2. The old NSEC5 chain is replaced by a new NSEC5 chain constructed 709 using the new key. This replacement MUST happen as a single 710 atomic operation; the server MUST NOT be responding with RRs from 711 both the new and old chain at the same time. 713 3. The old public key is removed from the NSEC5KEY RRset in the zone 714 apex. 716 The minimal delay between the steps 1. and 2. MUST be the time it 717 takes for the data to propagate to the authoritative servers, plus 718 the TTL value of the old NSEC5KEY RRset. 720 The minimal delay between the steps 2. and 3. MUST be the time it 721 takes for the data to propagate to the authoritative servers, plus 722 the maximum zone TTL value of any of the data in the previous version 723 of the zone. 725 9.4. Secondary Servers 727 This document does not define mechanism to distribute NSEC5 private 728 keys. 730 9.5. Zones Using Unknown Hash Algorithms 732 Zones that are signed with unknown NSEC5 algorithm or by an 733 unavailable NSEC5 private key cannot be effectively served. Such 734 zones SHOULD be rejected when loading and servers SHOULD respond with 735 RCODE=2 (Server failure) when handling queries that would fall under 736 such zones. 738 9.6. Dynamic Updates 740 A zone signed using NSEC5 MAY accept dynamic updates. The changes to 741 the zone MUST be performed in a way, that the zone satisfies the 742 properties specified in Section 9.1 at any time. 744 It is RECOMMENDED that the server rejects all updates containing 745 changes to the NSEC5 chain (or related RRSIG RRs) and performs itself 746 any required alternations of the NSEC5 chain induced by the update. 748 Alternatively, the server MUST verify that all the properties are 749 satisfied prior to performing the update atomically. 751 10. Resolver Considerations 753 The same considerations as described in Section 9 of [RFC5155] for 754 NSEC3 apply to NSEC5. In addition, as NSEC5 RRs can be validated 755 only with appropriate NSEC5PROOF RRs, the NSEC5PROOF RRs MUST be all 756 together cached and included in responses with NSEC5 RRs. 758 11. Validator Considerations 760 11.1. Validating Responses 762 The validator MUST ignore NSEC5 RRs with Flags field values other 763 than the ones defined in Section 6.2. 765 The validator MAY treat responses as bogus if the response contains 766 NSEC5 RRs that refer to a different NSEC5KEY. 768 According to a type of a response, the validator MUST verify all 769 conditions defined in Section 8. Prior to making decision based on 770 the content of NSEC5 RRs in a response, the NSEC5 RRs MUST be 771 validated. 773 To validate a denial of existence, zone NSEC5 public keys are 774 required in addition to DNSSEC public keys. Similarly to DNSKEY RRs, 775 the NSEC5KEY RRs are present in the zone apex. 777 The NSEC5 RR is validated as follows: 779 1. Select a correct NSEC5 public key to validate the NSEC5PROOF. 780 The Key Tag value of the NSEC5PROOF RR must match with the key 781 tag value computed from the NSEC5KEY RDATA. 783 2. Validate the NSEC5 proof present in the NSEC5PROOF Owner Name 784 Hash field using the NSEC5 public key. If there are multiple 785 NSEC5KEY RRs matching the key tag, at least one of the keys must 786 validate the NSEC5 proof. 788 3. Compute the NSEC5 hash value from the NSEC5 proof and check if 789 the response contains NSEC5 RR matching or covering the computed 790 NSEC5 hash. The TTL values of the NSEC5 and NSEC5PROOF RRs must 791 be the same. 793 4. Validate the signature of the NSEC5 RR. 795 If the NSEC5 RR fails to validate, it MUST be ignored. If some of 796 the conditions required for an NSEC5 proof is not satisfied, the 797 response MUST be treated as bogus. 799 Notice that determining closest encloser and next closer name in 800 NSEC5 is easier than in NSEC3. NSEC5 and NSEC5PROOF RRs are always 801 present in pairs in responses and the original owner name of the 802 NSEC5 RR matches the owner name of the NSEC5PROOF RR. 804 11.2. Validating Referrals to Unsigned Subzones 806 The same considerations as defined in Section 8.9 of [RFC5155] for 807 NSEC3 apply to NSEC5. 809 11.3. Responses With Unknown Hash Algorithms 810 A validator MUST ignore NSEC5KEY RRs with unknown NSEC5 algorithms. 811 The practical result of this is that zones sighed with unknown 812 algorithms will be considered bogus. 814 12. Special Considerations 816 12.1. Transition Mechanism 818 TODO: Not finished. Following information will be covered: 820 o Transition from NSEC or NSEC3. 822 o Transition from NSEC5 to NSEC/NSEC3 824 o Transition to new algorithms within NSEC5 826 Quick notes on transition from NSEC/NSEC3 to NSEC5: 828 1. Publish NSEC5KEY RR. 830 2. Wait for data propagation to slaves and cache expiration. 832 3. Instantly switch answering from NSEC/NSEC3 to NSEC5. 834 Quick notes on transition from NSEC5 to NSEC/NSEC3: 836 1. Instantly switch answering from NSEC5 to NSEC/NSEC3. 838 2. Wait for NSEC5 RRs expiration in caches. 840 3. Remove NSEC5KEY RR from the zone. 842 12.2. NSEC5 Private Keys 844 This document does not define format to store NSEC5 private key. Use 845 of standardized and adopted format is RECOMMENDED. 847 The NSEC5 private key MAY be shared between multiple zones, however a 848 separate key is RECOMMENDED for each zone. 850 12.3. Domain Name Length Restrictions 852 The NSEC5 creates additional restrictions on domain name lengths. In 853 particular, zones with names that, when converted into hashed owner 854 names exceed the 255 octet length limit imposed by [RFC1035], cannot 855 use this specification. 857 The actual maximum length of a domain name depends on the length of 858 the zone name and used NSEC5 algorithm. 860 With FDH-SHA256-SHA256 defined in this document, the SHA-256 hash 861 function is used to construct NSEC5 hash values. SHA-256 produces a 862 hash of 256 bits, which can be encoded in 52 characters in Base32hex 863 without padding. The encoded string is prepended to the name of the 864 zone as a single label, which includes the length field of a single 865 octet. The maximal length of the zone name is therefore 202 octets 866 (255 - 53). 868 13. Performance Considerations 870 This section compares NSEC, NSEC3, and NSEC5 with regards to the size 871 of denial-of-existence responses and performance impact on the DNS 872 components. 874 13.1. Performance of Cryptographic Operations 876 Additional performance costs depend on the costs of cryptographic 877 operations to a great extent. The following results were retrieved 878 with OpenSSL 1.0.1k, running an ordinary laptop on a single-core of a 879 CPU manufactured in 2011. The parameters of cryptographic operations 880 were chosen to reflect the parameters used in the real-world 881 application of DNSSEC. 883 Comparison of NSEC3 and NSEC5 hashing performance: 885 o NSEC3 uses multiple iterations of the SHA-1 function with an 886 arbitrary salt. The input of the first iteration is the domain 887 name in wire format together with binary salt; the input of the 888 subsequent iterations is the binary digest and the salt. We can 889 assume that the input size will be smaller than 32 octets for most 890 executions. 892 The measured implementation gives a stable performance for small 893 input blocks up to 32 octets. About 3e6 hashes per second can be 894 computed given these parameters. 896 The number of additional iterations in NSEC3 parameters will 897 probably vary between 0 and 20 in reality. Therefore we can 898 expect the NSEC3 hash computation performance to be between 2e5 899 and 3e6 hashes per second. 901 o The NSEC5 hash is computed in two steps: NSEC5 proof computation 902 followed by hashing of the result. The NSEC5 proof is basically 903 an RSA signature and the performance will therefore vary for 904 signing and verification and also for different key sizes. We can 905 expect that the final hashing will have insignificant impact on 906 the overall hashing performance. 908 The measurement of NSEC5 proof computation and verification 909 resulted into the following numbers: 3e3 sign/s and 4e4 verify/s 910 for 1024-bit key; 4e2 sign/s and 1e4 verify/s for 2048-bit key; 911 and 5e1 sign/s and 3e3 verify/s for 4096-bit key. 913 The final SHA-256 hashing is about two orders of magnitude faster 914 given the input block size matching the NSEC5 proof result size. 916 Picking a moderate key size of 2048-bits, the NSEC5 hash 917 computation performance will be in the order of 10^2 issued hashes 918 per second and 10^4 validated hashes per second. 920 According to the results, the NSEC5 hashing is about three orders of 921 magnitude slower than NSEC3 hashing and the NSEC5 hash verification 922 is about one order of magnitude slower than NSEC3 hash verification. 924 Comparison of signing and verification performance of different 925 DNSSEC signing algorithms: 927 +-----------------+---------+-----------+-------------+-------------+ 928 | Algorithm | Key | Signature | Performance | Performance | 929 | | size | size | (sign/s) | (verify/s) | 930 | | (bits) | (octets) | | | 931 +-----------------+---------+-----------+-------------+-------------+ 932 | RSASHA256 | 1024 | 128 | 2000 | 40000 | 933 | RSASHA256 | 2048 | 256 | 400 | 10000 | 934 | RSASHA256 | 4096 | 512 | 50 | 3000 | 935 | ECDSAP256SHA256 | 256 | 64 | 5000 | 1000 | 936 | ECDSAP384SHA384 | 384 | 96 | 3000 | 600 | 937 +-----------------+---------+-----------+-------------+-------------+ 939 The retrieved values are important primarily for the purpose of 940 evaluating performance of response validation. The signing 941 performance is not that important because the zone is usually signed 942 offline. 944 13.2. Authoritative Server Startup 946 This section compares additional server startup cost based on the 947 used authenticated denial mechanism. 949 NSEC There are no special requirements on processing of a NSEC- 950 signed zone during an authoritative server startup. The server 951 handles the NSEC RRs the same way as any other records in the 952 zone. 954 NSEC3 The authoritative server can precompute NSEC3 hashes for all 955 domain names in the NSEC3-signed zone on startup. With respect to 956 query answering, this can speed up inclusion of NSEC3 RRs for 957 existing domain names (i.e., Closest provable encloser and QNAME 958 for No Data response). 960 NSEC5 Very similar considerations apply for NSEC3 and NSEC5. There 961 is a strong motivation to precompute the NSEC5 proofs because they 962 are costly to compute. A possible solution to reduce the startup 963 time is to store the precomputed NSEC5 proofs and NSEC5 hashes in 964 a persistent storage. 966 The impact of NSEC3 and NSEC5 on the authoritative server startup 967 performance is greatly implementation specific. The server software 968 vendor has to seek balance between answering performance, startup 969 slowdown, and additional storage cost. 971 13.3. NSEC5 Answer Generating and Processing 973 An authenticated denial proof is required for No Data, Name Error, 974 Wildcard Match, and Wildcard No Data answer. The number of required 975 records depends on used authenticated denial mechanism. Their size, 976 generation cost, and validation cost depend on various zone and 977 signing parameters. 979 In the worst case, the following additional records authenticating 980 the denial will be included into the response: 982 o Up to two NSEC records and their associated RRSIG records. 984 o Up to three NSEC3 records and their associated RRSIG records. 986 o Up to two NSEC5 records and their associated NSEC5PROOF and RRSIG 987 records. 989 The following table compares the size of NSEC, NSEC3, and NSEC5 990 records. We assume the SHA-1 hash algorithm for NSEC3 and the FDH- 991 SHA256-SHA256 algorithm for NSEC5. 993 +-------+------------+---------------+-----------------------+ 994 | | Fixed part | Common part | RR type-specific part | 995 +-------+------------+---------------+-----------------------+ 996 | NSEC | 10 octets | Type Bit Maps | Owner Name, Next Name | 997 | NSEC3 | 64 octets | Type Bit Maps | Salt | 998 | NSEC5 | 101 octets | Type Bit Maps | - | 999 +-------+------------+---------------+-----------------------+ 1001 The size covers complete RR representation in wire format: 1003 o The Fixed part includes length of all fixed-size fields in the RR; 1004 and also a size of generally variable-sized fields whose length 1005 can determined from the used parameters (e.g., the NSEC3 owner 1006 name consists from one label encoding the hash and a compression 1007 pointer to zone apex). 1009 o The Common part includes the only field shared among the RR types. 1011 o The RR type-specific part contains unique fields present in the RR 1012 types whose length will vary. Note that the Owner Name can be 1013 compressed, but Next Name must not. Also note that the Salt in 1014 NSEC3 will have constant size for all NSEC3 records in the chain. 1016 The size of RRSIG RR is a sum of length of possibly compressed RR 1017 owner name, 28 octets for fixed-size fields, the length of 1018 uncompressed signer name, and the length of the signature. 1020 The size of NSEC5PROOF RR is a sum of length of possibly compressed 1021 RR owner name, 2 octets for fixed-size fields, and the length of the 1022 proof. 1024 The following list summarizes the increase of the DNS response size 1025 for authenticated denial worst-case scenario. As a significant part 1026 of the increase is caused by the used DNSSEC signing algorithm, the 1027 summary includes two variants: RSA stands for the RSASHA256 algorithm 1028 with 2048-bit key and ECDSA stands for the ECDSAP256SHA256 algorithm. 1029 For NSEC5, FDH-SHA256-SHA256 with 2048-bit key is used. 1031 o NSEC: 1033 * 4 x compressed domain name 1035 * 4 x uncompressed domain name 1037 * 2 x type bit bitmap 1039 * 588 octets (RSA) or 204 octets (ECDSA) 1041 o NSEC3: 1043 * 3 x compressed domain name 1044 * 3 x uncompressed domain name 1046 * 3 x salt 1048 * 3 x type bit map 1050 * 969 octets (RSA) or 393 octets (ECDSA) 1052 o NSEC5: 1054 * 4 x compressed domain name 1056 * 2 x uncompressed domain name 1058 * 2 x type bit map 1060 * 1286 octets (RSA) or 902 octets (ECDSA) 1062 The following list summarizes additional cryptographic operations 1063 performed by the authoritative server for authenticated denial worst- 1064 case scenario: 1066 o NSEC: 1068 * No cryptographic operations required. 1070 o NSEC3: 1072 * NSEC3 hash for Closest provable encloser (possibly precomputed) 1074 * NSEC3 hash for Next closer name 1076 * NSEC3 hash for wildcard at the closest encloser 1078 o NSEC5: 1080 * NSEC5 proof and hash for Closest provable encloser (possibly 1081 precomputed) 1083 * NSEC5 proof and hash for Next closer name 1085 As anticipated, NSEC is the most efficient authenticated denial 1086 mechanism as for response size and performance cost. The bottleneck 1087 of NSEC5 is the NSEC5 proof computation. If the proofs are 1088 precomputed for domain names in the zone, the server has to compute 1089 just one NSEC5 proof per answer. But it will still be more expensive 1090 than NSEC3 and the same applies for the response size. 1092 As for the response processing, the validation cost reflects from the 1093 records present in the response. Again, the NSEC validation seems to 1094 be the most inexpensive. However the difference between RSA and 1095 ECDSA verification performance is huge and for some parameters, NSEC3 1096 is faster to validate than NSEC5 and vice versa. 1098 14. Security Considerations 1100 14.1. Zone Enumeration Attacks 1102 NSEC5 is robust to zone enumeration via offline dictionary attacks by 1103 any attacker that does not know the NSEC5 private key. Without the 1104 private NSEC5 key, that attacker cannot compute the NSEC5 proof that 1105 corresponds to a given name; the only way it can learn the NSEC5 1106 proof value for a given name is by sending a queries for that name to 1107 the authoritative server. Without the NSEC5 proof value, the 1108 attacker cannot learn the NSEC5 hash value. Thus, even an attacker 1109 that collects the entire chain of NSEC5 RR for a zone cannot use 1110 offline attacks to "reverse" that NSEC5 hash values in these NSEC5 RR 1111 and thus learn which names are present in the zone. A formal 1112 cryptographic proof of this property is in [nsec5]. 1114 14.2. Hash Collisions 1116 Hash collisions between QNAME and the owner name of an NSEC5 RR may 1117 occur. When they do, it will be impossible to prove the non- 1118 existence of the colliding QNAME. However, with SHA-256, this is 1119 highly unlikely (on the order of 1 in 2^128). Note that DNSSEC 1120 already relies on the presumption that a cryptographic hash function 1121 is collision resistant, since these hash functions are used for 1122 generating and validating signatures and DS RRs. See also the 1123 discussion on key lengths in [nsec5]. 1125 14.3. Compromise of the Private NSEC5 Key 1127 NSEC5 requires authoritative servers to hold the private NSEC5 key, 1128 but not the private zone-signing keys or the private key-signing keys 1129 for the zone. The private NSEC5 key needs only be as secure as the 1130 DNSSEC records whose the privacy (against zone-enumeration attacks) 1131 that NSEC5 is protecting. This is because even an adversary that 1132 knows the private NSEC5 key cannot modify the contents of the zone; 1133 this is because the zone contents are signed using the private zone- 1134 signing key, while the private NSEC5 key is only used to compute 1135 NSEC5 proof values. Thus, a compromise of the private NSEC5 keys 1136 does not lead to a compromise of the integrity of the DNSSEC record 1137 in the zone; instead, all that is lost is privacy against zone 1138 enumeration, if the attacker that knows the private NSEC5 key can 1139 compute NSEC5 hashes offline, and thus launch offline dictionary 1140 attacks. Thus, a compromise of the private NSEC5 key effectively 1141 downgrades the security of NSEC5 to that of NSEC3. A formal 1142 cryptographic proof of this property is in [nsec5]. 1144 14.4. Key Length Considerations 1146 The NSEC5 key must be long enough to withstand attacks for as long as 1147 the privacy of the zone is important. Even if the NSEC5 key is 1148 rolled frequently, its length cannot be too short, because zone 1149 privacy may be important for a period of time longer than the 1150 lifetime of the key. (For example, an attacker might collect the 1151 entire chain of NSEC5 RR for the zone over one short period, and 1152 then, later (even after the NSEC5 key expires) perform an offline 1153 dictionary attack that attempt to "reverse" the NSEC5 hash values 1154 present in the NSEC5 RRs.) This is in contrast to zone-signing and 1155 key-signing keys used in DNSSEC; these keys, which ensure the 1156 authenticity and integrity of the zone contents need to remain secure 1157 only during their lifetime. 1159 14.5. Transitioning to a New NSEC5 Algorithm 1161 Although the NSEC5KEY RR formats include a hash algorithm parameter, 1162 this document does not define a particular mechanism for safely 1163 transitioning from one NSEC5 algorithm to another. When specifying a 1164 new hash algorithm for use with NSEC5, a transition mechanism MUST 1165 also be defined. It is possible that the only practical and 1166 palatable transition mechanisms may require an intermediate 1167 transition to an insecure state, or to a state that uses NSEC or 1168 NSEC3 records instead of NSEC5. 1170 15. IANA Considerations 1172 This document updates the IANA registry "Domain Name System (DNS) 1173 Parameters" in subregistry "Resource Record (RR) TYPEs", by defining 1174 the following new RR types: 1176 NSEC5KEY value XXX. 1178 NSEC5 value XXX. 1180 NSEC5PROOF value XXX. 1182 This document creates a new IANA registry for NSEC5 algorithms. This 1183 registry is named "DNSSEC NSEC5 Algorithms". The initial content of 1184 the registry is: 1186 0 is Reserved. 1188 1 is FDH-SHA256-SHA256. 1190 2-255 is Available for assignment. 1192 This document updates the IANA registry "DNS Security Algorithm 1193 Numbers" by defining following aliases: 1195 XXX is NSEC5-RSASHA256, alias for RSASHA256 (8). 1197 XXX is NSEC5-RSASHA512, alias for RSASHA512 (10). 1199 XXX is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13). 1201 XXX is NSEC5-ECDSAP384SHA384 alias for ECDSAP384SHA384 (14). 1203 16. Contributors 1205 This document would not be possible without help of Moni Naor 1206 (Weizmann Institute), Dimitrios Papadopoulos (Boston University), 1207 Sachin Vasant (Cisco Systems), Leonid Reyzin (Boston University), and 1208 Asaf Ziv (Weizmann Institute) who contributed to the design of NSEC5, 1209 and Ondrej Sury (CZ.NIC Labs) who provided advice on its 1210 implementation. 1212 17. References 1214 17.1. Normative References 1216 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1217 STD 13, RFC 1034, November 1987. 1219 [RFC1035] Mockapetris, P., "Domain names - implementation and 1220 specification", STD 13, RFC 1035, November 1987. 1222 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1223 Requirement Levels", BCP 14, RFC 2119, March 1997. 1225 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1226 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1227 RFC 2136, April 1997. 1229 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1230 Specification", RFC 2181, July 1997. 1232 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1233 NCACHE)", RFC 2308, March 1998. 1235 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 1236 Name System (DNS)", RFC 3110, May 2001. 1238 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1239 Standards (PKCS) #1: RSA Cryptography Specifications 1240 Version 2.1", RFC 3447, February 2003. 1242 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1243 Rose, "DNS Security Introduction and Requirements", RFC 1244 4033, March 2005. 1246 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1247 Rose, "Resource Records for the DNS Security Extensions", 1248 RFC 4034, March 2005. 1250 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1251 Rose, "Protocol Modifications for the DNS Security 1252 Extensions", RFC 4035, March 2005. 1254 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1255 Encodings", RFC 4648, October 2006. 1257 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1258 Security (DNSSEC) Hashed Authenticated Denial of 1259 Existence", RFC 5155, March 2008. 1261 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1262 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1264 17.2. Informative References 1266 [nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., 1267 Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC 1268 Zone Enumeration", July 2014. 1270 [nsec3gpu] 1271 Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, 1272 "GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network 1273 Computing and Applications (NCA), 2014. 1275 [nsec3walker] 1276 Bernstein, D., "Nsec3 walker", 2011, 1277 . 1279 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1280 Operational Practices, Version 2", RFC 6781, December 1281 2012. 1283 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1284 Existence in the DNS", RFC 7129, February 2014. 1286 Appendix A. Full Domain Hash Algorithm 1288 The Full Domain Hash (FDH) is a RSA-based scheme that allows 1289 authentication of hashes using public-key cryptography. 1291 In this document, the notation from [RFC3447] is used. 1293 Used parameters: 1295 (n, e) - RSA public key 1297 K - RSA private key 1299 k - length of the RSA modulus n in octets 1301 Fixed options: 1303 Hash - hash function to be used with MGF1 1305 Used primitives: 1307 I2OSP - Coversion of a nonnegative integer to an octet string as 1308 defined in Section 4.1 of [RFC3447] 1310 OS2IP - Coversion of an octet string to a nonnegative integer as 1311 defined in Section 4.2 of [RFC3447] 1313 RSASP1 - RSA signature primitive as defined in Section 5.2.1 of 1314 [RFC3447] 1316 RSAVP1 - RSA verification primitive as defined in Section 5.2.2 of 1317 [RFC3447] 1319 MGF1 - Mask Generation Function based on a hash function as 1320 defined in Section B.2.1 of [RFC3447] 1322 A.1. FDH signature 1324 FDH_SIGN(K, M) 1326 Input: 1328 K - RSA private key 1330 M - message to be signed, an octet string 1332 Output: 1334 S - signature, an octet string of length k 1336 Steps: 1338 1. EM = MGF1(M, k - 1) 1340 2. m = OS2IP(EM) 1342 3. s = RSASP1(K, m) 1344 4. S = I2OSP(s, k) 1346 5. Output S 1348 A.2. FDH verification 1350 FDH_VERIFY((n, e), M, S) 1352 Input: 1354 (n, e) - RSA public key 1356 M - message whose signature is to be verified, an octet string 1358 S - signature to be verified, an octet string of length k 1360 Output: 1362 "valid signature" or "invalid signature" 1364 Steps: 1366 1. s = OS2IP(S) 1368 2. m = RSAVP1((n, e), s) 1370 3. EM = I2OSP(m, k - 1) 1372 4. EM' = MGF1(M, k - 1) 1374 5. If EM and EM' are the same, output "valid signature"; else output 1375 "invalid signature". 1377 Appendix B. Change Log 1378 Note to RFC Editor: if this document does not obsolete an existing 1379 RFC, please remove this appendix before publication as an RFC. 1381 pre 00 - initial version of the document submitted to mailing list 1382 only 1384 00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA, 1385 clarify inputs and outputs for NSEC5 proof and NSEC5 hash 1386 computation 1388 01 - added Performance Considerations section 1390 Appendix C. Open Issues 1392 Note to RFC Editor: please remove this appendix before publication as 1393 an RFC. 1395 1. Consider alternative way to signalize NSEC5 support. The NSEC5 1396 could use only one DNSSEC algorithm identifier, and the actual 1397 algorithm to be used for signing can be the first octet in DNSKEY 1398 public key field and RRSIG signature field. Similar approach is 1399 used by PRIVATEDNS and PRIVATEOID defined in [RFC4034]. 1401 2. How to add new NSEC5 hashing algorithm. We will need to add new 1402 DNSSEC algorithm identifiers again. 1404 3. NSEC and NSEC3 define optional steps for hash collisions 1405 detection. We don't have a way to avoid them if they really 1406 appear (unlikely). We would have to drop the signing key and 1407 generate a new one. Which cannot be done instantly. 1409 4. Write Special Considerations section. 1411 5. Contributor list has to be completed. 1413 Authors' Addresses 1415 Jan Vcelak 1416 CZ.NIC 1417 Milesovska 1136/5 1418 Praha 130 00 1419 CZ 1421 EMail: jan.vcelak@nic.cz 1422 Sharon Goldberg 1423 Boston University 1424 111 Cummington St, MCS135 1425 Boston, MA 02215 1426 USA 1428 EMail: goldbe@cs.bu.edu