idnits 2.17.1 draft-vcelak-nsec5-07.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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 34 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'FIPS-186-3' is defined on line 1086, but no explicit reference was found in the text == Unused Reference: 'RFC5114' is defined on line 1140, but no explicit reference was found in the text == Unused Reference: 'RFC6234' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'RFC7748' is defined on line 1160, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' == Outdated reference: A later version (-15) exists of draft-irtf-cfrg-vrf-01 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-vrf (ref. 'I-D.irtf-cfrg-vrf') ** 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 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: December 30, 2018 Boston University 6 D. Papadopoulos 7 HKUST 8 S. Huque 9 Salesforce 10 D. Lawrence 11 Akamai Technologies 12 June 28, 2018 14 NSEC5, DNSSEC Authenticated Denial of Existence 15 draft-vcelak-nsec5-07 17 Abstract 19 The Domain Name System Security Extensions (DNSSEC) introduced two 20 resource records (RR) for authenticated denial of existence: the NSEC 21 RR and the NSEC3 RR. This document introduces NSEC5 as an 22 alternative mechanism for DNSSEC authenticated denial of existence. 23 NSEC5 uses verifiable random functions (VRFs) to prevent offline 24 enumeration of zone contents. NSEC5 also protects the integrity of 25 the zone contents even if an adversary compromises one of the 26 authoritative servers for the zone. Integrity is preserved because 27 NSEC5 does not require private zone-signing keys to be present on all 28 authoritative servers for the zone, in contrast to DNSSEC online 29 signing schemes like NSEC3 White Lies. 31 Ed note 33 Text inside square brackets ([]) is additional background 34 information, answers to frequently asked questions, general musings, 35 etc. They will be removed before publication. This document is 36 being collaborated on in GitHub at . The most recent version of the document, open issues, 38 etc should all be available there. The authors gratefully accept 39 pull requests. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on December 30, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 6 78 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 79 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 80 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 7 81 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 8 82 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 9 83 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 9 84 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 9 85 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 9 86 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 10 87 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 10 88 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 11 89 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 11 90 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 11 91 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 12 92 8. Types of Authenticated Denial of Existence with NSEC5 . . . . 12 93 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 12 94 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 13 95 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 13 96 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 14 97 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 14 98 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 14 99 9. Authoritative Server Considerations . . . . . . . . . . . . . 15 100 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 15 101 9.1.1. Precomputing Closest Provable Encloser Proofs . . . . 16 102 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 17 103 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 18 104 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 18 105 9.5. Zones Using Unknown NSEC5 Algorithms . . . . . . . . . . 18 106 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 18 107 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 19 108 11. Validator Considerations . . . . . . . . . . . . . . . . . . 19 109 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 19 110 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 20 111 11.3. Responses With Unknown NSEC5 Algorithms . . . . . . . . 20 112 12. Special Considerations . . . . . . . . . . . . . . . . . . . 20 113 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 20 114 12.2. Private NSEC5 keys . . . . . . . . . . . . . . . . . . . 20 115 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 21 116 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 117 14. Performance Considerations . . . . . . . . . . . . . . . . . 21 118 15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 119 15.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 21 120 15.2. Compromise of the Private NSEC5 Key . . . . . . . . . . 22 121 15.3. Key Length Considerations . . . . . . . . . . . . . . . 22 122 15.4. NSEC5 Hash Collisions . . . . . . . . . . . . . . . . . 22 123 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 124 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 125 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 126 18.1. Normative References . . . . . . . . . . . . . . . . . . 24 127 18.2. Informative References . . . . . . . . . . . . . . . . . 25 128 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 27 129 A.1. Name Error Example . . . . . . . . . . . . . . . . . . . 27 130 A.2. No Data Example . . . . . . . . . . . . . . . . . . . . . 29 131 A.3. Delegation to an Unsigned Zone in an Opt-Out span Example 30 132 A.4. Wildcard Example . . . . . . . . . . . . . . . . . . . . 31 133 A.5. Wildcard No Data Example . . . . . . . . . . . . . . . . 32 134 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 137 1. Introduction 139 1.1. Rationale 141 NSEC5 provides an alternative mechanism for authenticated denial of 142 existence for the DNS Security Extensions (DNSSEC). NSEC5 has two 143 key security properties. First, NSEC5 protects the integrity of the 144 zone contents even if an adversary compromises one of the 145 authoritative servers for the zone. Second, NSEC5 prevents offline 146 zone enumeration, where an adversary makes a small number of online 147 DNS queries and then processes them offline in order to learn all of 148 the names in a zone. Zone enumeration can be used to identify 149 routers, servers or other "things" that could then be targeted in 150 more complex attacks. An enumerated zone can also be a source of 151 probable email addresses for spam, or as a "key for multiple WHOIS 152 queries to reveal registrant data that many registries may have legal 153 obligations to protect" [RFC5155]. 155 All other DNSSEC mechanisms for authenticated denial of existence 156 either fail to preserve integrity against a compromised server, or 157 fail to prevent offline zone enumeration. 159 When offline signing with NSEC is used [RFC4034], an NSEC chain of 160 all existing domain names in the zone is constructed and signed 161 offline. The chain is made of resource records (RRs), where each RR 162 represents two consecutive domain names in canonical order present in 163 the zone. The authoritative server proves the non-existence of a 164 name by presenting a signed NSEC RR which covers the name. Because 165 the authoritative server does not need not to know the private zone- 166 signing key, the integrity of the zone is protected even if the 167 server is compromised. However, the NSEC chain allows for easy zone 168 enumeration: N queries to the server suffice to learn all N names in 169 the zone (see e.g., [nmap-nsec-enum], [nsec3map], and [ldns-walk]). 171 When offline signing with NSEC3 is used [RFC5155], the original names 172 in the NSEC chain are replaced by their cryptographic hashes. 173 Offline signing ensures that NSEC3 preserves integrity even if an 174 authoritative server is compromised. However, offline zone 175 enumeration is still possible with NSEC3 (see e.g., [nsec3walker], 176 [nsec3gpu]), and is part of standard network reconnaissance tools 177 (e.g., [nmap-nsec3-enum], [nsec3map]). 179 When online signing is used, the authoritative server holds the 180 private zone-signing key and uses this key to synthesize NSEC or 181 NSEC3 responses on the fly (e.g. NSEC3 White Lies (NSEC3-WL) or 182 Minimally-Covering NSEC, both described in [RFC7129]). Because the 183 synthesized response only contains information about the queried name 184 (but not about any other name in the zone), offline zone enumeration 185 is not possible. However, because the authoritative server holds the 186 private zone-signing key, integrity is lost if the authoritative 187 server is compromised. 189 +----------+-------------+---------------+----------------+---------+ 190 | Scheme | Integrity | Integrity vs | Prevents | Online | 191 | | vs network | compromised | offline zone | crypto? | 192 | | attacks? | auth. server? | enumeration? | | 193 +----------+-------------+---------------+----------------+---------+ 194 | Unsigned | NO | NO | YES | NO | 195 | NSEC | YES | YES | NO | NO | 196 | NSEC3 | YES | YES | NO | NO | 197 | NSEC3-WL | YES | NO | YES | YES | 198 | NSEC5 | YES | YES | YES | YES | 199 +----------+-------------+---------------+----------------+---------+ 201 NSEC5 prevents offline zone enumeration and also protects integrity 202 even if a zone's authoritative server is compromised. To do this, 203 NSEC5 replaces the unkeyed cryptographic hash function used in NSEC3 204 with a verifiable random function (VRF) [I-D.irtf-cfrg-vrf] [MRV99]. 205 A VRF is the public-key version of a keyed cryptographic hash. Only 206 the holder of the private VRF key can compute the hash, but anyone 207 with public VRF key can verify the correctness of the hash. 209 The public VRF key is distributed in an NSEC5KEY RR, similar to a 210 DNSKEY RR, and is used to verify NSEC5 hash values. The private VRF 211 key is present on all authoritative servers for the zone, and is used 212 to compute hash values. For every query that elicits a negative 213 response, the authoritative server hashes the query on the fly using 214 the private VRF key, and also returns the corresponding precomputed 215 NSEC5 record(s). In contrast to the online signing approach 216 [RFC7129], the private key that is present on all authoritative 217 servers for NSEC5 cannot be used to modify the zone contents. 219 Like online signing approaches, NSEC5 requires the authoritative 220 server to perform online public key cryptographic operations for 221 every query eliciting a denying response. This is necessary; [nsec5] 222 proved that online cryptography is required to prevent offline zone 223 enumeration while still protecting the integrity of zone contents 224 against network attacks. 226 NSEC5 is not intended to replace NSEC or NSEC3. It is an alternative 227 mechanism for authenticated denial of existence. This document 228 specifies NSEC5 based on the VRFs in [I-D.irtf-cfrg-vrf] over the 229 FIPS 186-3 P-256 elliptic curve and over the the Ed25519 elliptic 230 curve. A formal cryptographic proof of security for NSEC5 is in 231 [nsec5ecc]. 233 1.2. Requirements 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in [RFC2119]. 239 1.3. Terminology 241 The reader is assumed to be familiar with the basic DNS and DNSSEC 242 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and 243 [RFC4035]; subsequent RFCs that update them in [RFC2136], [RFC2181], 244 [RFC2308], [RFC5155], and [RFC7129]; and DNS terms in [RFC7719]. 246 The reader should also be familiar with verifiable random functions 247 (VRFs) as defined in [I-D.irtf-cfrg-vrf]. 249 The following terminology is used through this document: 251 Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as 252 specified in [RFC4648]. The padding characters ("=") are not used 253 in the NSEC5 specification. 255 Base64: The "Base 64 Encoding" as specified in [RFC4648]. 257 QNAME: The domain name being queried (query name). 259 Private NSEC5 key: The private key for the verifiable random 260 function (VRF). 262 Public NSEC5 key: The public key for the VRF. 264 NSEC5 proof: A VRF proof. The holder of the private NSEC5 key 265 (e.g., authoritative server) can compute the NSEC5 proof for an 266 input domain name. Anyone who knows the public VRF key can verify 267 that the NSEC5 proof corresponds to the input domain name. 269 NSEC5 hash: A cryptographic digest of an NSEC5 proof. If the NSEC5 270 proof is known, anyone can compute its corresponding NSEC5 hash. 272 NSEC5 algorithm: A triple of VRF algorithms that compute an NSEC5 273 proof (VRF_prove), verify an NSEC5 proof (VRF_verify), and process 274 an NSEC5 proof to obtain its NSEC5 hash (VRF_proof2hash). 276 2. Backward Compatibility 278 The specification describes a protocol change that is not backward 279 compatible with [RFC4035] and [RFC5155]. An NSEC5-unaware resolver 280 will fail to validate responses introduced by this document. 282 To prevent NSEC5-unaware resolvers from attempting to validate the 283 responses, new DNSSEC algorithms identifiers are introduced in 284 Section 16 which alias existing algorithm numbers. The zones signed 285 according to this specification MUST use only these algorithm 286 identifiers, thus NSEC5-unaware resolvers will treat the zone as 287 insecure. 289 3. How NSEC5 Works 291 With NSEC5, the original domain name is hashed using a VRF 292 [I-D.irtf-cfrg-vrf] using the following steps: 294 1. The domain name is processed using a VRF keyed with the private 295 NSEC5 key to obtain the NSEC5 proof. Anyone who knows the public 296 NSEC5 key, normally acquired via an NSEC5KEY RR, can verify that 297 a given NSEC5 proof corresponds to a given domain name. 299 2. The NSEC5 proof is then processed using a publicly-computable VRF 300 proof2hash function to obtain the NSEC5 hash. The NSEC5 hash can 301 be computed by anyone who knows the input NSEC5 proof. 303 The NSEC5 hash determines the position of a domain name in an NSEC5 304 chain. 306 To sign a zone, the private NSEC5 key is used to compute the NSEC5 307 hashes for each name in the zone. These NSEC5 hashes are sorted in 308 canonical order [RFC4034], and each consecutive pair forms an NSEC5 309 RR. Each NSEC5 RR is signed offline using the private zone-signing 310 key. The resulting signed chain of NSEC5 RRs is provided to all 311 authoritative servers for the zone, along with the private NSEC5 key. 313 To prove non-existence of a particular domain name in response to a 314 query, the server uses the private NSEC5 key to compute the NSEC5 315 proof and NSEC5 hash corresponding to the queried name. The server 316 then identifies the NSEC5 RR that covers the NSEC5 hash, and responds 317 with this NSEC5 RR and its corresponding RRSIG signature RRset, as 318 well as a synthesized NSEC5PROOF RR that contains the NSEC5 proof 319 corresponding to the queried name. 321 To validate the response, the client verifies the following items: 323 o The client uses the public NSEC5 key, normally acquired from the 324 NSEC5KEY RR, to verify that the NSEC5 proof in the NSEC5PROOF RR 325 corresponds to the queried name. 327 o The client uses the VRF proof2hash function to compute the NSEC5 328 hash from the NSEC5 proof in the NSEC5PROOF RR. The client 329 verifies that the NSEC5 hash is covered by the NSEC5 RR. 331 o The client verifies that the NSEC5 RR is validly signed by the 332 RRSIG RRset. 334 4. NSEC5 Algorithms 336 The algorithms used for NSEC5 authenticated denial are independent of 337 the algorithms used for DNSSEC signing. An NSEC5 algorithm defines 338 how the NSEC5 proof and the NSEC5 hash are computed and validated. 340 The NSEC5 proof corresponding to a name is computed using 341 ECVRF_prove(), as specified in [I-D.irtf-cfrg-vrf]. The input to 342 ECVRF_prove() is a public NSEC5 key followed by a private NSEC5 key 343 followed by an RR owner name in [RFC4034] canonical wire format. The 344 output NSEC5 proof is an octet string. 346 An NSEC5 hash corresponding to a name is computed from its NSEC5 347 proof using ECVRF_proof2hash(), as specified in [I-D.irtf-cfrg-vrf]. 348 The input to VRF_proof2hash() is an NSEC5 proof as an octet string. 349 The output NSEC5 hash is either an octet string, or INVALID. 351 An NSEC5 proof for a name is verified using ECVRF_verify(), as 352 specified in [I-D.irtf-cfrg-vrf]. The input is the NSEC5 public key, 353 followed by an NSEC5 proof as an octet string, followed by an RR 354 owner name in [RFC4034] canonical wire format. The output is either 355 VALID or INVALID. 357 This document defines the EC-P256-SHA256 NSEC5 algorithm as follows: 359 o The VRF is the ECVRF algorithm using the ECVRF-P256-SHA256 360 ciphersuite specified in [I-D.irtf-cfrg-vrf]. 362 o The public key format to be used in the NSEC5KEY RR is defined in 363 Section 4 of [RFC6605] and thus is the same as the format used to 364 store ECDSA public keys in DNSKEY RRs. 365 [NOTE: This specification does not compress the elliptic curve 366 point used for the public key, but we do compress curve points in 367 every other place we use them. The NSEC5KEY record can be shrunk 368 by 31 additional octets by encoding the public key with point 369 compression.] 371 This document defines the EC-ED25519-SHA512 NSEC5 algorithm as 372 follows: 374 o The VRF is the EC-VRF algorithm using the ECVRF-ED25519-SHA512 375 ciphersuite specified in [I-D.irtf-cfrg-vrf]. 377 o The public key format to be used in the NSEC5KEY RR is defined in 378 Section 3 of [RFC8080] and thus is the same as the format used to 379 store Ed25519 public keys in DNSKEY RRs. 381 [NOTE: Could alternatively have the EC-ED25519-SHA512 NSEC5 382 ciphersuite use the EC-VRF-ED25519-SHA512-ELLIGATOR2 ciphersuite 383 specified in [I-D.irtf-cfrg-vrf].] 385 5. The NSEC5KEY Resource Record 387 The NSEC5KEY RR stores a public NSEC5 key. The key allows clients to 388 validate an NSEC5 proof sent by a server. 390 5.1. NSEC5KEY RDATA Wire Format 392 The RDATA for the NSEC5KEY RR is as shown below: 394 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 395 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 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Algorithm | Public Key / 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Algorithm is a single octet identifying the NSEC5 algorithm. 402 Public Key is a variable-sized field holding public key material for 403 NSEC5 proof verification. 405 5.2. NSEC5KEY RDATA Presentation Format 407 The presentation format of the NSEC5KEY RDATA is as follows: 409 The Algorithm field is represented as an unsigned decimal integer. 411 The Public Key field is represented in Base64 encoding. Whitespace 412 is allowed within the Base64 text. 414 6. The NSEC5 Resource Record 416 The NSEC5 RR provides authenticated denial of existence for an RRset 417 or domain name. One NSEC5 RR represents one piece of an NSEC5 chain, 418 proving existence of the owner name and non-existence of other domain 419 names in the part of the hashed domain space that is covered until 420 the next owner name hashed in the RDATA. 422 6.1. NSEC5 RDATA Wire Format 424 The RDATA for the NSEC5 RR is as shown below: 426 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Key Tag | Flags | Next Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Next Hashed Owner Name / 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 / Type Bit Maps / 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 The Key Tag field contains the key tag value of the NSEC5KEY RR that 437 validates the NSEC5 RR, in network byte order. The value is computed 438 from the NSEC5KEY RDATA using the same algorithm used to compute key 439 tag values for DNSKEY RRs. This algorithm is defined in [RFC4034]. 441 The Flags field is a single octet. The meaning of individual bits of 442 the field is defined in Section 6.2. 444 The Next Length field is an unsigned single octet specifying the 445 length of the Next Hashed Owner Name field in octets. 447 The Next Hashed Owner Name field is a sequence of binary octets. It 448 contains an NSEC5 hash of the next domain name in the NSEC5 chain. 450 Type Bit Maps is a variable-sized field encoding RR types present at 451 the original owner name matching the NSEC5 RR. The format of the 452 field is equivalent to the format used in the NSEC3 RR, described in 453 [RFC5155]. 455 6.2. NSEC5 Flags Field 457 The following one-bit NSEC5 flags are defined: 459 0 1 2 3 4 5 6 7 460 +-+-+-+-+-+-+-+-+ 461 | |W|O| 462 +-+-+-+-+-+-+-+-+ 464 O - Opt-Out flag 466 W - Wildcard flag 468 All the other flags are reserved for future use and MUST be zero. 470 The Opt-Out flag has the same semantics as in NSEC3. The definition 471 and considerations in [RFC5155] are valid, except that NSEC3 is 472 replaced by NSEC5. 474 The Wildcard flag indicates that a wildcard synthesis is possible at 475 the original domain name level (i.e., there is a wildcard node 476 immediately descending from the immediate ancestor of the original 477 domain name). The purpose of the Wildcard flag is to reduce the 478 maximum number of RRs required for an authenticated denial of 479 existence proof from (at most) three to (at most) two, as originally 480 described in [I-D.gieben-nsec4] Section 7.2.1. 482 6.3. NSEC5 RDATA Presentation Format 484 The presentation format of the NSEC5 RDATA is as follows: 486 The Key Tag field is represented as an unsigned decimal integer. 488 The Flags field is represented as an unsigned decimal integer. 490 The Next Length field is not represented. 492 The Next Hashed Owner Name field is represented as a sequence of 493 case-insensitive Base32hex digits without any whitespace and without 494 padding. 496 The Type Bit Maps representation is equivalent to the representation 497 used in NSEC3 RR, described in [RFC5155]. 499 7. The NSEC5PROOF Resource Record 501 The NSEC5PROOF record is not to be included in the zone file. The 502 NSEC5PROOF record contains the NSEC5 proof, proving the position of 503 the owner name in an NSEC5 chain. 505 7.1. NSEC5PROOF RDATA Wire Format 507 The RDATA for the NSEC5PROOF RR is shown below: 509 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Key Tag | Owner Name Hash / 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Key Tag field contains the key tag value of the NSEC5KEY RR that 516 validates the NSEC5PROOF RR, in network byte order. 518 Owner Name Hash is a variable-sized sequence of binary octets 519 encoding the NSEC5 proof of the owner name of the RR. 521 7.2. NSEC5PROOF RDATA Presentation Format 523 The presentation format of the NSEC5PROOF RDATA is as follows: 525 The Key Tag field is represented as an unsigned decimal integer. 527 The Owner Name Hash is represented in Base64 encoding. Whitespace is 528 allowed within the Base64 text. 530 8. Types of Authenticated Denial of Existence with NSEC5 532 This section summarizes all possible types of authenticated denial of 533 existence. For each type the following lists are included: 535 1. Facts to prove: the minimum amount of information that an 536 authoritative server must provide to a client to assure the 537 client that the response content is valid. 539 2. Authoritative server proofs: the names for which the NSEC5PROOF 540 RRs are synthesized and added into the response along with the 541 NSEC5 RRs matching or covering each such name. These records 542 together prove the listed facts. 544 3. Validator checks: the individual checks that a validating server 545 is required to perform on a response. The response content is 546 considered valid only if all of the checks pass. 548 If NSEC5 is said to match a domain name, the owner name of the NSEC5 549 RR has to be equivalent to an NSEC5 hash of that domain name. If an 550 NSEC5 RR is said to cover a domain name, the NSEC5 hash of the domain 551 name must sort in canonical order between that NSEC5 RR's Owner Name 552 and Next Hashed Owner Name. 554 8.1. Name Error Responses 556 Facts to prove: 558 Non-existence of the domain name that explictly matches the QNAME. 560 Non-existence of the wildcard that matches the QNAME. 562 Authoritative server proofs: 564 NSEC5PROOF for closest encloser and matching NSEC5 RR. 566 NSEC5PROOF for next closer name and covering NSEC5 RR. 568 Validator checks: 570 Closest encloser is in the zone. 572 The NSEC5 RR matching the closest encloser has its Wildcard flag 573 cleared. 575 The NSEC5 RR matching the closest encloser does not have NS 576 without SOA in the Type Bit Map. 578 The NSEC5 RR matching the closest encloser does not have DNAME in 579 the Type Bit Map. 581 Next closer name is not in the zone. 583 8.2. No Data Responses 585 The processing of a No Data response for DS QTYPE differs if the Opt- 586 Out is in effect. For DS QTYPE queries, the validator has two 587 possible checking paths. The correct path can be simply decided by 588 inspecting if the NSEC5 RR in the response matches the QNAME. 590 Note that the Opt-Out is valid only for DS QTYPE queries. 592 8.2.1. No Data Response, Opt-Out Not In Effect 594 Facts to prove: 596 Existence of an RRset explicitly matching the QNAME. 598 Non-existence of QTYPE RRset matching the QNAME. 600 Non-existence of CNAME RRset matching the QNAME. 602 Authoritative server proofs: 604 NSEC5PROOF for the QNAME and matching NSEC5 RR. 606 Validator checks: 608 QNAME is in the zone. 610 NSEC5 RR matching the QNAME does not have QTYPE in Type Bit Map. 612 NSEC5 RR matching the QNAME does not have CNAME in Type Bit Map. 614 8.2.2. No Data Response, Opt-Out In Effect 616 Facts to prove: 618 The delegation is not covered by the NSEC5 chain. 620 Authoritative server proofs: 622 NSEC5PROOF for closest provable encloser and matching NSEC5 RR. 624 Validator checks: 626 Closest provable encloser is in zone. 628 Closest provable encloser covers (not matches) the QNAME. 630 NSEC5 RR matching the closest provable encloser has Opt-Out flag 631 set. 633 8.3. Wildcard Responses 635 Facts to prove: 637 A signed positive response to the QNAME demonstrating the 638 existence of the wildcard (label count in RRSIG is less than in 639 QNAME), and also providing closest encloser name. 641 Non-existence of the domain name matching the QNAME. 643 Authoritative server proofs: 645 A signed positive response for the wildcard expansion of the 646 QNAME. 648 NSEC5PROOF for next closer name and covering NSEC5 RR. 650 Validator checks: 652 Next closer name is not in the zone. 654 8.4. Wildcard No Data Responses 656 Facts to prove: 658 The existence of the wildcard at the closest encloser to the 659 QNAME. 661 Non-existence of both the QTYPE and of the CNAME type that matches 662 QNAME via wildcard expansion. 664 Authoritative server proofs: 666 NSEC5PROOF for source of synthesis (i.e., wildcard at closest 667 encloser) and matching NSEC5 RR. 669 NSEC5PROOF for next closer name and covering NSEC5 RR. 671 Validator checks: 673 Closest encloser to the QNAME exists. 675 NSEC5 RR matching the wildcard label prepended to the closest 676 encloser, and which does not have the bits corresponding to the 677 QTYPE and CNAME types set it the type bitmap. 679 9. Authoritative Server Considerations 681 9.1. Zone Signing 683 Zones using NSEC5 MUST satisfy the same properties as described in 684 Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition, 685 the following conditions MUST be satisfied as well: 687 o If the original owner name has a wildcard label immediately 688 descending from the original owner name, the corresponding NSEC5 689 RR MUST have the Wildcard flag set in the Flags field. Otherwise, 690 the flag MUST be cleared. 692 o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5 693 public key allowing verification of the current NSEC5 chain. 695 The following steps describe one possible method to properly add 696 required NSEC5 related records into a zone. This is not the only 697 such existing method. 699 1. Select an algorithm for NSEC5 and generate the public and private 700 NSEC5 keys. 702 2. Add an NSEC5KEY RR into the zone apex containing the public NSEC5 703 key. 705 3. For each unique original domain name in the zone and each empty 706 non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names 707 of unsigned delegations MAY be excluded. 709 A. The owner name of the NSEC5 RR is the NSEC5 hash of the 710 original owner name encoded in Base32hex without padding, 711 prepended as a single label to the zone name. 713 B. Set the Key Tag field to be the key tag corresponding to the 714 public NSEC5 key. 716 C. Clear the Flags field. If Opt-Out is being used, set the 717 Opt-Out flag. If there is a wildcard label directly descending 718 from the original domain name, set the Wildcard flag. Note that 719 the wildcard can be an empty non-terminal (i.e., the wildcard 720 synthesis does not take effect and therefore the flag is not to 721 be set). 723 D. Set the Next Length field to a value determined by the used 724 NSEC5 algorithm. Leave the Next Hashed Owner Name field blank. 726 E. Set the Type Bit Maps field based on the RRsets present at 727 the original owner name. 729 4. Sort the set of NSEC5 RRs into canonical order. 731 5. For each NSEC5 RR, set the Next Hashed Owner Name field by using 732 the owner name of the next NSEC5 RR in the canonical order. If 733 the updated NSEC5 is the last NSEC5 RR in the chain, the owner 734 name of the first NSEC5 RR in the chain is used instead. 736 The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA 737 RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA 738 minimum TTL field. 740 Notice that a use of Opt-Out is not indicated in the zone. This does 741 not affect the ability of a server to prove insecure delegations. 742 The Opt-Out MAY be part of the zone-signing tool configuration. 744 9.1.1. Precomputing Closest Provable Encloser Proofs 746 Per Section 8, the worst-case scenario when answering a negative 747 query with NSEC5 requires the authoritative server to respond with 748 two NSEC5PROOF RRs and two NSEC5 RRs. One pair of NSEC5PROOF and 749 NSEC5 RRs corresponds to the closest provable encloser, and the other 750 pair corresponds to the next closer name. The NSEC5PROOF 751 corresponding to the next closer name MUST be computed on the fly by 752 the authoritative server when responding to the query. However, the 753 NSEC5PROOF corresponding to the closest provable encloser MAY be 754 precomputed and stored as part of zone signing. 756 Precomputing NSEC5PROOF RRs can halve the number of online 757 cryptographic computations required when responding to a negative 758 query. NSEC5PROOF RRs MAY be precomputed as part of zone signing as 759 follows: For each NSEC5 RR, compute an NSEC5PROOF RR corresponding to 760 the original owner name of the NSEC5 RR. The content of the 761 precomputed NSEC5PROOF record MUST be the same as if the record was 762 computed on the fly when serving the zone. NSEC5PROOF records are 763 not part of the zone and SHOULD be stored separately from the zone 764 file. 766 9.2. Zone Serving 768 This specification modifies DNSSEC-enabled DNS responses generated by 769 authoritative servers. In particular, it replaces use of NSEC or 770 NSEC3 RRs in such responses with NSEC5 RRs and adds NSEC5PROOF RRs. 772 According to the type of a response, an authoritative server MUST 773 include NSEC5 RRs in the response, as defined in Section 8. For each 774 NSEC5 RR in the response, a corresponding RRSIG RRset and an 775 NSEC5PROOF MUST be added as well. The NSEC5PROOF RR has its owner 776 name set to the domain name required according to the description in 777 Section 8. The class and TTL of the NSEC5PROOF RR MUST be the same 778 as the class and TTL value of the corresponding NSEC5 RR. The RDATA 779 payload of the NSEC5PROOF is set according to the description in 780 Section 7.1. 782 Notice that the NSEC5PROOF owner name can be a wildcard (e.g., source 783 of synthesis proof in wildcard No Data responses). The name also 784 always matches the domain name required for the proof while the NSEC5 785 RR may only cover (not match) the name in the proof (e.g., closest 786 encloser in Name Error responses). 788 If NSEC5 is used, an answering server MUST use exactly one NSEC5 789 chain for one signed zone. 791 NSEC5 MUST NOT be used in parallel with NSEC, NSEC3, or any other 792 authenticated denial of existence mechanism that allows for 793 enumeration of zone contents, as this would defeat a principal 794 security goal of NSEC5. 796 Similarly to NSEC3, the owner names of NSEC5 RRs are not represented 797 in the NSEC5 chain and therefore NSEC5 records deny their own 798 existence. The desired behavior caused by this paradox is the same 799 as described in Section 7.2.8 of [RFC5155]. 801 9.3. NSEC5KEY Rollover Mechanism 803 Replacement of the NSEC5 key implies generating a new NSEC5 chain. 804 The NSEC5KEY rollover mechanism is similar to "Pre-Publish Zone 805 Signing Key Rollover" as specified in [RFC6781]. The NSEC5KEY 806 rollover MUST be performed as a sequence of the following steps: 808 1. A new public NSEC5 key is added into the NSEC5KEY RRset in the 809 zone apex. 811 2. The old NSEC5 chain is replaced by a new NSEC5 chain constructed 812 using the new key. This replacement MUST happen as a single 813 atomic operation; the server MUST NOT be responding with RRs from 814 both the new and old chain at the same time. 816 3. The old public key is removed from the NSEC5KEY RRset in the zone 817 apex. 819 The minimum delay between steps 1 and 2 MUST be the time it takes for 820 the data to propagate to the authoritative servers, plus the TTL 821 value of the old NSEC5KEY RRset. 823 The minimum delay between steps 2 and 3 MUST be the time it takes for 824 the data to propagate to the authoritative servers, plus the maximum 825 zone TTL value of any of the data in the previous version of the 826 zone. 828 9.4. Secondary Servers 830 This document does not define mechanism to distribute private NSEC5 831 keys. See Section 15.2 for security considerations for private NSEC5 832 keys. 834 9.5. Zones Using Unknown NSEC5 Algorithms 836 Zones that are signed with an unknown NSEC5 algorithm or with an 837 unavailable private NSEC5 key cannot be effectively served. Such 838 zones SHOULD be rejected when loading and servers SHOULD respond with 839 RCODE=2 (Server failure) when handling queries that would fall under 840 such zones. 842 9.6. Dynamic Updates 844 A zone signed using NSEC5 MAY accept dynamic updates [RFC2136]. The 845 changes to the zone MUST be performed in a way that ensures that the 846 zone satisfies the properties specified in Section 9.1 at any time. 847 The process described in [RFC5155] Section 7.5 describes how to 848 handle the issues surrounding the handling of empty non-terminals as 849 well as Opt-Out. 851 It is RECOMMENDED that the server rejects all updates containing 852 changes to the NSEC5 chain and its related RRSIG RRs, and performs 853 itself any required alternations of the NSEC5 chain induced by the 854 update. Alternatively, the server MUST verify that all the 855 properties are satisfied prior to performing the update atomically. 857 10. Resolver Considerations 859 The same considerations as described in Section 9 of [RFC5155] for 860 NSEC3 apply to NSEC5. In addition, as NSEC5 RRs can be validated 861 only with appropriate NSEC5PROOF RRs, the NSEC5PROOF RRs MUST be all 862 together cached and included in responses with NSEC5 RRs. 864 11. Validator Considerations 866 11.1. Validating Responses 868 The validator MUST ignore NSEC5 RRs with Flags field values other 869 than the ones defined in Section 6.2. 871 The validator MAY treat responses as bogus if the response contains 872 NSEC5 RRs that refer to a different NSEC5KEY. 874 According to a type of a response, the validator MUST verify all 875 conditions defined in Section 8. Prior to making decision based on 876 the content of NSEC5 RRs in a response, the NSEC5 RRs MUST be 877 validated. 879 To validate a denial of existence, public NSEC5 keys for the zone are 880 required in addition to DNSSEC public keys. Similarly to DNSKEY RRs, 881 the NSEC5KEY RRs are present at the zone apex. 883 The NSEC5 RR is validated as follows: 885 1. Select a correct public NSEC5 key to validate the NSEC5 proof. 886 The Key Tag value of the NSEC5PROOF RR must match with the key 887 tag value computed from the NSEC5KEY RDATA. 889 2. Validate the NSEC5 proof present in the NSEC5PROOF Owner Name 890 Hash field using the public NSEC5 key. If there are multiple 891 NSEC5KEY RRs matching the key tag, at least one of the keys must 892 validate the NSEC5 proof. 894 3. Compute the NSEC5 hash value from the NSEC5 proof and check if 895 the response contains NSEC5 RR matching or covering the computed 896 NSEC5 hash. The TTL values of the NSEC5 and NSEC5PROOF RRs must 897 be the same. 899 4. Validate the signature on the NSEC5 RR. 901 If the NSEC5 RR fails to validate, it MUST be ignored. If some of 902 the conditions required for an NSEC5 proof are not satisfied, the 903 response MUST be treated as bogus. 905 Notice that determining the closest encloser and next closer name in 906 NSEC5 is easier than in NSEC3. NSEC5 and NSEC5PROOF RRs are always 907 present in pairs in responses and the original owner name of the 908 NSEC5 RR matches the owner name of the NSEC5PROOF RR. 910 11.2. Validating Referrals to Unsigned Subzones 912 The same considerations as defined in Section 8.9 of [RFC5155] for 913 NSEC3 apply to NSEC5. 915 11.3. Responses With Unknown NSEC5 Algorithms 917 A validator MUST ignore NSEC5KEY RRs with unknown NSEC5 algorithms. 918 The practical result of this is that zones signed with unknown 919 algorithms will be considered bogus. 921 12. Special Considerations 923 12.1. Transition Mechanism 925 [TODO: The following information will be covered.] 927 o Transition to NSEC5 from NSEC/NSEC3 929 o Transition from NSEC5 to NSEC/NSEC3 931 o Transition to new NSEC5 algorithms 933 12.2. Private NSEC5 keys 935 This document does not define a format to store private NSEC5 keys. 936 Use of a standardized and adopted format is RECOMMENDED. 938 The private NSEC5 key MAY be shared between multiple zones, however a 939 separate key is RECOMMENDED for each zone. 941 12.3. Domain Name Length Restrictions 943 NSEC5 creates additional restrictions on domain name lengths. In 944 particular, zones with names that, when converted into hashed owner 945 names, exceed the 255 octet length limit imposed by [RFC1035] cannot 946 use this specification. 948 The actual maximum length of a domain name depends on the length of 949 the zone name and the NSEC5 algorithm used. 951 All NSEC5 algorithms defined in this document use 256-bit NSEC5 hash 952 values. Such a value can be encoded in 52 characters in Base32hex 953 without padding. When constructing the NSEC5 RR owner name, the 954 encoded hash is prepended to the name of the zone as a single label 955 which includes the length field of a single octet. The maximum 956 length of the zone name in wire format using the 256-bit hash is 957 therefore 202 octets (255 - 53). 959 13. Implementation Status 961 NSEC5 has been implemented for the Knot DNS authoritative server 962 (version 1.6.4) and the Unbound recursive server (version 1.5.9). 963 The implementations did not introduce additional library 964 dependencies; all cryptographic primitives are already present in 965 OpenSSL v1.0.2j, which is used by both implementations. The 966 implementations support the full spectrum of negative responses, 967 (i.e., NXDOMAIN, NODATA, Wildcard, Wildcard NODATA, and unsigned 968 delegation) using the EC-P256-SHA256 algorithm. The code is 969 deliberately modular, so that the EC-ED25519-SHA256 algorithm could 970 be implemented by using the Ed25519 elliptic curve [RFC8080] as a 971 drop-in replacement for the P256 elliptic curve. The authoritative 972 server implements the optimization from Section 9.1.1 to precompute 973 the NSEC5PROOF RRs matching each NSEC5 record. 975 14. Performance Considerations 977 The performance of NSEC5 has been evaluated in [nsec5ecc]. 979 15. Security Considerations 981 15.1. Zone Enumeration Attacks 983 NSEC5 is robust to zone enumeration via offline dictionary attacks by 984 any attacker that does not know the private NSEC5 key. Without the 985 private NSEC5 key, that attacker cannot compute the NSEC5 proof that 986 corresponds to a given domain name. The only way it can learn the 987 NSEC5 proof value for a domain name is by querying the authoritative 988 server for that name. Without the NSEC5 proof value, the attacker 989 cannot learn the NSEC5 hash value. Thus, even an attacker that 990 collects the entire chain of NSEC5 RR for a zone cannot use offline 991 attacks to "reverse" that NSEC5 hash values in these NSEC5 RR and 992 thus learn which names are present in the zone. A formal 993 cryptographic proof of this property is in [nsec5] and [nsec5ecc]. 995 15.2. Compromise of the Private NSEC5 Key 997 NSEC5 requires authoritative servers to hold the private NSEC5 key, 998 but not the private zone-signing keys or the private key-signing keys 999 for the zone. 1001 The private NSEC5 key cannot be used to modify zone contents, because 1002 zone contents are signed using the private zone-signing key. As 1003 such, a compromise of the private NSEC5 key does not compromise the 1004 integrity of the zone. An adversary that learns the private NSEC5 1005 key can, however, perform offline zone-enumeration attacks. For this 1006 reason, the private NSEC5 key need only be as secure as the DNSSEC 1007 records whose privacy (against zone enumeration) is being protected 1008 by NSEC5. A formal cryptographic proof of this property is in 1009 [nsec5] and [nsec5ecc]. 1011 To preserve this property of NSEC5, the private NSEC5 key MUST be 1012 different from the private zone-signing keys or key-signing keys for 1013 the zone. 1015 15.3. Key Length Considerations 1017 The NSEC5 key must be long enough to withstand attacks for as long as 1018 the privacy of the zone contents is important. Even if the NSEC5 key 1019 is rolled frequently, its length cannot be too short, because zone 1020 privacy may be important for a period of time longer than the 1021 lifetime of the key. For example, an attacker might collect the 1022 entire chain of NSEC5 RR for the zone over one short period, and 1023 then, later (even after the NSEC5 key expires) perform an offline 1024 dictionary attack that attempts to reverse the NSEC5 hash values 1025 present in the NSEC5 RRs. This is in contrast to zone-signing and 1026 key-signing keys used in DNSSEC; these keys, which ensure the 1027 authenticity and integrity of the zone contents, need to remain 1028 secure only during their lifetime. 1030 15.4. NSEC5 Hash Collisions 1032 If the NSEC5 hash of a QNAME collides with the NSEC5 hash of the 1033 owner name of an NSEC5 RR, it will be impossible to prove the non- 1034 existence of the colliding QNAME. However, the NSEC5 VRFs ensure 1035 that obtaining such a collision is as difficult as obtaining a 1036 collision in the SHA-256 hash function, requiring approximately 2^128 1037 effort. Note that DNSSEC already relies on the assumption that a 1038 cryptographic hash function is collision-resistant, since these hash 1039 functions are used for generating and validating signatures and DS 1040 RRs. See also the discussion on key lengths in [nsec5]. 1042 16. IANA Considerations 1044 This document updates the IANA registry "Domain Name System (DNS) 1045 Parameters" in subregistry "Resource Record (RR) TYPEs", by defining 1046 the following new RR types: 1048 NSEC5KEY value TBD. 1050 NSEC5 value TBD. 1052 NSEC5PROOF value TBD. 1054 This document creates a new IANA registry for NSEC5 algorithms. This 1055 registry is named "DNSSEC NSEC5 Algorithms". The initial content of 1056 the registry is: 1058 0 is Reserved. 1060 1 is EC-P256-SHA256. 1062 2 is EC-ED25519-SHA256. 1064 3-255 is Available for assignment. 1066 This document updates the IANA registry "DNS Security Algorithm 1067 Numbers" by defining following aliases: 1069 TBD is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13). 1071 TBD is NSEC5-ED25519, alias for ED25519 (15). 1073 17. Contributors 1075 This document would not be possible without help of Moni Naor 1076 (Weizmann Institute), Sachin Vasant (Cisco Systems), Leonid Reyzin 1077 (Boston University), and Asaf Ziv (Weizmann Institute) who 1078 contributed to the design of NSEC5. Ondrej Sury (CZ.NIC Labs), and 1079 Duane Wessels (Verisign Labs) provided advice on the implementation 1080 of NSEC5, and assisted with evaluating its performance. 1082 18. References 1084 18.1. Normative References 1086 [FIPS-186-3] 1087 National Institute for Standards and Technology, "Digital 1088 Signature Standard (DSS)", FIPS PUB 186-3, June 2009. 1090 [I-D.irtf-cfrg-vrf] 1091 Goldberg, S., Reyzin, L., Papadopoulos, D., and J. Vcelak, 1092 "Verifiable Random Functions (VRFs)", draft-irtf-cfrg- 1093 vrf-01 (work in progress), March 2018. 1095 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1096 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1097 . 1099 [RFC1035] Mockapetris, P., "Domain names - implementation and 1100 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1101 November 1987, . 1103 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1104 Requirement Levels", BCP 14, RFC 2119, 1105 DOI 10.17487/RFC2119, March 1997, 1106 . 1108 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 1109 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1110 RFC 2136, DOI 10.17487/RFC2136, April 1997, 1111 . 1113 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1114 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 1115 . 1117 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1118 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 1119 . 1121 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1122 Rose, "DNS Security Introduction and Requirements", 1123 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1124 . 1126 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1127 Rose, "Resource Records for the DNS Security Extensions", 1128 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1129 . 1131 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1132 Rose, "Protocol Modifications for the DNS Security 1133 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 1134 . 1136 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1137 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 1138 . 1140 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 1141 Groups for Use with IETF Standards", RFC 5114, 1142 DOI 10.17487/RFC5114, January 2008, 1143 . 1145 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1146 Security (DNSSEC) Hashed Authenticated Denial of 1147 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 1148 . 1150 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1151 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1152 DOI 10.17487/RFC6234, May 2011, 1153 . 1155 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 1156 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 1157 DOI 10.17487/RFC6605, April 2012, 1158 . 1160 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1161 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1162 2016, . 1164 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 1165 Algorithm (EdDSA) for DNSSEC", RFC 8080, 1166 DOI 10.17487/RFC8080, February 2017, 1167 . 1169 18.2. Informative References 1171 [I-D.gieben-nsec4] 1172 Gieben, R. and M. Mekking, "DNS Security (DNSSEC) 1173 Authenticated Denial of Existence", draft-gieben-nsec4-01 1174 (work in progress), July 2012. 1176 [ldns-walk] 1177 NLNetLabs, "ldns", 2015, 1178 . 1180 [MRV99] Michali, S., Rabin, M., and S. Vadhan, "Verifiable Random 1181 Functions", in FOCS, 1999. 1183 [nmap-nsec-enum] 1184 Bond, J., "nmap: dns-nsec-enum", 2011, 1185 . 1187 [nmap-nsec3-enum] 1188 Nikolic, A. and J. Bond, "nmap: dns-nsec3-enum", 2011, 1189 . 1191 [nsec3gpu] 1192 Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, 1193 "GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network 1194 Computing and Applications (NCA), 2014. 1196 [nsec3map] 1197 anonion0, "nsec3map with John the Ripper plugin", 2015, 1198 . 1200 [nsec3walker] 1201 Bernstein, D., "Nsec3 walker", 2011, 1202 . 1204 [nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., 1205 Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC 1206 Zone Enumeration", in NDSS'15, July 2014, 1207 . 1209 [nsec5ecc] 1210 Papadopoulos, D., Wessels, D., Huque, S., Vcelak, J., 1211 Naor, M., Reyzin, L., and S. Goldberg, "Can NSEC5 be 1212 Practical for DNSSEC Deployments?", in ePrint Cryptology 1213 Archive 2017/099, February 2017, 1214 . 1216 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1217 Operational Practices, Version 2", RFC 6781, 1218 DOI 10.17487/RFC6781, December 2012, 1219 . 1221 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1222 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 1223 February 2014, . 1225 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1226 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1227 2015, . 1229 Appendix A. Examples 1231 We use a small DNS zone to illustrate how negative responses are 1232 handled with NSEC5. For brevity, the class is not shown (defaults to 1233 IN) and the SOA record is shortened, resulting in the following zone 1234 file: 1236 example.org. SOA ( ... ) 1237 example.org. NS a.example.org 1239 a.example.org. A 192.0.2.1 1241 c.example.org. A 192.0.2.2 1242 c.example.org. TXT "c record" 1244 d.example.org. NS ns1.d.example.org 1246 ns1.d.example.org. A 192.0.2.4 1248 g.example.org. A 192.0.2.1 1249 g.example.org. TXT "g record" 1251 *.a.example.org. TXT "wildcard record" 1253 Notice the delegation to an unsigned zone d.example.org served by 1254 ns1.d.example.org. (Note: if the d.example.org zone was signed, then 1255 the example.org zone have a DS record for d.example.org.) 1257 Next we present example responses. All cryptographic values are 1258 shortened as indicated by "..." and ADDITIONAL sections have been 1259 removed. 1261 A.1. Name Error Example 1263 Consider a query for a type A record for a.b.c.example.org. 1265 The server must prove the following facts: 1267 o Existence of closest encloser c.example.org. 1269 o Non-existence of wildcard at closest encloser *.c.example.org. 1271 o Non-existence of next closer b.c.example.org. 1273 To do this, the server returns: 1275 ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 5937 1277 ;; QUESTION SECTION: 1278 ;; a.b.c.example.org. IN A 1280 ;; AUTHORITY SECTION: 1281 example.org. 3600 IN SOA a.example.org. hostmaster.example.org. ( 1282 2010111214 21600 3600 604800 86400 ) 1284 example.org. 3600 IN RRSIG SOA 16 2 3600 ( 1285 20170412024301 20170313024301 5137 example.org. rT231b1rH... ) 1287 This is an NSEC5PROOF RR for c.example.com. It's RDATA is the NSEC5 1288 proof corresponding to c.example.com. (NSEC5 proofs are randomized 1289 values, because NSEC5 proof values are computed uses the EC-VRF from 1290 [I-D.irtf-cfrg-vrf].) Per Section 9.1.1, this NSEC5PROOF RR may be 1291 precomputed. 1293 c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT... 1295 This is a signed NSEC5 RR "matching" c.example.org, which proves the 1296 existence of closest encloser c.example.org. The NSEC5 RR has its 1297 owner name equal to the NSEC5 hash of c.example.org, which is O4K89V. 1298 (NSEC5 hash values are deterministic given the public NSEC5 key.) 1299 The NSEC5 RR also has its Wildcard flag cleared (see the "0" after 1300 the key ID 48566). This proves the non-existence of the wildcard at 1301 the closest encloser *.c.example.com. NSEC5 RRs are precomputed. 1303 o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG 1304 o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1305 20170412024301 20170313024301 5137 example.org. zDNTSMQNlz... ) 1307 This is an NSEC5PROOF RR for b.c.example.org. It's RDATA is the 1308 NSEC5 proof corresponding to b.c.example.com. This NSEC5PROOF RR 1309 must be computed on the fly. 1311 b.c.example.org. 86400 IN NSEC5PROOF 48566 AuvvJqbUcEs8sCpY... 1313 This is a signed NSEC5 RR "covering" b.c.example.org, which proves 1314 the non-existence of the next closer name b.c.example.org The NSEC5 1315 hash of b.c.example.org, which is AO5OF, sorts in canonical order 1316 between the "covering" NSEC5 RR's Owner Name (which is 0O49PI) and 1317 Next Hashed Owner Name (which is BAPROH). 1319 0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH ( 1320 NS SOA RRSIG DNSKEY NSEC5KEY ) 1322 0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1323 20170412024301 20170313024301 5137 example.org. 4HT1uj1YlMzO) 1325 [TODO: Add discussion of CNAME and DNAME to the example?] 1327 A.2. No Data Example 1329 Consider a query for a type MX record for c.example.org. 1331 The server must prove the following facts: 1333 o Existence of c.example.org. for any type other than MX or CNAME 1335 To do this, the server returns: 1337 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 38781 1339 ;; QUESTION SECTION: 1340 ;; c.example.org. IN MX 1342 ;; AUTHORITY SECTION: 1343 example.org. 3600 IN SOA a.example.org. hostmaster.example.org. ( 1344 2010111214 21600 3600 604800 86400 ) 1346 example.org. 3600 IN RRSIG SOA 16 2 3600 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p 1348 This is an NSEC5PROOF RR for c.example.com. Its RDATA corresponds to 1349 the NSEC5 proof for c.example.com. which is a randomized value. Per 1350 Section 9.1.1, this NSEC5PROOF RR may be precomputed. 1352 c.example.org. 86400 IN NSEC5PROOF 48566 Amgn22zUiZ9JVyaT 1354 This is a signed NSEC5 RR "matching" c.example.org. with CNAME and MX 1355 Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has its 1356 owner name equal to the NSEC5 hash of c.example.org. This proves the 1357 existence of c.example.org. for a type other than MX and CNAME. 1358 NSEC5 RR are precomputed. 1360 o4k89v.example.org. 86400 IN NSEC5 48566 0 0O49PI A TXT RRSIG 1362 o4k89v.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1363 20170412024301 20170313024301 5137 example.org. zDNTSMQNlz/J) 1365 A.3. Delegation to an Unsigned Zone in an Opt-Out span Example 1367 Consider a query for a type A record for foo.d.example.org. 1369 Here, d.example.org is a delegation to an unsigned zone, which lies 1370 within an Opt-Out span. 1372 The server must prove the following facts: 1374 o Non-existence of signature on next closer name d.example.org. 1376 o Opt-out bit is set in NSEC5 record covering next closer name 1377 d.example.org. 1379 o Existence of closest provable encloser example.org 1381 To do this, the server returns: 1383 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 45866 1385 ;; QUESTION SECTION: 1386 ;; foo.d.example.org. IN A 1388 ;; AUTHORITY SECTION: 1389 d.example.org. 3600 IN NS ns1.d.example.org. 1391 This is an NSEC5PROOF RR for d.example.org. Its RDATA is the NSEC5 1392 proof corresponding to d.example.org. This NSEC5PROOF RR is computed 1393 on the fly. 1395 d.example.org. 86400 IN NSEC5PROOF 48566 A9FpmeH79q7g6VNW 1397 This is a signed NSEC5 RR "covering" d.example.org with its Opt-out 1398 bit set (see the "1" after the key ID 48566). The NSEC5 hash of 1399 d.example.org (which is BLE8LR) sorts in canonical order between the 1400 "covering" NSEC5 RR's Owner Name (BAPROH) and Next Hashed Owner Name 1401 (JQBMG4). This proves that no signed RR exists for d.example.org, 1402 but that the zone might contain a unsigned RR for a name whose NSEC5 1403 hash sorts in canonical order between BAPROH and JQBMG4. 1405 baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG 1407 baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1408 20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1) 1410 This is an NSEC5PROOF RR for example.com. It's RDATA is the NSEC5 1411 proof corresponding to example.com. Per Section 9.1.1, this 1412 NSEC5PROOF RR may be precomputed. 1414 example.org. 86400 IN NSEC5PROOF 48566 AjwsPCJZ8zH/D0Tr 1416 This is a signed NSEC5 RR "matching" example.org which proves the 1417 existence of a signed RRs for example.org. This NSEC5 RR has its 1418 owner name equal to the NSEC5 hash of example.org which is 0O49PI. 1419 NSEC5 RR are precomputed. 1421 0o49pi.example.org. 86400 IN NSEC5 48566 0 BAPROH ( 1422 NS SOA RRSIG DNSKEY NSEC5KEY) 1424 0o49pi.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1425 20170412034216 20170313034216 5137 example.org. 4HT1uj1YlMzO) 1427 A.4. Wildcard Example 1429 Consider a query for a type TXT record for foo.a.example.org. 1431 The server must prove the following facts: 1433 o Existence of the TXT record for the wildcard *.a.example.org 1435 o Non-existence of the next closer name foo.a.example.org. 1437 To do this, the server returns: 1439 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 53731 1441 ;; QUESTION SECTION: 1442 ;; foo.a.example.org. IN TXT 1444 This is a signed TXT record for the wildcard at a.example.org (number 1445 of labels is set to 3 in the RRSIG record). 1447 ;; ANSWER SECTION: 1448 foo.a.example.org. 3600 IN TXT "wildcard record" 1450 foo.a.example.org. 3600 IN RRSIG TXT 16 3 3600 ( 1451 20170412024301 20170313024301 5137 example.org. aeaLgZ8sk+98) 1453 ;; AUTHORITY SECTION: 1454 example.org. 3600 IN NS a.example.org. 1456 example.org. 3600 IN RRSIG NS 16 2 3600 ( 1457 20170412024301 20170313024301 5137 example.org. 8zuN0h2x5WyF) 1459 This is an NSEC5PROOF RR for foo.a.example.org. This NSEC5PROOF RR 1460 must be computed on-the-fly. 1462 foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda 1464 This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5 1465 hash of foo.a.example.org is FORDMO and sorts in canonical order 1466 between the NSEC5 RR's Owner Name (which is BAPROH) and Next Hashed 1467 Owner Name (which is JQBMG4). This proves the non-existence of the 1468 next closer name foo.a.example.com. NSEC5 RRs are precomputed. 1470 baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG 1471 baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1472 20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 1474 A.5. Wildcard No Data Example 1476 Consider a query for a type MX record for foo.a.example.org. 1478 The server must prove the following facts: 1480 o Existence of wildcard at closest encloser *.a.example.org. for any 1481 type other than MX or CNAME. 1483 o Non-existence of the next closer name foo.a.example.org. 1485 To do this, the server returns: 1487 ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17332 1489 ;; QUESTION SECTION: 1490 ;; foo.a.example.org. IN MX 1492 ;; AUTHORITY SECTION: 1493 example.org. 3600 IN SOA a.example.org. hostmaster.example.org. ( 1494 2010111214 21600 3600 604800 86400 ) 1496 example.org. 3600 IN RRSIG SOA 16 2 3600 ( 1497 20170412024301 20170313024301 5137 example.org. /rT231b1rH/p ) 1499 This is an NSEC5PROOF RR for *.a.example.com, with RDATA equal to the 1500 NSEC5 proof for *.a.example.com. Per Section 9.1.1, this NSEC5PROOF 1501 RR may be precomputed. 1503 *.a.example.org. 86400 IN NSEC5PROOF 48566 Aq38RWWPhbs/vtih 1505 This is a signed NSEC5 RR "matching" *.a.example.org with its CNAME 1506 and MX Type Bits cleared and its TXT Type Bit set. This NSEC5 RR has 1507 its owner name equal to the NSEC5 hash of *.a.example.org. NSEC5 RRs 1508 are precomputed. 1510 mpu6c4.example.org. 86400 IN NSEC5 48566 0 O4K89V TXT RRSIG 1512 mpu6c4.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1513 20170412024301 20170313024301 5137 example.org. m3I75ttcWwVC ) 1515 This is an NSEC5PROOF RR for foo.a.example.com. This NSEC5PROOF RR 1516 must be computed on-the-fly. 1518 foo.a.example.org. 86400 IN NSEC5PROOF 48566 AjqF5FGGVso40Lda 1520 This is a signed NSEC5 RR "covering" foo.a.example.org. The NSEC5 1521 hash of foo.a.example.org is FORDMO, and sorts in canonical order 1522 between this covering NSEC5 RR's Owner Name (which is BAPROH) and 1523 Next Hashed Owner Name (which is JQBMG4). This proves the existence 1524 of the wildcard at closest encloser *.a.example.org. for any type 1525 other than MX or CNAME. NSEC5 RRs are precomputed. 1527 baproh.example.org. 86400 IN NSEC5 48566 1 JQBMG4 A TXT RRSIG 1529 baproh.example.org. 86400 IN RRSIG NSEC5 16 3 86400 ( 1530 20170412024301 20170313024301 5137 example.org. fjTcoRKgdML1 ) 1532 Appendix B. Change Log 1534 Note to RFC Editor: if this document does not obsolete an existing 1535 RFC, please remove this appendix before publication as an RFC. 1537 pre 00 - initial version of the document submitted to mailing list 1538 only 1540 00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA, 1541 clarify inputs and outputs for NSEC5 proof and NSEC5 hash 1542 computation. 1544 01 - Add Performance Considerations section. 1546 02 - Add elliptic curve based VRF. Add measurement of response 1547 sizes based on empirical data. 1549 03 - Mention precomputed NSEC5PROOF Values in Performance 1550 Considerations section. 1552 04 - Edit Rationale, How NSEC5 Works, and Security Consideration 1553 sections for clarity. Edit Zone Signing section, adding 1554 precomputation of NSEC5PROOFs. Remove RSA-based NSEC5 1555 specification. Rewrite Performance Considerations and 1556 Implementation Status sections. 1558 05 - Remove appendix specifying VRFs and add reference to draft- 1559 goldbe-vrf. Add Appendix A. 1561 06 - Editorial changes. Minor updates to Section 8.1. 1563 07 - Updated reference to [I-D.irtf-cfrg-vrf], updated VRF 1564 ciphersuites. 1566 Authors' Addresses 1568 Jan Vcelak 1569 CZ.NIC 1570 Milesovska 1136/5 1571 Praha 130 00 1572 CZ 1574 EMail: jan.vcelak@nic.cz 1576 Sharon Goldberg 1577 Boston University 1578 111 Cummington St, MCS135 1579 Boston, MA 02215 1580 USA 1582 EMail: goldbe@cs.bu.edu 1584 Dimitrios Papadopoulos 1585 HKUST 1586 Clearwater Bay 1587 Hong Kong 1589 EMail: dipapado@ust.hk 1591 Shumon Huque 1592 Salesforce 1593 2550 Wasser Terr 1594 Herndon, VA 20171 1595 USA 1597 EMail: shuque@gmail.com 1598 David C Lawrence 1599 Akamai Technologies 1600 150 Broadway 1601 Boston, MA 02142-1054 1602 USA 1604 EMail: tale@akamai.com