idnits 2.17.00 (12 Aug 2021) /tmp/idnits53551/draft-vcelak-nsec5-03.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 19, 2016) is 2069 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 5114 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Downref: Normative reference to an Informational RFC: RFC 7748 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'SECG1' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 23, 2017 D. Papadopoulos 6 Boston University 7 September 19, 2016 9 NSEC5, DNSSEC Authenticated Denial of Existence 10 draft-vcelak-nsec5-03 12 Abstract 14 The Domain Name System Security (DNSSEC) Extensions introduced the 15 NSEC resource record (RR) for authenticated denial of existence and 16 the NSEC3 for hashed authenticated denial of existence. The NSEC RR 17 allows for the entire zone contents to be enumerated if a server is 18 queried for carefully chosen domain names; N queries suffice to 19 enumerate a zone containing N names. The NSEC3 RR adds domain-name 20 hashing, which makes the zone enumeration harder, but not impossible. 21 This document introduces NSEC5, which provides an cryptographically- 22 proven mechanism that prevents zone enumeration. NSEC5 has the 23 additional advantage of not requiring private zone-signing keys to be 24 present on all authoritative servers for the zone. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 23, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 5 63 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 65 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 7 67 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 8 68 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 8 69 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 8 70 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 9 71 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 9 72 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 9 73 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 10 74 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 10 75 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 11 76 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 11 77 8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12 79 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 12 80 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 12 81 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 13 82 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 13 83 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14 84 9. Authoritative Server Considerations . . . . . . . . . . . . . 14 85 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 14 86 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 16 87 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 17 88 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 17 89 9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 17 90 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 17 91 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 18 92 11. Validator Considerations . . . . . . . . . . . . . . . . . . 18 93 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 18 94 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 19 95 11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 19 97 12. Special Considerations . . . . . . . . . . . . . . . . . . . 19 98 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 19 99 12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 20 100 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 20 101 13. Performance Considerations . . . . . . . . . . . . . . . . . 20 102 13.1. Performance of Cryptographic Operations . . . . . . . . 20 103 13.1.1. NSEC3 Hashing Performance . . . . . . . . . . . . . 20 104 13.1.2. NSEC5 Hashing Performance . . . . . . . . . . . . . 21 105 13.1.3. DNSSEC Signing Performance . . . . . . . . . . . . . 22 106 13.2. Authoritative Server Startup . . . . . . . . . . . . . . 22 107 13.3. NSEC5 Answer Generating and Processing . . . . . . . . . 23 108 13.4. Precomputed NSEC5PROOF Values . . . . . . . . . . . . . 24 109 13.5. Response Lengths . . . . . . . . . . . . . . . . . . . . 24 110 13.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . 25 111 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 112 14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 26 113 14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 26 114 14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 26 115 14.4. Key Length Considerations . . . . . . . . . . . . . . . 27 116 14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 27 117 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 118 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 119 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 120 17.1. Normative References . . . . . . . . . . . . . . . . . . 28 121 17.2. Informative References . . . . . . . . . . . . . . . . . 30 122 Appendix A. RSA Full Domain Hash Algorithm . . . . . . . . . . . 32 123 A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 32 124 A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 33 125 Appendix B. Elliptic Curve VRF . . . . . . . . . . . . . . . . . 33 126 B.1. ECVRF Hash To Curve . . . . . . . . . . . . . . . . . . . 34 127 B.2. ECVRF Auxiliary Functions . . . . . . . . . . . . . . . . 35 128 B.2.1. ECVRF Hash Points . . . . . . . . . . . . . . . . . . 35 129 B.2.2. ECVRF Proof To Hash . . . . . . . . . . . . . . . . . 36 130 B.2.3. ECVRF Decode Proof . . . . . . . . . . . . . . . . . 36 131 B.3. ECVRF Signing . . . . . . . . . . . . . . . . . . . . . . 37 132 B.4. ECVRF Verification . . . . . . . . . . . . . . . . . . . 37 133 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38 134 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . 39 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 137 1. Introduction 139 1.1. Rationale 141 The DNS Security Extensions (DNSSEC) provides data integrity 142 protection using public-key cryptography, while not requiring that 143 authoritative servers compute signatures on-the-fly. The content of 144 the zone is usually pre-computed and served as is. The evident 145 advantages of this approach are reduced performance requirements per 146 query, as well as not requiring private zone-signing keys to be 147 present on nameservers facing the network. 149 With DNSSEC, each resource record (RR) set in the zone is signed. 150 The signature is retained as an RRSIG RR directly in the zone. This 151 enables response authentication for data existing in the zone. To 152 ensure integrity of denying answers, an NSEC chain of all existing 153 domain names in the zone is constructed. The chain is made of RRs, 154 where each RR represents two consecutive domain names in canonical 155 order present in the zone. The NSEC RRs are signed the same way as 156 any other RRs in the zone. Non-existence of a name can be thus 157 proven by presenting a NSEC RR which covers the name. 159 As side-effect, however, the NSEC chain allows for enumeration of the 160 zone's contents by sequentially querying for the names immediately 161 following those in the most-recently retrieved NSEC record; N queries 162 suffice to enumerate a zone containing N names. As such, the NSEC3 163 hashed denial of existence was introduced to prevent zone 164 enumeration. In NSEC3, the original domain names in the NSEC chain 165 are replaced by their cryptographic hashes. While NSEC3 makes zone 166 enumeration more difficult, offline dictionary attacks are still 167 possible and have been demonstrated; this is because hashes may be 168 computed offline and the space of possible domain names is restricted 169 [nsec3walker][nsec3gpu]. 171 Zone enumeration can be prevented with NSEC3 if having the 172 authoritative server compute NSEC3 RRs on-the-fly, in response to 173 queries with denying responses. Usually, this is done with Minimally 174 Covering NSEC Records or NSEC3 White Lies [RFC7129]. The 175 disadvantage of this approach is a required presence of the private 176 key on all authoritative servers for the zone. This is often 177 undesirable, as the holder of the private key can tamper with the 178 zone contents, and having private keys on many network-facing servers 179 increases the risk that keys can be compromised. 181 To prevent zone content enumeration without keeping private keys on 182 all authoritative servers, NSEC5 replaces the unkeyed cryptographic 183 hash function used in NSEC3 with a public-key hashing scheme. 184 Hashing in NSEC5 is performed with a separate NSEC5 key. The public 185 portion of this key is distributed in an NSEC5KEY RR, and is used to 186 validate NSEC5 hash values. The private portion of the NSEC5 key is 187 present on all authoritative servers for the zone, and is used to 188 compute hash values. 190 Importantly, the NSEC5KEY key cannot be used to modify the contents 191 of the zone. Thus, any compromise of the private NSEC5 key does not 192 lead to a compromise of zone contents. All that is lost is privacy 193 against zone enumeration, effectively downgrading the security of 194 NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of 195 security, available in [nsec5]. 197 The NSEC5 is not intended to replace NSEC or NSEC3. It is designed 198 as an alternative mechanism for authenticated denial of existence. 200 1.2. Requirements 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 1.3. Terminology 208 The reader is assumed to be familiar with the basic DNS and DNSSEC 209 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 210 [RFC4035], and subsequent RFCs that update them: [RFC2136], 211 [RFC2181], [RFC2308], and [RFC5155]. 213 The following terminology is used through this document: 215 Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as 216 specified in [RFC4648]. The padding characters ("=") are not used 217 in NSEC5 specification. 219 Base64: The "Base 64 Encoding" as specified in [RFC4648]. 221 NSEC5 proof: A signed hash of a domain name (hash-and-sign 222 paradigm). A holder of the private key (e.g., authoritative 223 server) can compute the proof. Anyone knowing the public key 224 (e.g., client) can verify it's validity. 226 NSEC5 hash: A cryptographic hash (digest) of an NSEC5 proof. If the 227 NSEC5 proof is known, anyone can compute and verify it's NSEC5 228 hash. 230 NSEC5 algorithm: A pair of algorithms used to compute NSEC5 proofs 231 and NSEC5 hashes. 233 2. Backward Compatibility 235 The specification describes a protocol change that is not backward 236 compatible with [RFC4035] and [RFC5155]. NSEC5-unaware resolver will 237 fail to validate responses introduced by this document. 239 To prevent NSEC5-unaware resolvers from attempting to validate the 240 responses, new DNSSEC algorithms identifiers are introduced, the 241 identifiers alias with existing algorithm numbers. The zones signed 242 according to this specification MUST use only these algorithm 243 identifiers, thus NSEC5-unaware resolvers will treat the zone as 244 insecure. 246 The new algorithm identifiers defined by this document are listed in 247 Section 15. 249 3. How NSEC5 Works 251 To prove non-existence of a domain name in a zone, NSEC uses a chain 252 built from domain names present in the zone. NSEC3 replaces the 253 original domain names by their cryptographic hashes. NSEC5 is very 254 similar to NSEC3, except that the cryptographic hash is replaced by 255 hashes computed using a verifiable random function (VRF). A VRF is 256 essentially the public-key version of a keyed cryptographic hash. A 257 VRF comes with a public/private key pair, and only the holder of the 258 private key can compute the hash, but anyone with public key can 259 verify the hash. 261 In NSEC5, the original domain name is hashed twice: 263 1. First, the domain name is hashed using a VRF keyed with the NSEC5 264 private key; the result is called the NSEC5 proof. Only an 265 authoritative server that knows the private NSEC5 key can compute 266 the NSEC5 proof. Any client that knows the public NSEC5 key can 267 validate the NSEC5 proof. 269 2. Second, the NSEC5 proof is hashed. The result is called the 270 NSEC5 hash value. This hash can be computed by any party that 271 knows the input NSEC5 proof. 273 The NSEC5 hash determines the position of a domain name in an NSEC5 274 chain. That is, all the NSEC5 hashes for a zone are sorted in their 275 canonical order, and each consecutive pair forms an NSEC5 RR. 277 To prove an non-existence of a particular domain name in response to 278 a query, the server computes the NSEC5 proof (using the private NSEC5 279 key) on the fly. Then it uses the NSEC5 proof to compute the 280 corresponding NSEC5 hash. It then identifies the NSEC5 RR that 281 covers the NSEC5 hash. In the response message, the server returns 282 the NSEC5 RR, it's corresponding signature (RRSIG RRset), and 283 synthesized NSEC5PROOF RR containing the NSEC5 proof it computed on 284 the fly. 286 To validate the response, the client first uses the public NSEC5 key 287 (stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof 288 corresponds with the domain name to be disproved. Then, the client 289 computes the NSEC5 hash from the NSEC5 proof and checks that it is 290 covered by the NSEC5 RR. Finally, it checks that the signature on 291 the NSEC5 RR is valid. 293 4. NSEC5 Algorithms 295 The algorithms used for NSEC5 authenticated denial are independent of 296 the algorithms used for DNSSEC signing. An NSEC5 algorithm defines 297 how the NSEC5 proof and the NSEC5 hash is computed and validated. 299 The input for the NSEC5 proof computation is an RR owner name in the 300 canonical form in the wire format and an NSEC5 private key; the 301 output is an octet string. 303 The input for the NSEC5 hash computation is the corresponding NSEC5 304 proof; the output is an octet string. 306 This document defines RSAFDH-SHA256-SHA256 NSEC5 algorithm as 307 follows: 309 o NSEC5 proof is computed using an RSA based Full Domain Hash (FDH) 310 signature with SHA-256 hash function used internally for input 311 preprocessing. The signature and verification is formally 312 specified in Appendix A. 314 o NSEC5 hash is computed by hashing the NSEC5 proof with the SHA-256 315 hash function as specified in [RFC6234]. 317 o The public key format to be used in NSEC5KEY RR is defined in 318 Section 2 of [RFC3110] and thus is the same as the format used to 319 store RSA public keys in DNSKEY RRs. 321 This document defines EC-P256-SHA256 NSEC5 algorithm as follows: 323 o NSEC5 proof is computed using an Elliptic Curve VRF with FIPS 324 186-3 P-256 curve. The proof computation and verification is 325 formally specified in Appendix B. The curve parameters are 326 specified in [FIPS-186-3] (Section D.1.2.3) and [RFC5114] 327 (Section 2.6). 329 o NSEC5 hash is x-coordinate of the group element gamma from the 330 NSEC5 proof (specified in Appendix B), encoded as a fixed-width 331 32-octet unsigned integer in network byte order. In practice, the 332 hash is a substring of the proof ranging from 2nd to 33th octet of 333 the proof inclusive. 335 o The public key format to be used in NSEC5KEY RR is defined in 336 Section 4 of [RFC6605] and thus is the same as the format used to 337 store ECDSA public keys in DNSKEY RRs. 339 This document defines EC-ED25519-SHA256 NSEC5 as follows: 341 o NSEC5 proof is the same as with EC-P256-SHA256 but using Ed25519 342 elliptic curve with parameters defined in [RFC7748] (Section 4.1). 344 o NSEC5 hash is the same as with EC-P256-SHA256. 346 o The public key format to be used in NSEC5KEY RR is defined in 347 Section 3 of [I-D.ietf-curdle-dnskey-ed25519] and thus is the same 348 as the format used to store Ed25519 public keys in DNSKEY RRs. 350 5. The NSEC5KEY Resource Record 352 The NSEC5KEY RR stores an NSEC5 public key. The key allows clients 353 to verify a validity of NSEC5 proof sent by a server. 355 5.1. NSEC5KEY RDATA Wire Format 357 The RDATA for NSEC5KEY RR is as shown below: 359 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Algorithm | Public Key / 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Algorithm is a single octet identifying NSEC5 algorithm. 367 Public Key is a variable sized field holding public key material for 368 NSEC5 proof verification. 370 5.2. NSEC5KEY RDATA Presentation Format 372 The presentation format of the NSEC5KEY RDATA is as follows: 374 The Algorithm field is represented as an unsigned decimal integer. 376 The Public Key field is represented in Base64 encoding. Whitespace 377 is allowed within the Base64 text. 379 6. The NSEC5 Resource Record 381 The NSEC5 RR provides authenticated denial of existence for an RRset. 382 One NSEC5 RR represents one piece of an NSEC5 chain, proving 383 existence of RR types present at the original domain name and also 384 non-existence of other domain names in a part of the hashed domain 385 name space. 387 6.1. NSEC5 RDATA Wire Format 389 The RDATA for NSEC5 RR is as shown below: 391 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 392 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 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Key Tag | Flags | Next Length | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Next Hashed Owner Name / 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 / Type Bit Maps / 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 Key Tag field contains the key tag value of the NSEC5KEY RR that 402 validates the NSEC5 RR, in network byte order. The value is computed 403 from the NSEC5KEY RDATA using the same algorithm, which is used to 404 compute key tag values for DNSKEY RRs. The algorithm is defined in 405 [RFC4034]. 407 Flags field is a single octet. The meaning of individual bits of the 408 field is defined in Section 6.2. 410 Next length is an unsigned single octet specifying the length of the 411 Next Hashed Owner Name field in octets. 413 Next Hashed Owner Name field is a sequence of binary octets. It 414 contains an NSEC5 hash of the next domain name in the NSEC5 chain. 416 Type Bit Maps is a variable sized field encoding RR types present at 417 the original owner name matching the NSEC5 RR. The format of the 418 field is equivalent to the format used in NSEC3 RR, described in 419 [RFC5155]. 421 6.2. NSEC5 Flags Field 423 The following one-bit NSEC5 flags are defined: 425 0 1 2 3 4 5 6 7 426 +-+-+-+-+-+-+-+-+ 427 | |W|O| 428 +-+-+-+-+-+-+-+-+ 430 O - Opt-Out flag 432 W - Wildcard flag 434 All the other flags are reserved for future use and MUST be zero. 436 The Opt-Out flag has the same semantics as in NSEC3. The definition 437 and considerations in [RFC5155] are valid, except that NSEC3 is 438 replaced by NSEC5. 440 The Wildcard flag indicates that a wildcard synthesis is possible at 441 the original domain name level (i.e., there is a wildcard node 442 immediately descending from the immediate ancestor of the original 443 domain name). The purpose of the Wildcard flag is to reduce a 444 maximum number of RRs required for authenticated denial of existence 445 proof. 447 6.3. NSEC5 RDATA Presentation Format 449 The presentation format of the NSEC5 RDATA is as follows: 451 The Key Tag field is represented as an unsigned decimal integer. 453 The Flags field is represented as an unsigned decimal integer. 455 The Next Length field is not represented. 457 The Next Hashed Owner Name field is represented as a sequence of 458 case-insensitive Base32hex digits without any whitespace and without 459 padding. 461 The Type Bit Maps representation is equivalent to the representation 462 used in NSEC3 RR, described in [RFC5155]. 464 7. The NSEC5PROOF Resource Record 466 The NSEC5PROOF record is synthesized by the authoritative server on- 467 the-fly. The record contains the NSEC5 proof, proving a position of 468 the owner name in an NSEC5 chain. 470 7.1. NSEC5PROOF RDATA Wire Format 472 The RDATA for NSEC5PROOF is as as shown below: 474 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Key Tag | Owner Name Hash / 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Key Tag field contains the key tag value of the NSEC5KEY RR that 481 validates the NSEC5PROOF RR, in network byte order. 483 Owner Name Hash is a variable sized sequence of binary octets 484 encoding the NSEC5 proof of the owner name of the RR. 486 7.2. NSEC5PROOF RDATA Presentation Format 488 The presentation format of the NSEC5PROOF RDATA is as follows: 490 The Key Tag field is represented as an unsigned decimal integer. 492 The Owner Name Hash is represented in Base64 encoding. Whitespace is 493 allowed within the Base64 text. 495 8. NSEC5 Proofs 497 This section summarizes all possible types of authenticated denial of 498 existence. For each type the following lists are included: 500 1. Facts to prove. The minimum amount of information an 501 authoritative server must provide to a client to assure the 502 client that the response content is valid. 504 2. Authoritative server proofs. NSEC5 RRs an authoritative server 505 must include in a response to prove the listed facts. 507 3. Validator checks. Individual checks a validating server is 508 required to perform on a response. The response content is 509 considered valid only if all the checks pass. 511 If NSEC5 is said to match a domain name, the owner name of the NSEC5 512 RR has to be equivalent to an NSEC5 hash of that domain name. If an 513 NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain 514 name must lay strictly between that NSEC5 RR's Owner Name and Next 515 Hashed Owner Name. 517 8.1. Name Error Responses 519 Facts to prove: 521 No RRset matching the QNAME exactly exists. 523 No RRset matching the QNAME via wildcard expansion exists. 525 The QNAME does not fall into a delegation. 527 The QNAME does not fall into a DNAME redirection. 529 Authoritative server proofs: 531 Closest encloser. 533 Next closer name. 535 Validator checks: 537 Closest encloser belongs to the zone. 539 Closest encloser has the Wildcard flag cleared. 541 Closest encloser does not have NS without SOA in the Type Bit Map. 543 Closest encloser does not have DNAME in the Type Bit Maps. 545 Next closer name is derived correctly. 547 8.2. No Data Responses 549 The processing of a No Data response for DS QTYPE differs if the Opt- 550 Out is in effect. For DS QTYPE queries, the validator has two 551 possible checking paths. The correct path can be simply decided by 552 inspecting if the NSEC5 RR in the response matches the QNAME. 554 Note that the Opt-Out is valid only for DS QTYPE queries. 556 8.2.1. No Data Response, Opt-Out Not In Effect 558 Facts to prove: 560 An RRset matching the QNAME exists. 562 No QTYPE RRset matching the QNAME exists. 564 No CNAME RRset matching the QNAME exists. 566 Authoritative server proofs: 568 QNAME. 570 Validator checks: 572 The NSEC5 RR exactly matches the QNAME. 574 The NSEC5 RR does not have QTYPE in the Type Bit Map. 576 The NSEC5 RR does not have CNAME in the Type Bit Map. 578 8.2.2. No Data Response, Opt-Out In Effect 580 Facts to prove: 582 The delegation is not covered by the NSEC5 chain. 584 Authoritative server proofs: 586 Closest provable encloser. 588 Validator checks: 590 Closest provable encloser is in zone. 592 Closest provable encloser covers (not matches) the QNAME. 594 Closest provable encloser has the Opt-Out flag set. 596 8.3. Wildcard Responses 598 Facts to prove: 600 No RRset matching the QNAME exactly exists. 602 No wildcard closer to the QNAME exists. 604 Authoritative server proofs: 606 Next closer name. 608 Validator checks: 610 Next closer name is derived correctly. 612 Next closer name covers (not matches). 614 8.4. Wildcard No Data Responses 616 Facts to prove: 618 No RRset matching the QNAME exactly exists. 620 No QTYPE RRset exists at the wildcard matching the QNAME. 622 No CNAME RRset exists at the wildcard matching the QNAME. 624 No wildcard closer to the QNAME exists. 626 Authoritative server proofs: 628 Source of synthesis (i.e., wildcard at closest encloser). 630 Next closer name. 632 Validator checks: 634 Source of synthesis matches exactly the QNAME. 636 Source of synthesis does not have QTYPE in the Type Bit Map. 638 Source of synthesis does not have CNAME in the Type Bit Map. 640 Next closer name is derived correctly. 642 Next closer name covers (not matches). 644 9. Authoritative Server Considerations 646 9.1. Zone Signing 648 Zones using NSEC5 MUST satisfy the same properties as described in 649 Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition, 650 the following conditions MUST be satisfied as well: 652 o If the original owner name has a wildcard label immediately 653 descending from the original owner name, the corresponding NSEC5 654 RR MUST have the Wildcard flag set in the Flags field. Otherwise, 655 the flag MUST be cleared. 657 o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5 658 public key allowing verification of the current NSEC5 chain. 660 The following steps describe one possible method to properly add 661 required NSEC5 related records into a zone. This is not the only 662 such existing method. 664 1. Select an algorithm for NSEC5. Generate the public and private 665 NSEC5 keys. 667 2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5 668 key. 670 3. For each unique original domain name in the zone and each empty 671 non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names 672 of unsigned delegations MAY be excluded. 674 A. The owner name of the NSEC5 RR is the NSEC5 hash of the 675 original owner name encoded in Base32hex without padding, 676 prepended as a single label to the zone name. 678 B. Set the Key Tag field to be the key tag corresponding to the 679 public NSEC5 key. 681 C. Clear the Flags field. If Opt-Out is being used, set the 682 Opt-Out flag. If there is a wildcard label directly 683 descending from the original domain name, set the Wildcard 684 flag. Note that the wildcard can be an empty non-terminal 685 (i.e., the wildcard synthesis does not take effect and 686 therefore the flag is not to be set). 688 D. Set the Next Length field to a value determined by the used 689 NSEC5 algorithm. Leave the Next Hashed Owner Name field 690 blank. 692 E. Set the Type Bit Maps field based on the RRsets present at 693 the original owner name. 695 4. Sort the set of NSEC5 RRs into canonical order. 697 5. For each NSEC5 RR, set the Next Hashed Owner Name field by using 698 the owner name of the next NSEC5 RR in the canonical order. If 699 the updated NSEC5 is the last NSEC5 RR in the chain, the owner 700 name of the first NSEC5 RR in the chain is used instead. 702 The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA 703 RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA 704 minimum TTL field. 706 Notice that a use of Opt-Out is not indicated in the zone. This does 707 not affect the ability of a server to prove insecure delegations. 708 The Opt-Out MAY be part of the zone-signing tool configuration. 710 9.2. Zone Serving 712 This specification modifies DNSSEC-enabled DNS responses generated by 713 authoritative servers. In particular, it replaces use of NSEC or 714 NSEC3 RRs in such responses with NSEC5 RRs and adds on-the-fly 715 computed NSEC5PROOF RRs. 717 The authenticated denial of existence proofs in NSEC5 are almost the 718 same as in NSEC3. However, due to introduction of Wildcard flag in 719 NSEC5 RRs, the NSEC5 proof consists from (up to) two NSEC5 RRs, 720 instead of (up to) three. 722 According to a type of a response, an authoritative server MUST 723 include NSEC5 RRs in a response as defined in Section 8. For each 724 NSEC5 RR in the response a matching RRSIG RRset and a synthesized 725 NSEC5PROOF MUST be added as well. 727 A synthesized NSEC5PROOF RR has the owner name set to a domain name 728 exactly matching the name required for the proof. The class and TTL 729 of the RR MUST be the same as the class and TTL value of the 730 corresponding NSEC5 RR. The RDATA are set according to the 731 description in Section 7.1. 733 Notice, that the NSEC5PROOF owner name can be a wildcard (e.g., 734 source of synthesis proof in wildcard No Data responses). The name 735 also always matches the domain name required for the proof while the 736 NSEC5 RR may only cover (not match) the name in the proof (e.g., 737 closest encloser in Name Error responses). 739 If NSEC5 is used, an answering server MUST use exactly one NSEC5 740 chain for one signed zone. 742 NSEC5 MUST NOT be used in parallel with NSEC, NSEC3, or any other 743 authenticated denial of existence mechanism that allows for 744 enumeration of zone contents. 746 Similarly to NSEC3, the owner names of NSEC5 RRs are not represented 747 in the NSEC5 chain and therefore NSEC5 records deny their own 748 existence. The desired behavior caused by this paradox is the same 749 as described in Section 7.2.8 of [RFC5155]. 751 9.3. NSEC5KEY Rollover Mechanism 753 Replacement of the NSEC5 key implies generating a new NSEC5 chain. 754 The NSEC5KEY rollover mechanism is similar to "Pre-Publish Zone 755 Signing Key Rollover" as specified in [RFC6781]. The NSEC5KEY 756 rollover MUST be performed as a sequence of the following steps: 758 1. A new public NSEC5 key is added into the NSEC5KEY RRset in the 759 zone apex. 761 2. The old NSEC5 chain is replaced by a new NSEC5 chain constructed 762 using the new key. This replacement MUST happen as a single 763 atomic operation; the server MUST NOT be responding with RRs from 764 both the new and old chain at the same time. 766 3. The old public key is removed from the NSEC5KEY RRset in the zone 767 apex. 769 The minimal delay between the steps 1. and 2. MUST be the time it 770 takes for the data to propagate to the authoritative servers, plus 771 the TTL value of the old NSEC5KEY RRset. 773 The minimal delay between the steps 2. and 3. MUST be the time it 774 takes for the data to propagate to the authoritative servers, plus 775 the maximum zone TTL value of any of the data in the previous version 776 of the zone. 778 9.4. Secondary Servers 780 This document does not define mechanism to distribute NSEC5 private 781 keys. See Section 14.3 for discussion on the security requirements 782 for NSEC5 private keys. 784 9.5. Zones Using Unknown Hash Algorithms 786 Zones that are signed with unknown NSEC5 algorithm or by an 787 unavailable NSEC5 private key cannot be effectively served. Such 788 zones SHOULD be rejected when loading and servers SHOULD respond with 789 RCODE=2 (Server failure) when handling queries that would fall under 790 such zones. 792 9.6. Dynamic Updates 794 A zone signed using NSEC5 MAY accept dynamic updates. The changes to 795 the zone MUST be performed in a way, that the zone satisfies the 796 properties specified in Section 9.1 at any time. 798 It is RECOMMENDED that the server rejects all updates containing 799 changes to the NSEC5 chain (or related RRSIG RRs) and performs itself 800 any required alternations of the NSEC5 chain induced by the update. 802 Alternatively, the server MUST verify that all the properties are 803 satisfied prior to performing the update atomically. 805 10. Resolver Considerations 807 The same considerations as described in Section 9 of [RFC5155] for 808 NSEC3 apply to NSEC5. In addition, as NSEC5 RRs can be validated 809 only with appropriate NSEC5PROOF RRs, the NSEC5PROOF RRs MUST be all 810 together cached and included in responses with NSEC5 RRs. 812 11. Validator Considerations 814 11.1. Validating Responses 816 The validator MUST ignore NSEC5 RRs with Flags field values other 817 than the ones defined in Section 6.2. 819 The validator MAY treat responses as bogus if the response contains 820 NSEC5 RRs that refer to a different NSEC5KEY. 822 According to a type of a response, the validator MUST verify all 823 conditions defined in Section 8. Prior to making decision based on 824 the content of NSEC5 RRs in a response, the NSEC5 RRs MUST be 825 validated. 827 To validate a denial of existence, zone NSEC5 public keys are 828 required in addition to DNSSEC public keys. Similarly to DNSKEY RRs, 829 the NSEC5KEY RRs are present in the zone apex. 831 The NSEC5 RR is validated as follows: 833 1. Select a correct NSEC5 public key to validate the NSEC5PROOF. 834 The Key Tag value of the NSEC5PROOF RR must match with the key 835 tag value computed from the NSEC5KEY RDATA. 837 2. Validate the NSEC5 proof present in the NSEC5PROOF Owner Name 838 Hash field using the NSEC5 public key. If there are multiple 839 NSEC5KEY RRs matching the key tag, at least one of the keys must 840 validate the NSEC5 proof. 842 3. Compute the NSEC5 hash value from the NSEC5 proof and check if 843 the response contains NSEC5 RR matching or covering the computed 844 NSEC5 hash. The TTL values of the NSEC5 and NSEC5PROOF RRs must 845 be the same. 847 4. Validate the signature of the NSEC5 RR. 849 If the NSEC5 RR fails to validate, it MUST be ignored. If some of 850 the conditions required for an NSEC5 proof is not satisfied, the 851 response MUST be treated as bogus. 853 Notice that determining closest encloser and next closer name in 854 NSEC5 is easier than in NSEC3. NSEC5 and NSEC5PROOF RRs are always 855 present in pairs in responses and the original owner name of the 856 NSEC5 RR matches the owner name of the NSEC5PROOF RR. 858 11.2. Validating Referrals to Unsigned Subzones 860 The same considerations as defined in Section 8.9 of [RFC5155] for 861 NSEC3 apply to NSEC5. 863 11.3. Responses With Unknown Hash Algorithms 865 A validator MUST ignore NSEC5KEY RRs with unknown NSEC5 algorithms. 866 The practical result of this is that zones sighed with unknown 867 algorithms will be considered bogus. 869 12. Special Considerations 871 12.1. Transition Mechanism 873 TODO: Not finished. Following information will be covered: 875 o Transition from NSEC or NSEC3. 877 o Transition from NSEC5 to NSEC/NSEC3 879 o Transition to new algorithms within NSEC5 881 Quick notes on transition from NSEC/NSEC3 to NSEC5: 883 1. Publish NSEC5KEY RR. 885 2. Wait for data propagation to slaves and cache expiration. 887 3. Instantly switch answering from NSEC/NSEC3 to NSEC5. 889 Quick notes on transition from NSEC5 to NSEC/NSEC3: 891 1. Instantly switch answering from NSEC5 to NSEC/NSEC3. 893 2. Wait for NSEC5 RRs expiration in caches. 895 3. Remove NSEC5KEY RR from the zone. 897 12.2. NSEC5 Private Keys 899 This document does not define format to store NSEC5 private key. Use 900 of standardized and adopted format is RECOMMENDED. 902 The NSEC5 private key MAY be shared between multiple zones, however a 903 separate key is RECOMMENDED for each zone. 905 12.3. Domain Name Length Restrictions 907 The NSEC5 creates additional restrictions on domain name lengths. In 908 particular, zones with names that, when converted into hashed owner 909 names exceed the 255 octet length limit imposed by [RFC1035], cannot 910 use this specification. 912 The actual maximum length of a domain name depends on the length of 913 the zone name and used NSEC5 algorithm. 915 All NSEC5 algorithms defined in this document use 256-bit NSEC5 hash 916 values. Such a value can be encoded in 52 characters in Base32hex 917 without padding. When constructing the NSEC5 RR owner name, the 918 encoded hash is prepended to the name of the zone as a single label 919 which includes the length field of a single octet. The maximal 920 length of the zone name in wire format is therefore 202 octets (255 - 921 53). 923 13. Performance Considerations 925 This section compares NSEC, NSEC3, and NSEC5 with regards to the size 926 of denial-of-existence responses and performance impact on the DNS 927 components. 929 13.1. Performance of Cryptographic Operations 931 Additional performance costs depend on the costs of cryptographic 932 operations to a great extent. The following results were retrieved 933 with OpenSSL 1.0.2g, running an ordinary laptop on a single-core of a 934 CPU manufactured in 2016. The parameters of cryptographic operations 935 were chosen to reflect the parameters used in the real-world 936 application of DNSSEC. 938 13.1.1. NSEC3 Hashing Performance 940 NSEC3 uses multiple iterations of the SHA-1 function with an 941 arbitrary salt. The input of the first iteration is the domain name 942 in wire format together with binary salt; the input of the subsequent 943 iterations is the binary digest and the salt. We can assume that the 944 input size will be smaller than 32 octets for most executions. 946 The measured implementation gives a stable performance for small 947 input blocks up to 32 octets. About 4e6 hashes per second can be 948 computed given these parameters. 950 The number of additional iterations in NSEC3 parameters will probably 951 vary between 0 and 20 in reality. Therefore we can expect the NSEC3 952 hash computation performance to be between 2e5 and 4e6 hashes per 953 second. 955 13.1.2. NSEC5 Hashing Performance 957 The NSEC5 hash is computed in two steps: NSEC5 proof computation 958 followed by hashing of the result. As the proof computation involves 959 relatively expensive RSA/EC cryptographic operations, the final 960 hashing will have insignificant impact on the overall performance. 961 We can also expect difference between NSEC5 hashing (signing) and 962 verification time. 964 The measurement results for various NSEC5 algorithms and key sizes 965 are summarized in the following table: 967 +----------------------+--------+-----------+----------+------------+ 968 | NSEC5 algorithm | Key | Proof | Perf. | Perf. | 969 | | size | size | (hash/s) | (verify/s) | 970 | | (bits) | (octets) | | | 971 +----------------------+--------+-----------+----------+------------+ 972 | RSAFDH-SHA256-SHA256 | 1024 | 128 | 9500 | 120000 | 973 | RSAFDH-SHA256-SHA256 | 2048 | 256 | 1500 | 46000 | 974 | RSAFDH-SHA256-SHA256 | 4096 | 512 | 200 | 14000 | 975 | EC-P256-SHA256 | 256 | 81 | 4700 | 4000 | 976 +----------------------+--------+-----------+----------+------------+ 978 Picking a moderate key size of 2048-bits for RSAFDH-SHA256-SHA256, 979 the NSEC5 hash computation performance will be in the order of 10^3 980 issued hashes per second and 10^4 validated hashes per second. 982 EC-P256-SHA256 trades off verification performance for shorter proof 983 size and faster query processing at the nameserver. In that case, 984 both hash computation and verification performance will be in the 985 order of 10^3 hashes per second. 987 13.1.3. DNSSEC Signing Performance 989 For completeness, the following table sumarrizes the signing and 990 verification performance for different DNSSEC signing algorithms: 992 +------------------+--------+-----------+-------------+-------------+ 993 | Algorithm | Key | Signature | Performance | Performance | 994 | | size | size | (sign/s) | (verify/s) | 995 | | (bits) | (octets) | | | 996 +------------------+--------+-----------+-------------+-------------+ 997 | RSASHA256 | 1024 | 128 | 9000 | 140000 | 998 | RSASHA256 | 2048 | 256 | 1500 | 47000 | 999 | RSASHA256 | 4096 | 512 | 200 | 14000 | 1000 | ECDSAP256SHA256 | 256 | 64 | 7400 | 4000 | 1001 | ECDSAP384SHA384 | 384 | 96 | 5000 | 1000 | 1002 | ECDSAP256SHA256* | 256 | 64 | 24000 | 11000 | 1003 +------------------+--------+-----------+-------------+-------------+ 1005 * highly optimized implementation 1007 The retrieved values are important primarily for the purpose of 1008 evaluating performance of response validation. The signing 1009 performance is usually not that important because the zone is signed 1010 offline. However, when online signing is used, signing performace is 1011 also important. 1013 13.2. Authoritative Server Startup 1015 This section compares additional server startup cost based on the 1016 used authenticated denial mechanism. 1018 NSEC There are no special requirements on processing of a NSEC- 1019 signed zone during an authoritative server startup. The server 1020 handles the NSEC RRs the same way as any other records in the 1021 zone. 1023 NSEC3 The authoritative server can precompute NSEC3 hashes for all 1024 domain names in the NSEC3-signed zone on startup. With respect to 1025 query answering, this can speed up inclusion of NSEC3 RRs for 1026 existing domain names (i.e., Closest provable encloser and QNAME 1027 for No Data response). 1029 NSEC5 Very similar considerations apply for NSEC3 and NSEC5. There 1030 is a strong motivation to store the NSEC5PROOF values for existing 1031 domain names in order to reduce query processing time. A possible 1032 way to do this, without inceasing the zone size, is to store 1033 NSEC5PROOF values in a persistent storage structure, as explained 1034 in Section 13.4. 1036 The impact of NSEC3 and NSEC5 on the authoritative server startup 1037 performance is greatly implementation specific. The server software 1038 vendor has to seek balance between answering performance, startup 1039 slowdown, and additional storage cost. 1041 13.3. NSEC5 Answer Generating and Processing 1043 An authenticated denial proof is required for No Data, Name Error, 1044 Wildcard Match, and Wildcard No Data answer. The number of required 1045 records depends on used authenticated denial mechanism. Their size, 1046 generation cost, and validation cost depend on various zone and 1047 signing parameters. 1049 In the worst case, the following additional records authenticating 1050 the denial will be included into the response: 1052 o Up to two NSEC records and their associated RRSIG records. 1054 o Up to three NSEC3 records and their associated RRSIG records. 1056 o Up to two NSEC5 records and their associated NSEC5PROOF and RRSIG 1057 records. 1059 The following list summarizes additional cryptographic operations 1060 performed by the authoritative server for authenticated denial worst- 1061 case scenario: 1063 o NSEC: 1065 * No cryptographic operations required. 1067 o NSEC3: 1069 * NSEC3 hash for Closest provable encloser 1071 * NSEC3 hash for Next closer name 1073 * NSEC3 hash for wildcard at the closest encloser 1075 o NSEC5: 1077 * NSEC5 proof and hash for Closest provable encloser (possibly 1078 precomputed) 1080 * NSEC5 proof and hash for Next closer name 1082 13.4. Precomputed NSEC5PROOF Values 1084 As we dicussed in the previous section, the worst-case authenticated 1085 denial scenario with NSEC5 entails the computation of two NSEC5 proof 1086 and hash values, one for the Closest provable encloser and one for 1087 the Next closer name. For the latter, these values must be computed 1088 from scratch at query time. However, the proof value for the former 1089 had been computed during startup, without being stored, as part of 1090 the NSEC5 hash computation. 1092 The query processing time can be drastically reduced if the NSEC5 1093 proof values for all existing names in the zone are stored by the 1094 authoritative. In that case, the authoritative identifies the 1095 Closest provable encloser name for the given query and looks up both 1096 the NSEC5 proof and hash value. This limits the necessary 1097 computation during query processing to just one NSEC5 proof and hash 1098 value (that of the Next closer name). For both variants of NSEC5, 1099 the proof computation time strongly dominates the final NSEC5 hash 1100 computation. Therefore, by storing NSEC5 proof values query 1101 processing time is almost halved. 1103 On the other hand, this slightly increases the used storage space at 1104 the authoritative. It should be noted that these values should not 1105 be part of the zone explicitly. They can be stored at an additional 1106 data structure. 1108 13.5. Response Lengths 1110 [nsec5ecc] precisely measured response lengths for NSEC, NSEC3 and 1111 NSEC5 using empirical data from a sample second-level domain 1112 containing about 1000 names. The sample zone was signed several 1113 times with different DNSSEC signing algorithms and different 1114 authenticated denial of existence mechanisms. 1116 For DNSKEY algorithms, RSASHA256 (2048-bit) and ECDSAPSHA256 were 1117 considered. For authenticated denial, NSEC, NSEC3, NSEC5 with 1118 RSAFDH-SHA256-SHA256 (2048-bit), and NSEC5 with EC-P256-SHA256 were 1119 considered. (Note that NSEC5 with EC-ED25519-SHA256 is identical to 1120 EC-P256-SHA256 as for response size.) 1122 For each instance of the signed zone, Name Error responses were 1123 collected by issuing DNS queries with a random five-character label 1124 prepended to each actual record name from the zone. The average and 1125 standard deviation of the length of these responses are shown below. 1127 +-----------+--------------+------------------+---------------------+ 1128 | | DNSKEY | Average length | Standard deviation | 1129 | | algorithm | (octets) | (octets) | 1130 +-----------+--------------+------------------+---------------------+ 1131 | NSEC | RSA | 1116 | 48 | 1132 | NSEC | ECDSA | 543 | 24 | 1133 | NSEC3 | RSA | 1440 | 170 | 1134 | NSEC3 | ECDSA | 752 | 84 | 1135 | NSEC5/RSA | RSA | 1767 | 7 | 1136 | NSEC5/EC | ECDSA | 839 | 7 | 1137 +-----------+--------------+------------------+---------------------+ 1139 13.6. Summary 1141 As anticipated, NSEC and NSEC3 are the most efficient authenticated 1142 denial mechanisms, in terms of computation for authoritative server 1143 and resolver. NSEC also has the shortest response lengths. However, 1144 these mechanisms do not prevent zone enumeration. 1146 Regarding mechanisms that do prevent zone enumeration, NSEC5 should 1147 be examined in contrast with Minimally Covering NSEC Records or NSEC3 1148 White Lies [RFC7129]. The following table summarizes their 1149 comparison in terms of response size, performance at the 1150 authoritative server, and performance at the resolver. For NSEC3 1151 White Lies, RSASHA256 (2048-bit) and ECDSAPSHA256 were considered, 1152 and for NSEC5, RSAFDH-SHA256-SHA256 (2048-bit) and EC-P256-SHA256 1153 were considered. 1155 +---------------+-----------------+------------------+--------------+ 1156 | Algorithm | Response length | Authoritative | Resolver | 1157 | | (octets) | (ops/sec) | (ops/sec) | 1158 +---------------+-----------------+------------------+--------------+ 1159 | NSEC3WL/RSA | 1440 | 1500 | 47000 | 1160 | NSEC3WL/ECDSA | 752 | 7400 | 4000 | 1161 | NSEC5/RSA | 1767 | 1500 | 46000 | 1162 | NSEC5/EC | 839 | 4700 | 4000 | 1163 +---------------+-----------------+------------------+--------------+ 1165 NSEC5 responses lengths are only slighly longer than NSEC3 response 1166 lengths: NSEC5/RSA has responses that are about 22% longer than 1167 NSEC3/RSA, while NSEC5/EC has responses that are about 13% longer 1168 than NSEC3/ECDSA. For both NSEC3 and NSEC5, it is clear that EC- 1169 based solutions give much shorter responses. 1171 Regarding the computation performance, with RSA the difference is 1172 negligible for both nameserver and resolver, whereas with the EC- 1173 based schemes there is no slowdown for the resolver, and a slowdown 1174 of 1.5x for the server. Importantly, we expect the slowdown to be 1175 smaller in practice because NSEC3 entails three signing/verifying 1176 computations per query in the worst case (closest encloser, next 1177 closer, wildcard at closest encloser) whereas NSEC5 requires only 1178 two. The table above does not capture this issue, it just measures 1179 number of signing/verifying operations per second. Future versions 1180 of this draft will more accurately measure and compare NSEC5 1181 performance. 1183 Note also that while NSEC3 White Lies outperforms NSEC5 for certain 1184 cases, NSEC3 White Lies require authoratitive nameserver to store the 1185 private zone-signing key, making each nameserver a potential point of 1186 compromise. 1188 14. Security Considerations 1190 14.1. Zone Enumeration Attacks 1192 NSEC5 is robust to zone enumeration via offline dictionary attacks by 1193 any attacker that does not know the NSEC5 private key. Without the 1194 private NSEC5 key, that attacker cannot compute the NSEC5 proof that 1195 corresponds to a given name; the only way it can learn the NSEC5 1196 proof value for a given name is by sending a queries for that name to 1197 the authoritative server. Without the NSEC5 proof value, the 1198 attacker cannot learn the NSEC5 hash value. Thus, even an attacker 1199 that collects the entire chain of NSEC5 RR for a zone cannot use 1200 offline attacks to "reverse" that NSEC5 hash values in these NSEC5 RR 1201 and thus learn which names are present in the zone. A formal 1202 cryptographic proof of this property is in [nsec5]. 1204 14.2. Hash Collisions 1206 Hash collisions between QNAME and the owner name of an NSEC5 RR may 1207 occur. When they do, it will be impossible to prove the non- 1208 existence of the colliding QNAME. However, with SHA-256, this is 1209 highly unlikely (on the order of 1 in 2^128). Note that DNSSEC 1210 already relies on the presumption that a cryptographic hash function 1211 is collision resistant, since these hash functions are used for 1212 generating and validating signatures and DS RRs. See also the 1213 discussion on key lengths in [nsec5]. 1215 14.3. Compromise of the Private NSEC5 Key 1217 NSEC5 requires authoritative servers to hold the private NSEC5 key, 1218 but not the private zone-signing keys or the private key-signing keys 1219 for the zone. 1221 The private NSEC5 key needs only be as secure as the DNSSEC records 1222 whose the privacy (against zone-enumeration attacks) that NSEC5 is 1223 protecting. This is because even an adversary that knows the private 1224 NSEC5 key cannot modify the contents of the zone; this is because the 1225 zone contents are signed using the private zone-signing key, while 1226 the private NSEC5 key is only used to compute NSEC5 proof values. 1227 Thus, a compromise of the private NSEC5 keys does not lead to a 1228 compromise of the integrity of the DNSSEC record in the zone; 1229 instead, all that is lost is privacy against zone enumeration, if the 1230 attacker that knows the private NSEC5 key can compute NSEC5 hashes 1231 offline, and thus launch offline dictionary attacks. Thus, a 1232 compromise of the private NSEC5 key effectively downgrades the 1233 security of NSEC5 to that of NSEC3. A formal cryptographic proof of 1234 this property is in [nsec5]. 1236 If a zone owner wants to preserve this property of NSEC5, the zone 1237 owner SHOULD choose the NSEC5 private key to be different from the 1238 private zone-signing keys or key-signing keys for the zone. 1240 14.4. Key Length Considerations 1242 The NSEC5 key must be long enough to withstand attacks for as long as 1243 the privacy of the zone is important. Even if the NSEC5 key is 1244 rolled frequently, its length cannot be too short, because zone 1245 privacy may be important for a period of time longer than the 1246 lifetime of the key. (For example, an attacker might collect the 1247 entire chain of NSEC5 RR for the zone over one short period, and 1248 then, later (even after the NSEC5 key expires) perform an offline 1249 dictionary attack that attempt to "reverse" the NSEC5 hash values 1250 present in the NSEC5 RRs.) This is in contrast to zone-signing and 1251 key-signing keys used in DNSSEC; these keys, which ensure the 1252 authenticity and integrity of the zone contents need to remain secure 1253 only during their lifetime. 1255 14.5. Transitioning to a New NSEC5 Algorithm 1257 Although the NSEC5KEY RR formats include a hash algorithm parameter, 1258 this document does not define a particular mechanism for safely 1259 transitioning from one NSEC5 algorithm to another. When specifying a 1260 new hash algorithm for use with NSEC5, a transition mechanism MUST 1261 also be defined. It is possible that the only practical and 1262 palatable transition mechanisms may require an intermediate 1263 transition to an insecure state, or to a state that uses NSEC or 1264 NSEC3 records instead of NSEC5. 1266 15. IANA Considerations 1268 This document updates the IANA registry "Domain Name System (DNS) 1269 Parameters" in subregistry "Resource Record (RR) TYPEs", by defining 1270 the following new RR types: 1272 NSEC5KEY value XXX. 1274 NSEC5 value XXX. 1276 NSEC5PROOF value XXX. 1278 This document creates a new IANA registry for NSEC5 algorithms. This 1279 registry is named "DNSSEC NSEC5 Algorithms". The initial content of 1280 the registry is: 1282 0 is Reserved. 1284 1 is RSAFDH-SHA256-SHA256. 1286 2 is EC-P256-SHA256. 1288 3 is EC-ED25519-SHA256. 1290 4-255 is Available for assignment. 1292 This document updates the IANA registry "DNS Security Algorithm 1293 Numbers" by defining following aliases: 1295 XXX is NSEC5-RSASHA256, alias for RSASHA256 (8). 1297 XXX is NSEC5-RSASHA512, alias for RSASHA512 (10). 1299 XXX is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13). 1301 XXX is NSEC5-ECDSAP384SHA384 alias for ECDSAP384SHA384 (14). 1303 16. Contributors 1305 This document would not be possible without help of Moni Naor 1306 (Weizmann Institute), Sachin Vasant (Cisco Systems), Leonid Reyzin 1307 (Boston University), and Asaf Ziv (Weizmann Institute) who 1308 contributed to the design of NSEC5, and Ondrej Sury (CZ.NIC Labs) who 1309 provided advice on its implementation. 1311 17. References 1313 17.1. Normative References 1315 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1316 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1317 . 1319 [RFC1035] Mockapetris, P., "Domain names - implementation and 1320 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1321 November 1987, . 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, 1325 DOI 10.17487/RFC2119, March 1997, 1326 . 1328 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1329 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1330 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1331 . 1333 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1334 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1335 . 1337 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1338 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1339 . 1341 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the 1342 Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, 1343 May 2001, . 1345 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1346 Standards (PKCS) #1: RSA Cryptography Specifications 1347 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 1348 2003, . 1350 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1351 Rose, "DNS Security Introduction and Requirements", 1352 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1353 . 1355 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1356 Rose, "Resource Records for the DNS Security Extensions", 1357 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1358 . 1360 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1361 Rose, "Protocol Modifications for the DNS Security 1362 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1363 . 1365 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1366 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1367 . 1369 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 1370 Groups for Use with IETF Standards", RFC 5114, 1371 DOI 10.17487/RFC5114, January 2008, 1372 . 1374 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1375 Security (DNSSEC) Hashed Authenticated Denial of 1376 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1377 . 1379 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1380 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1381 DOI 10.17487/RFC6234, May 2011, 1382 . 1384 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 1385 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 1386 DOI 10.17487/RFC6605, April 2012, 1387 . 1389 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1390 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1391 2016, . 1393 [I-D.ietf-curdle-dnskey-ed25519] 1394 Sury, O. and R. Edmonds, "Ed25519 for DNSSEC", draft-ietf- 1395 curdle-dnskey-ed25519-01 (work in progress), February 1396 2016. 1398 [FIPS-186-3] 1399 National Institute for Standards and Technology, "Digital 1400 Signature Standard (DSS)", FIPS PUB 186-3, June 2009. 1402 [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: 1403 Elliptic Curve Cryptography", Version 2.0, May 2009, 1404 . 1406 17.2. Informative References 1408 [nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., 1409 Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC 1410 Zone Enumeration", in NDSS'15, July 2014. 1412 [nsec5ecc] 1413 Goldberg, S., Naor, M., Papadopoulos, D., and L. Reyzin, 1414 "NSEC5 from Elliptic Curves", in ePrint Cryptology Archive 1415 2016/083, January 2016. 1417 [nsec3gpu] 1418 Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, 1419 "GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network 1420 Computing and Applications (NCA), 2014. 1422 [nsec3walker] 1423 Bernstein, D., "Nsec3 walker", 2011, 1424 . 1426 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1427 Operational Practices, Version 2", RFC 6781, 1428 DOI 10.17487/RFC6781, December 2012, 1429 . 1431 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1432 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 1433 February 2014, . 1435 Appendix A. RSA Full Domain Hash Algorithm 1437 The Full Domain Hash (FDH) is a RSA-based scheme that allows 1438 authentication of hashes using public-key cryptography. 1440 In this document, the notation from [RFC3447] is used. 1442 Used parameters: 1444 (n, e) - RSA public key 1446 K - RSA private key 1448 k - length of the RSA modulus n in octets 1450 Fixed options: 1452 Hash - hash function to be used with MGF1 1454 Used primitives: 1456 I2OSP - Coversion of a nonnegative integer to an octet string as 1457 defined in Section 4.1 of [RFC3447] 1459 OS2IP - Coversion of an octet string to a nonnegative integer as 1460 defined in Section 4.2 of [RFC3447] 1462 RSASP1 - RSA signature primitive as defined in Section 5.2.1 of 1463 [RFC3447] 1465 RSAVP1 - RSA verification primitive as defined in Section 5.2.2 of 1466 [RFC3447] 1468 MGF1 - Mask Generation Function based on a hash function as 1469 defined in Section B.2.1 of [RFC3447] 1471 A.1. FDH signature 1473 FDH_SIGN(K, M) 1475 Input: 1477 K - RSA private key 1479 M - message to be signed, an octet string 1481 Output: 1483 S - signature, an octet string of length k 1485 Steps: 1487 1. EM = MGF1(M, k - 1) 1489 2. m = OS2IP(EM) 1491 3. s = RSASP1(K, m) 1493 4. S = I2OSP(s, k) 1495 5. Output S 1497 A.2. FDH verification 1499 FDH_VERIFY((n, e), M, S) 1501 Input: 1503 (n, e) - RSA public key 1505 M - message whose signature is to be verified, an octet string 1507 S - signature to be verified, an octet string of length k 1509 Output: 1511 "valid signature" or "invalid signature" 1513 Steps: 1515 1. s = OS2IP(S) 1517 2. m = RSAVP1((n, e), s) 1519 3. EM = I2OSP(m, k - 1) 1521 4. EM' = MGF1(M, k - 1) 1523 5. If EM and EM' are the same, output "valid signature"; else output 1524 "invalid signature". 1526 Appendix B. Elliptic Curve VRF 1528 The Elliptic Curve Verifiable Random Function (VRF) is a EC-based 1529 scheme that allows authentication of hashes using public-key 1530 cryptography. 1532 Fixed options: 1534 G - EC group 1536 Used parameters: 1538 g^x - EC public key 1540 x - EC private key 1542 q - primer order of group G 1544 g - generator of group G 1546 Used primitives: 1548 "" - empty octet string 1550 || - octet string concatenation 1552 p^k - EC point multiplication 1554 p1*p2 - EC point addition 1556 SHA256 - hash function SHA-256 as specified in [RFC6234] 1558 ECP2OS - EC point to octet string conversion with point 1559 compression as specified in Section 2.3.3 of [SECG1] 1561 OS2ECP - octet string to EC point conversion with point 1562 compression as specified in Section 2.3.4 of [SECG1] 1564 B.1. ECVRF Hash To Curve 1566 ECVRF_hash_to_curve(m) 1568 Input: 1570 m - value to be hashed, an octet string 1572 Output: 1574 h - hashed value, EC point 1576 Steps: 1578 1. c = 0 1579 2. C = I2OSP(c, 4) 1581 3. xc = SHA256(m || C) 1583 4. p = 0x02 || xc 1585 5. If p is not a valid octet string representing encoded compressed 1586 point in G: 1588 A. c = c + 1 1590 B. Go to step 2. 1592 6. h = OS2ECP(p) 1594 7. Output h 1596 B.2. ECVRF Auxiliary Functions 1598 B.2.1. ECVRF Hash Points 1600 ECVRF_hash_points(p_1, p_2, ..., p_n) 1602 Input: 1604 p_x - EC point in G 1606 Output: 1608 h - hash value, integer between 0 and 2^128-1 1610 Steps: 1612 1. P = "" 1614 2. for p in [p_1, p_2, ... p_n]: 1615 P = P || ECP2OS(p) 1617 3. h' = SHA256(P) 1619 4. h = OS2IP(first 16 octets of h') 1621 5. Output h 1623 B.2.2. ECVRF Proof To Hash 1625 ECVRF_proof_to_hash(gamma) 1627 Input: 1629 gamma - VRF proof, EC point in G with coordinates (x, y) 1631 Output: 1633 beta - VRF hash, octet string (32 octets) 1635 Steps: 1637 1. beta = I2OSP(x, 32) 1639 2. Output beta 1641 Note: Because of the format of compressed form of an elliptic curve, 1642 the hash can be retrieved from an encoded gamma simply by omitting 1643 the first octet of the gamma. 1645 B.2.3. ECVRF Decode Proof 1647 ECVRF_decode_proof(pi) 1649 Input: 1651 pi - VRF proof, octet string (81 octets) 1653 Output: 1655 gamma - EC point 1657 c - integer between 0 and 2^128-1 1659 s - integer between 0 and 2^256-1 1661 Steps: 1663 1. let gamma', c', s' be pi split after 33-rd and 49-th octet 1665 2. gamma = OS2ECP(gamma') 1667 3. c = OS2IP(c') 1669 4. s = OS2IP(s') 1670 5. Output gamma, c, and s 1672 B.3. ECVRF Signing 1674 ECVRF_sign(g^x, x, alpha) 1676 Input: 1678 g^x - EC public key 1680 x - EC private key 1682 alpha - message to be signed, octet string 1684 Output: 1686 pi - VRF proof, octet string (81 octets) 1688 beta - VRF hash, octet string (32 octets) 1690 Steps: 1692 1. h = ECVRF_hash_to_curve(alpha) 1694 2. gamma = h^x 1696 3. choose a nonce k from [0, q-1] 1698 4. c = ECVRF_hash_points(g, h, g^x, h^x, g^k, h^k) 1700 5. s = k - c*q mod q 1702 6. pi = ECP2OS(gamma) || I2OSP(c, 16) || I2OSP(s, 32) 1704 7. beta = h2(gamma) 1706 8. Output pi and beta 1708 B.4. ECVRF Verification 1710 ECVRF_VERIFY(g^x, pi, alpha) 1712 Input: 1714 g^x - EC public key 1716 pi - VRF proof, octet string 1717 alpha - message to verify, octet string 1719 Output: 1721 "valid signature" or "invalid signature" 1723 beta - VRF hash, octet string (32 octets) 1725 Steps: 1727 1. gamma, c, s = ECVRF_decode_proof(pi) 1729 2. u = (g^x)^c * g^s 1731 3. h = ECVRF_hash_to_curve(alpha) 1733 4. v = gamma^c * h^s 1735 5. c' = ECVRF_hash_points(g, h, g^x, gamma, u, v) 1737 6. beta = ECVRF_proof_to_hash(gamma) 1739 7. If c and c' are the same, output "valid signature"; else output 1740 "invalid signature". Output beta. 1742 [[CREF1: TODO: check validity of gamma before hashing --Jan]] 1744 Appendix C. Change Log 1746 Note to RFC Editor: if this document does not obsolete an existing 1747 RFC, please remove this appendix before publication as an RFC. 1749 pre 00 - initial version of the document submitted to mailing list 1750 only 1752 00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA, 1753 clarify inputs and outputs for NSEC5 proof and NSEC5 hash 1754 computation 1756 01 - added Performance Considerations section 1758 02 - Elliptic Curve based VRF for NSEC5 proofs; response sizes 1759 based on empirical data 1761 03 - Precomputed NSEC5PROOF Values (section Section 13.4) 1763 Appendix D. Open Issues 1765 Note to RFC Editor: please remove this appendix before publication as 1766 an RFC. 1768 1. Consider alternative way to signalize NSEC5 support. The NSEC5 1769 could use only one DNSSEC algorithm identifier, and the actual 1770 algorithm to be used for signing can be the first octet in DNSKEY 1771 public key field and RRSIG signature field. Similar approach is 1772 used by PRIVATEDNS and PRIVATEOID defined in [RFC4034]. 1774 2. How to add new NSEC5 hashing algorithm. We will need to add new 1775 DNSSEC algorithm identifiers again. 1777 3. NSEC and NSEC3 define optional steps for hash collisions 1778 detection. We don't have a way to avoid them if they really 1779 appear (unlikely). We would have to drop the signing key and 1780 generate a new one. Which cannot be done instantly. 1782 4. Write Special Considerations section. 1784 5. Contributor list has to be completed. 1786 Authors' Addresses 1788 Jan Vcelak 1789 CZ.NIC 1790 Milesovska 1136/5 1791 Praha 130 00 1792 CZ 1794 EMail: jan.vcelak@nic.cz 1796 Sharon Goldberg 1797 Boston University 1798 111 Cummington St, MCS135 1799 Boston, MA 02215 1800 USA 1802 EMail: goldbe@cs.bu.edu 1803 Dimitrios Papadopoulos 1804 Boston University 1805 111 Cummington St, MCS135 1806 Boston, MA 02215 1807 USA 1809 EMail: dipapado@bu.edu