idnits 2.17.00 (12 Aug 2021) /tmp/idnits48766/draft-vcelak-nsec5-00.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 (March 23, 2015) is 2615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 6234 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Vcelak 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track S. Goldberg 5 Expires: September 24, 2015 Boston University 6 March 23, 2015 8 NSEC5, DNSSEC Authenticated Denial of Existence 9 draft-vcelak-nsec5-00 11 Abstract 13 The Domain Name System Security (DNSSEC) Extensions introduced the 14 NSEC resource record (RR) for authenticated denial of existence and 15 the NSEC3 for hashed authenticated denial of existence. The NSEC RR 16 allows for the entire zone contents to be enumerated if a server is 17 queried for carefully chosen domain names; N queries suffice to 18 enumerate a zone containing N names. The NSEC3 RR adds domain-name 19 hashing, which makes the zone enumeration harder, but not impossible. 20 This document introduces NSEC5, which provides an cryptographically- 21 proven mechanism that prevents zone enumeration. NSEC5 has the 22 additional advantage of not requiring private zone-signing keys to be 23 present on all authoritative servers for the zone. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 24, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 62 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 64 3. How NSEC5 Works . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. NSEC5 Algorithms . . . . . . . . . . . . . . . . . . . . . . 6 66 5. The NSEC5KEY Resource Record . . . . . . . . . . . . . . . . 7 67 5.1. NSEC5KEY RDATA Wire Format . . . . . . . . . . . . . . . 7 68 5.2. NSEC5KEY RDATA Presentation Format . . . . . . . . . . . 7 69 6. The NSEC5 Resource Record . . . . . . . . . . . . . . . . . . 7 70 6.1. NSEC5 RDATA Wire Format . . . . . . . . . . . . . . . . . 7 71 6.2. NSEC5 Flags Field . . . . . . . . . . . . . . . . . . . . 8 72 6.3. NSEC5 RDATA Presentation Format . . . . . . . . . . . . . 9 73 7. The NSEC5PROOF Resource Record . . . . . . . . . . . . . . . 9 74 7.1. NSEC5PROOF RDATA Wire Format . . . . . . . . . . . . . . 9 75 7.2. NSEC5PROOF RDATA Presentation Format . . . . . . . . . . 9 76 8. NSEC5 Proofs . . . . . . . . . . . . . . . . . . . . . . . . 10 77 8.1. Name Error Responses . . . . . . . . . . . . . . . . . . 10 78 8.2. No Data Responses . . . . . . . . . . . . . . . . . . . . 11 79 8.2.1. No Data Response, Opt-Out Not In Effect . . . . . . . 11 80 8.2.2. No Data Response, Opt-Out In Effect . . . . . . . . . 11 81 8.3. Wildcard Responses . . . . . . . . . . . . . . . . . . . 12 82 8.4. Wildcard No Data Responses . . . . . . . . . . . . . . . 12 83 9. Authoritative Server Considerations . . . . . . . . . . . . . 13 84 9.1. Zone Signing . . . . . . . . . . . . . . . . . . . . . . 13 85 9.2. Zone Serving . . . . . . . . . . . . . . . . . . . . . . 14 86 9.3. NSEC5KEY Rollover Mechanism . . . . . . . . . . . . . . . 15 87 9.4. Secondary Servers . . . . . . . . . . . . . . . . . . . . 15 88 9.5. Zones Using Unknown Hash Algorithms . . . . . . . . . . . 16 89 9.6. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 16 90 10. Resolver Considerations . . . . . . . . . . . . . . . . . . . 16 91 11. Validator Considerations . . . . . . . . . . . . . . . . . . 16 92 11.1. Validating Responses . . . . . . . . . . . . . . . . . . 16 93 11.2. Validating Referrals to Unsigned Subzones . . . . . . . 17 94 11.3. Responses With Unknown Hash Algorithms . . . . . . . . . 17 95 12. Special Considerations . . . . . . . . . . . . . . . . . . . 17 96 12.1. Transition Mechanism . . . . . . . . . . . . . . . . . . 17 97 12.2. NSEC5 Private Keys . . . . . . . . . . . . . . . . . . . 18 98 12.3. Domain Name Length Restrictions . . . . . . . . . . . . 18 99 13. Performance Considerations . . . . . . . . . . . . . . . . . 19 100 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 14.1. Zone Enumeration Attacks . . . . . . . . . . . . . . . . 19 102 14.2. Hash Collisions . . . . . . . . . . . . . . . . . . . . 19 103 14.3. Compromise of the Private NSEC5 Key . . . . . . . . . . 19 104 14.4. Key Length Considerations . . . . . . . . . . . . . . . 20 105 14.5. Transitioning to a New NSEC5 Algorithm . . . . . . . . . 20 106 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 107 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 108 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 109 17.1. Normative References . . . . . . . . . . . . . . . . . . 21 110 17.2. Informative References . . . . . . . . . . . . . . . . . 22 111 Appendix A. Full Domain Hash Algorithm . . . . . . . . . . . . . 23 112 A.1. FDH signature . . . . . . . . . . . . . . . . . . . . . . 23 113 A.2. FDH verification . . . . . . . . . . . . . . . . . . . . 24 114 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 25 115 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 25 117 1. Introduction 119 1.1. Rationale 121 The DNS Security Extensions (DNSSEC) provides data integrity 122 protection using public-key cryptography, while not requiring that 123 authoritative servers compute signatures on-the-fly. The content of 124 the zone is usually pre-computed and served as is. The evident 125 advantages of this approach are reduced performance requirements per 126 query, as well as not requiring private zone-signing keys to be 127 present on nameservers facing the network. 129 With DNSSEC, each resource record (RR) set in the zone is signed. 130 The signature is retained as an RRSIG RR directly in the zone. This 131 enables response authentication for data existing in the zone. To 132 ensure integrity of denying answers, an NSEC chain of all existing 133 domain names in the zone is constructed. The chain is made of RRs, 134 where each RR represents two consecutive domain names in canonical 135 order present in the zone. The NSEC RRs are signed the same way as 136 any other RRs in the zone, and each NSEC can be used to prove that a 137 given name does not existing in a part of the domain name space. 139 As side-effect, however, the NSEC chain existence allows for the 140 enumeration of the zone's contents by querying for names immediately 141 individual RRs in the chain; N queries suffice to enumerate a zone 142 containing N names. As such, the NSEC3 hashed denial of existence 143 was introduced to prevent zone enumeration. In NSEC3, the original 144 domain names in the NSEC chain are replaced by their cryptographic 145 hashes. While NSEC3 makes zone enumeration more difficult, offline 146 dictionary attacks are still possible and have been demonstrated; 147 this is because hashes may be computed offline and the space of 148 possible domain names is restricted [nsec3walker][nsec3gpu]. 150 Zone enumeration can be prevented with NSEC3 if having the 151 authoritative server compute NSEC3 RRs on-the-fly, in response to 152 queries with denying responses. Usually, this is done with Minimally 153 Covering NSEC Records or NSEC3 White Lies [RFC7129]. One of the most 154 significant disadvantage of this approach is a required presence of 155 the private key on all authoritative servers for the zone. This is 156 often undesirable, as the holder of the private key can tamper with 157 the zone content, and having private keys on many network-facing 158 servers increases the risk that keys can be compromised. 160 To prevent zone content enumeration without keeping private keys on 161 all authoritative servers, NSEC5 replaces the unkeyed cryptographic 162 hash function used in NSEC3 with a public-key hashing scheme. 163 Hashing in NSEC5 is performed with a separate NSEC5 key. The public 164 portion of this key is distributed in an NSEC5KEY RR, and is used to 165 validate NSEC5 hash values. The private portion of the NSEC5 key is 166 present on all authoritative servers for the zone, and is used to 167 compute hash values. 169 Importantly, the NSEC5KEY key cannot be used to modify the contents 170 of the zone. Thus, any compromise of the private NSEC5 key does not 171 lead to a compromise of zone contents; all that is lost is privacy 172 against zone enumeration, effectively downgrading the security of 173 NSEC5 to that of NSEC3. NSEC5 comes with a cryptographic proof of 174 security, available in [nsec5]. 176 The NSEC5 is not intended to replace NSEC or NSEC3. It is designed 177 as an alternative mechanisms for authenticated denial of existence. 179 1.2. Requirements 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 183 document are to be interpreted as described in [RFC2119]. 185 1.3. Terminology 187 The reader is assumed to be familiar with the basic DNS and DNSSEC 188 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], 189 [RFC4035], and subsequent RFCs that update them: [RFC2136], 190 [RFC2181], [RFC2308], and [RFC5155]. 192 The following terminology is used through this document: 194 Base32hex: The "Base 32 Encoding with Extended Hex Alphabet" as 195 specified in [RFC4648]. The padding characters ("=") are not used 196 in NSEC5 specification. 198 Base64: The "Base 64 Encoding" as specified in [RFC4648]. 200 NSEC5 proof: A signed hash of a domain name (hash-and-sign 201 paradigm). A holder of the private key (e.g., authoritative 202 server) can compute the proof. Anyone knowing the public key 203 (e.g., client) can verify it's validity. 205 NSEC5 hash: A cryptographic hash (digest) of an NSEC5 proof. If the 206 NSEC5 proof is known, anyone can compute and verify it's NSEC5 207 hash. 209 NSEC5 algorithm: A pair of algorithms used to compute NSEC5 proofs 210 and NSEC5 hashes. 212 2. Backward Compatibility 214 The specification describes a protocol change that is not backward 215 compatible with [RFC4035] and [RFC5155]. NSEC5-unaware resolver will 216 fail to validate responses introduced by this document. 218 To prevent NSEC5-unaware resolvers from attempting to validate the 219 responses, new DNSSEC algorithms identifiers are introduced, the 220 identifiers alias with existing algorithm numbers. The zones signed 221 according to this specification MUST use only these algorithm 222 identifiers, thus NSEC5-unaware resolvers will treat the zone as 223 insecure. 225 The new algorithm identifiers defined by this document are listed in 226 Section 15. 228 3. How NSEC5 Works 230 To prove non-existence of a domain name in a zone, NSEC uses a chain 231 built from domain names present in the zone. NSEC3 replaces the 232 original domain names by their cryptographic hashes. NSEC5 is very 233 similar to NSEC3, however a public-key based hashing scheme is used. 235 In NSEC5, the original domain name is hashed twice: 237 1. First, the domain name is hashed using the NSEC5 private key; the 238 result is called the NSEC5 proof. Only an authoritative server 239 that knows the private NSEC5 key can compute the NSEC5 proof. 240 Any client that knows the public NSEC5 key can validate the NSEC5 241 proof. 243 2. Second, the NSEC5 proof is hashed using a cryptographic hash 244 function; the result is called the NSEC5 hash. This hash can be 245 computed by any party that knows the input NSEC5 proof. 247 The NSEC5 hash determines the position of a domain name in an NSEC5 248 chain. That is, all the NSEC5 hashes for a zone are sorted in their 249 canonical order, and each consecutive pair forms an NSEC5 RR. 251 To prove an non-existence of a particular domain name in response to 252 a query, the server computes on the fly, the NSEC5 proof (using the 253 private NSEC5 key). Then it uses the NSEC5 proof to compute the 254 corresponding NSEC5 hash. It then identifies the NSEC5 RR that 255 covers the hash. In the response message, the server returns the 256 NSEC5 RR, it's corresponding signature (RRSIG RRset), and synthesized 257 NSEC5PROOF RR containing the NSEC5 proof it computed on the fly. 259 To validate the response, the client first uses the public NSEC5 key 260 (stored in the zone as an NSEC5KEY RR) to verify that the NSEC5 proof 261 corresponds with the domain name to be disproved. Then, the client 262 computes the NSEC5 hash from the NSEC5 proof and checks if the NSEC5 263 RR content and it's signature are valid. 265 4. NSEC5 Algorithms 267 The algorithms used for NSEC5 authenticated denial are independent on 268 the algorithms used for DNSSEC signing. An NSEC5 algorithm defines 269 how the NSEC5 proof and the NSEC5 hash is computed and validated. 271 The input for the NSEC5 proof computation is an RR owner name in the 272 canonical form in the wire format and an NSEC5 private key; the 273 output is an octet string. 275 The input for the NSEC5 hash computation is the corresponding NSEC5 276 proof; the output is an octet string. 278 This document defines FDH-SHA256-SHA256 NSEC5 algorithm as follows: 280 o NSEC5 proof is an RSA based Full Domain Hash (FDH) with SHA-256 281 hash function used internally for input preprocessing. The FDH 282 signature and verification is formally specified in Appendix A. 284 o NSEC5 hash is an SHA-256 hash function as specified in [RFC6234]. 286 o The public key format to be used in NSEC5KEY RR is defined in 287 Section 2 of [RFC3110] and thus is the same as the format used to 288 store RSA public keys in DNSKEY RRs. 290 The NSEC5 algorithm identifier for FDH-SHA256-SHA256 is 1. 292 5. The NSEC5KEY Resource Record 294 The NSEC5KEY RR stores an NSEC5 public key. The key allows clients 295 to verify a validity of NSEC5 proof sent by a server. 297 5.1. NSEC5KEY RDATA Wire Format 299 The RDATA for NSEC5KEY RR is as shown below: 301 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Algorithm | Public Key / 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Algorithm is a single octet identifying NSEC5 algorithm. 309 Public Key is a variable sized field holding public key material for 310 NSEC5 proof verification. 312 5.2. NSEC5KEY RDATA Presentation Format 314 The presentation format of the NSEC5KEY RDATA is as follows: 316 The Algorithm field is represented as an unsigned decimal integer. 318 The Public Key field is represented in Base64 encoding. Whitespace 319 is allowed within the Base64 text. 321 6. The NSEC5 Resource Record 323 The NSEC5 RR provides authenticated denial of existence for an RRset. 324 One NSEC5 RR represents one piece of an NSEC5 chain, proving 325 existence of RR types present at the original domain name and also 326 non-existence of other domain names in a part of the hashed domain 327 name space. 329 6.1. NSEC5 RDATA Wire Format 331 The RDATA for NSEC5 RR is as shown below: 333 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Key Tag | Flags | Next Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Next Hashed Owner Name / 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 / Type Bit Maps / 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Key Tag field contains the key tag value of the NSEC5KEY RR that 344 validates the NSEC5 RR, in network byte order. The value is computed 345 from the NSEC5KEY RDATA using the same algorithm, which is used to 346 compute key tag values for DNSKEY RRs. The algorithm is defined in 347 [RFC4034]. 349 Flags field is a single octet. The meaning of individual bits of the 350 field is defined in Section 6.2. 352 Next length is an unsigned single octet specifying the length of the 353 Next Hashed Owner Name field in octets. 355 Next Hashed Owner Name field is a sequence of binary octets. It 356 contains an NSEC5 hash of the next domain name in the NSEC5 chain. 358 Type Bit Maps is a variable sized field encoding RR types present at 359 the original owner name matching the NSEC5 RR. The format of the 360 field is equivalent to the format used in NSEC3 RR, described in 361 [RFC5155]. 363 6.2. NSEC5 Flags Field 365 The following one-bit NSEC5 flags are defined: 367 0 1 2 3 4 5 6 7 368 +-+-+-+-+-+-+-+-+ 369 | |W|O| 370 +-+-+-+-+-+-+-+-+ 372 O - Opt-Out flag 374 W - Wildcard flag 376 All the other flags are reserved for future use and MUST be zero. 378 The Opt-Out flag has the same semantics as in NSEC3. The definition 379 and considerations in [RFC5155] are valid, except that NSEC3 is 380 replaced by NSEC5. 382 The Wildcard flag indicates that a wildcard synthesis is possible at 383 the original domain name level (i.e., there is a wildcard node 384 immediately descending from the immediate ancestor of the original 385 domain name). The purpose of the Wildcard flag is to reduce a 386 maximum number of RRs required for authenticated denial of existence 387 proof. 389 6.3. NSEC5 RDATA Presentation Format 391 The presentation format of the NSEC5 RDATA is as follows: 393 The Key Tag field is represented as an unsigned decimal integer. 395 The Flags field is represented as an unsigned decimal integer. 397 The Next Length field is not represented. 399 The Next Hashed Owner Name field is represented as a sequence of 400 case-insensitive Base32hex digits without any whitespace and without 401 padding. 403 The Type Bit Maps representation is equivalent to the representation 404 used in NSEC3 RR, described in [RFC5155]. 406 7. The NSEC5PROOF Resource Record 408 The NSEC5PROOF record is synthesized by the authoritative server on- 409 the-fly. The record contains the NSEC5 proof, proving a position of 410 the owner name in an NSEC5 chain. 412 7.1. NSEC5PROOF RDATA Wire Format 414 The RDATA for NSEC5PROOF is as as shown below: 416 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Key Tag | Owner Name Hash / 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Key Tag field contains the key tag value of the NSEC5KEY RR that 423 validates the NSEC5PROOF RR, in network byte order. 425 Owner Name Hash is a variable sized sequence of binary octets 426 encoding the NSEC5 proof of the owner name of the RR. 428 7.2. NSEC5PROOF RDATA Presentation Format 430 The presentation format of the NSEC5PROOF RDATA is as follows: 432 The Key Tag field is represented as an unsigned decimal integer. 434 The Owner Name Hash is represented in Base64 encoding. Whitespace is 435 allowed within the Base64 text. 437 8. NSEC5 Proofs 439 This section summarizes all possible types of authenticated denial of 440 existence. For each type the following lists are included: 442 1. Facts to prove. The minimum amount of information an 443 authoritative server must provide to a client to assure the 444 client that the response content is valid. 446 2. Authoritative server proofs. NSEC5 RRs an authoritative server 447 must include in a response to prove the listed facts. 449 3. Validator checks. Individual checks a validating server is 450 required to perform on a response. The response content is 451 considered valid only if all the checks pass. 453 If NSEC5 is said to match a domain name, the owner name of the NSEC5 454 has to be equivalent to an NSEC5 hash of that domain name. If NSEC5 455 is said to cover a domain name, the NSEC5 hash of that name must lay 456 strictly between the NSEC5 owner name and the NSEC5 Next Hashed Owner 457 Name. 459 8.1. Name Error Responses 461 Facts to prove: 463 No RRset matching the QNAME exactly exists. 465 No RRset matching the QNAME via wildcard expansion exists. 467 The QNAME does not fall into a delegation. 469 The QNAME does not fall into a DNAME redirection. 471 Authoritative server proofs: 473 Closest encloser. 475 Next closer name. 477 Validator checks: 479 Closest encloser belongs to the zone. 481 Closest encloser has the Wildcard flag cleared. 483 Closest encloser does not have NS without SOA in the Type Bit Map. 485 Closest encloser does not have DNAME in the Type Bit Maps. 487 Next closer name is derived correctly. 489 8.2. No Data Responses 491 The processing of a No Data response for DS QTYPE differs if the Opt- 492 Out is in effect. For DS QTYPE queries, the validator has two 493 possible checking paths. The correct path can be simply decided by 494 inspecting if the NSEC5 RR in the response matches the QNAME. 496 Note that the Opt-Out is valid only for DS QTYPE queries. 498 8.2.1. No Data Response, Opt-Out Not In Effect 500 Facts to prove: 502 An RRset matching the QNAME exists. 504 No QTYPE RRset matching the QNAME exists. 506 No CNAME RRset matching the QNAME exists. 508 Authoritative server proofs: 510 QNAME. 512 Validator checks: 514 The NSEC5 RR exactly matches the QNAME. 516 The NSEC5 RR does not have QTYPE in the Type Bit Map. 518 The NSEC5 RR does not have CNAME in the Type Bit Map. 520 8.2.2. No Data Response, Opt-Out In Effect 522 Facts to prove: 524 The delegation is not covered by the NSEC5 chain. 526 Authoritative server proofs: 528 Closest provable encloser. 530 Validator checks: 532 Closest provable encloser is in zone. 534 Closest provable encloser covers (not matches) the QNAME. 536 Closest provable encloser has the Opt-Out flag set. 538 8.3. Wildcard Responses 540 Facts to prove: 542 No RRset matching the QNAME exactly exists. 544 No wildcard closer to the QNAME exists. 546 Authoritative server proofs: 548 Next closer name. 550 Validator checks: 552 Next closer name is derived correctly. 554 Next closer name covers (not matches). 556 8.4. Wildcard No Data Responses 558 Facts to prove: 560 No RRset matching the QNAME exactly exists. 562 No QTYPE RRset exists at the wildcard matching the QNAME. 564 No CNAME RRset exists at the wildcard matching the QNAME. 566 No wildcard closer to the QNAME exists. 568 Authoritative server proofs: 570 Source of synthesis (i.e., wildcard at closest encloser). 572 Next closer name. 574 Validator checks: 576 Source of synthesis matches exactly the QNAME. 578 Source of synthesis does not have QTYPE in the Type Bit Map. 580 Source of synthesis does not have CNAME in the Type Bit Map. 582 Next closer name is derived correctly. 584 Next closer name covers (not matches). 586 9. Authoritative Server Considerations 588 9.1. Zone Signing 590 Zones using NSEC5 MUST satisfy the same properties as described in 591 Section 7.1 of [RFC5155], with NSEC3 replaced by NSEC5. In addition, 592 the following conditions MUST be satisfied as well: 594 o If the original owner name has a wildcard label immediately 595 descending from the original owner name, the corresponding NSEC5 596 RR MUST have the Wildcard flag set in the Flags field. Otherwise, 597 the flag MUST be cleared. 599 o The zone apex MUST include an NSEC5KEY RRset containing a NSEC5 600 public key allowing verification of the current NSEC5 chain. 602 The following steps describe one possible method to properly add 603 required NSEC5 related records into a zone. This is not the only 604 such existing method. 606 1. Select an algorithm for NSEC5. Generate the public and private 607 NSEC5 keys. 609 2. Add a NSEC5KEY RR into the zone apex containing the public NSEC5 610 key. 612 3. For each unique original domain name in the zone and each empty 613 non-terminal, add an NSEC5 RR. If Opt-Out is used, owner names 614 of unsigned delegations MAY be excluded. 616 a. The owner name of the NSEC5 RR is the NSEC5 hash of the 617 original owner name encoded in Base32hex without padding, 618 prepended as a single label to the zone name. 620 b. Set the Key Tag field to be the key tag corresponding to the 621 public NSEC5 key. 623 c. Clear the Flags field. If Opt-Out is being used, set the 624 Opt-Out flag. If there is a wildcard label directly 625 descending from the original domain name, set the Wildcard 626 flag. Note that the wildcard can be an empty non-terminal 627 (i.e., the wildcard synthesis does not take effect and 628 therefore the flag is not to be set). 630 d. Set the Next Length field to a value determined by the used 631 NSEC5 algorithm. Leave the Next Hashed Owner Name field 632 blank. 634 e. Set the Type Bit Maps field based on the RRsets present at 635 the original owner name. 637 4. Sort the set of NSEC5 RRs into canonical order. 639 5. For each NSEC5 RR, set the Next Hashed Owner Name field by using 640 the owner name of the next NSEC5 RR in the canonical order. If 641 the updated NSEC5 is the last NSEC5 RR in the chain, the owner 642 name of the first NSEC5 RR in the chain is used instead. 644 The NSEC5KEY and NSEC5 RRs MUST have the same class as the zone SOA 645 RR. Also the NSEC5 RRs SHOULD have the same TTL value as the SOA 646 minimum TTL field. 648 Notice that a use of Opt-Out is not indicated in the zone. This does 649 not affect the ability of a server to prove insecure delegations. 650 The Opt-Out MAY be part of the zone-signing tool configuration. 652 9.2. Zone Serving 654 This specification modifies DNSSEC-enabled DNS responses generated by 655 authoritative servers. In particular, it replaces use of NSEC or 656 NSEC3 RRs in such responses with NSEC5 RRs and adds on-the-fly 657 computed NSEC5PROOF RRs. 659 The authenticated denial of existence proofs in NSEC5 are almost the 660 same as in NSEC3. However, due to introduction of Wildcard flag in 661 NSEC5 RRs, the NSEC5 proof consists from (up to) two NSEC5 RRs, 662 instead of (up to) three. 664 According to a type of a response, an authoritative server MUST 665 include NSEC5 RRs in a response as defined in Section 8. For each 666 NSEC5 RR in the response a matching RRSIG RRset and a synthesized 667 NSEC5PROOF MUST be added as well. 669 A synthesized NSEC5PROOF RR has the owner name set to a domain name 670 exactly matching the name required for the proof. The class and TTL 671 of the RR MUST be the same as the class and TTL value of the 672 corresponding NSEC5 RR. The RDATA are set according to the 673 description in Section 7.1. 675 Notice, that the NSEC5PROOF owner name can be a wildcard (e.g., 676 source of synthesis proof in wildcard No Data responses). The name 677 also always matches the domain name required for the proof while the 678 NSEC5 RR may only cover (not match) the name in the proof (e.g., 679 closest encloser in Name Error responses). 681 If NSEC5 is used, an answering server MUST use exactly one NSEC5 682 chain for one signed zone. 684 NSEC5 MUST NOT be used in parallel with NSEC, NSEC3, or any other 685 authenticated denial of existence mechanism that allows for 686 enumeration of zone contents. 688 Similarly to NSEC3, the owner names of NSEC5 RRs are not represented 689 in the NSEC5 chain and therefore NSEC5 records deny their own 690 existence. The desired behavior caused by this paradox is the same 691 as described in Section 7.2.8 of [RFC5155]. 693 9.3. NSEC5KEY Rollover Mechanism 695 Replacement of the NSEC5 key implies generating a new NSEC5 chain. 696 The NSEC5KEY rollover mechanism is similar to "Pre-Publish Zone 697 Signing Key Rollover" as specified in [RFC6781]. The NSEC5KEY 698 rollover MUST be performed as a sequence of the following steps: 700 1. A new public NSEC5 key is added into the NSEC5KEY RRset in the 701 zone apex. 703 2. The old NSEC5 chain is replaced by a new NSEC5 chain constructed 704 using the new key. This replacement MUST happen as a single 705 atomic operation; the server MUST NOT be responding with RRs from 706 both the new and old chain at the same time. 708 3. The old public key is removed from the NSEC5KEY RRset in the zone 709 apex. 711 The minimal delay between the steps 1. and 2. MUST be the time it 712 takes for the data to propagate to the authoritative servers, plus 713 the TTL value of the old NSEC5KEY RRset. 715 The minimal delay between the steps 2. and 3. MUST be the time it 716 takes for the data to propagate to the authoritative servers, plus 717 the maximum zone TTL value of any of the data in the previous version 718 of the zone. 720 9.4. Secondary Servers 721 This document does not define mechanism to distribute NSEC5 private 722 keys. 724 9.5. Zones Using Unknown Hash Algorithms 726 Zones that are signed with unknown NSEC5 algorithm or by an 727 unavailable NSEC5 private key cannot be effectively served. Such 728 zones SHOULD be rejected when loading and servers SHOULD respond with 729 RCODE=2 (Server failure) when handling queries that would fall under 730 such zones. 732 9.6. Dynamic Updates 734 A zone signed using NSEC5 MAY accept dynamic updates. The changes to 735 the zone MUST be performed in a way, that the zone satisfies the 736 properties specified in Section 9.1 at any time. 738 It is RECOMMENDED that the server rejects all updates containing 739 changes to the NSEC5 chain (or related RRSIG RRs) and performs itself 740 any required alternations of the NSEC5 chain induced by the update. 742 Alternatively, the server MUST verify that all the properties are 743 satisfied prior to performing the update atomically. 745 10. Resolver Considerations 747 The same considerations as described in Section 9 of [RFC5155] for 748 NSEC3 apply to NSEC5. In addition, as NSEC5 RRs can be validated 749 only with appropriate NSEC5PROOF RRs, the NSEC5PROOF RRs MUST be all 750 together cached and included in responses with NSEC5 RRs. 752 11. Validator Considerations 754 11.1. Validating Responses 756 The validator MUST ignore NSEC5 RRs with Flags field values other 757 than the ones defined in Section 6.2. 759 The validator MAY treat responses as bogus if the response contains 760 NSEC5 RRs that refer to a different NSEC5KEY. 762 According to a type of a response, the validator MUST verify all 763 conditions defined in Section 8. Prior to making decision based on 764 the content of NSEC5 RRs in a response, the NSEC5 RRs MUST be 765 validated. 767 To validate a denial of existence, zone NSEC5 public keys are 768 required in addition to DNSSEC public keys. Similarly to DNSKEY RRs, 769 the NSEC5KEY RRs are present in the zone apex. 771 The NSEC5 RR is validated as follows: 773 1. Select a correct NSEC5 public key to validate the NSEC5PROOF. 774 The Key Tag value of the NSEC5PROOF RR must match with the key 775 tag value computed from the NSEC5KEY RDATA. 777 2. Validate the NSEC5 proof present in the NSEC5PROOF Owner Name 778 Hash field using the NSEC5 public key. If there are multiple 779 NSEC5KEY RRs matching the key tag, at least one of the keys must 780 validate the NSEC5 proof. 782 3. Compute the NSEC5 hash value from the NSEC5 proof and check if 783 the response contains NSEC5 RR matching or covering the computed 784 NSEC5 hash. The TTL values of the NSEC5 and NSEC5PROOF RRs must 785 be the same. 787 4. Validate the signature of the NSEC5 RR. 789 If the NSEC5 RR fails to validate, it MUST be ignored. If some of 790 the conditions required for an NSEC5 proof is not satisfied, the 791 response MUST be treated as bogus. 793 Notice that determining closest encloser and next closer name in 794 NSEC5 is easier than in NSEC3. NSEC5 and NSEC5PROOF RRs are always 795 present in pairs in responses and the original owner name of the 796 NSEC5 RR matches the owner name of the NSEC5PROOF RR. 798 11.2. Validating Referrals to Unsigned Subzones 800 The same considerations as defined in Section 8.9 of [RFC5155] for 801 NSEC3 apply to NSEC5. 803 11.3. Responses With Unknown Hash Algorithms 805 A validator MUST ignore NSEC5KEY RRs with unknown NSEC5 algorithms. 806 The practical result of this is that zones sighed with unknown 807 algorithms will be considered bogus. 809 12. Special Considerations 811 12.1. Transition Mechanism 813 TODO: Not finished. Following information will be covered: 815 o Transition from NSEC or NSEC3. 817 o Transition from NSEC5 to NSEC/NSEC3 819 o Transition to new algorithms within NSEC5 821 Quick notes on transition from NSEC/NSEC3 to NSEC5: 823 1. Publish NSEC5KEY RR. 825 2. Wait for data propagation to slaves and cache expiration. 827 3. Instantly switch answering from NSEC/NSEC3 to NSEC5. 829 Quick notes on transition from NSEC5 to NSEC/NSEC3: 831 1. Instantly switch answering from NSEC5 to NSEC/NSEC3. 833 2. Wait for NSEC5 RRs expiration in caches. 835 3. Remove NSEC5KEY RR from the zone. 837 12.2. NSEC5 Private Keys 839 This document does not define format to store NSEC5 private key. Use 840 of standardized and adopted format is RECOMMENDED. 842 The NSEC5 private key MAY be shared between multiple zones, however a 843 separate key is RECOMMENDED for each zone. 845 12.3. Domain Name Length Restrictions 847 The NSEC5 creates additional restrictions on domain name lengths. In 848 particular, zones with names that, when converted into hashed owner 849 names exceed the 255 octet length limit imposed by [RFC1035], cannot 850 use this specification. 852 The actual maximum length of a domain name depends on the length of 853 the zone name and used NSEC5 algorithm. 855 With FDH-SHA256-SHA256 defined in this document, the SHA-256 hash 856 function is used to construct NSEC5 hash values. SHA-256 produces a 857 hash of 256 bits, which can be encoded in 52 characters in Base32hex 858 without padding. The encoded string is prepended to the name of the 859 zone as a single label, which includes the length field of a single 860 octet. The maximal length of the zone name is therefore 202 octets 861 (255 - 53). 863 13. Performance Considerations 865 TODO: Not finished. Following information will be covered: 867 o Size of the answers 869 o NSEC5 FDH-SHA256-SHA256 vs NSEC3 SHA1 871 o NSEC5 closest encloser name in NSEC5PROOF owner name vs NSEC5 SHA1 872 hashing 874 o Total number of crypto operations on server/client side 876 14. Security Considerations 878 14.1. Zone Enumeration Attacks 880 NSEC5 is robust to zone enumeration via offline dictionary attacks by 881 any attacker that does not know the NSEC5 private key. Without the 882 private NSEC5 key, that attacker cannot compute the NSEC5 proof that 883 corresponds to a given name; the only way it can learn the NSEC5 884 proof value for a given name is by sending a queries for that name to 885 the authoritative server. Without the NSEC5 proof value, the 886 attacker cannot learn the NSEC5 hash value. Thus, even an attacker 887 that collects the entire chain of NSEC5 RR for a zone cannot use 888 offline attacks to "reverse" that NSEC5 hash values in these NSEC5 RR 889 and thus learn which names are present in the zone. A formal 890 cryptographic proof of this property is in [nsec5]. 892 14.2. Hash Collisions 894 Hash collisions between QNAME and the owner name of an NSEC5 RR may 895 occur. When they do, it will be impossible to prove the non- 896 existence of the colliding QNAME. However, with SHA-256, this is 897 highly unlikely (on the order of 1 in 2^128). Note that DNSSEC 898 already relies on the presumption that a cryptographic hash function 899 is collision resistant, since these hash functions are used for 900 generating and validating signatures and DS RRs. See also the 901 discussion on key lengths in [nsec5]. 903 14.3. Compromise of the Private NSEC5 Key 905 NSEC5 requires authoritative servers to hold the private NSEC5 key, 906 but not the private zone-signing keys or the private key-signing keys 907 for the zone. The private NSEC5 key needs only be as secure as the 908 DNSSEC records whose the privacy (against zone-enumeration attacks) 909 that NSEC5 is protecting. This is because even an adversary that 910 knows the private NSEC5 key cannot modify the contents of the zone; 911 this is because the zone contents are signed using the private zone- 912 signing key, while the private NSEC5 key is only used to compute 913 NSEC5 proof values. Thus, a compromise of the private NSEC5 keys 914 does not lead to a compromise of the integrity of the DNSSEC record 915 in the zone; instead, all that is lost is privacy against zone 916 enumeration, if the attacker that knows the private NSEC5 key can 917 compute NSEC5 hashes offline, and thus launch offline dictionary 918 attacks. Thus, a compromise of the private NSEC5 key effectively 919 downgrades the security of NSEC5 to that of NSEC3. A formal 920 cryptographic proof of this property is in [nsec5]. 922 14.4. Key Length Considerations 924 The NSEC5 key must be long enough to withstand attacks for as long as 925 the privacy of the zone is important. Even if the NSEC5 key is 926 rolled frequently, its length cannot be too short, because zone 927 privacy may be important for a period of time longer than the 928 lifetime of the key. (For example, an attacker might collect the 929 entire chain of NSEC5 RR for the zone over one short period, and 930 then, later (even after the NSEC5 key expires) perform an offline 931 dictionary attack that attempt to "reverse" the NSEC5 hash values 932 present in the NSEC5 RRs.) This is in contrast to zone-signing and 933 key-signing keys used in DNSSEC; these keys, which ensure the 934 authenticity and integrity of the zone contents need to remain secure 935 only during their lifetime. 937 14.5. Transitioning to a New NSEC5 Algorithm 939 Although the NSEC5KEY RR formats include a hash algorithm parameter, 940 this document does not define a particular mechanism for safely 941 transitioning from one NSEC5 algorithm to another. When specifying a 942 new hash algorithm for use with NSEC5, a transition mechanism MUST 943 also be defined. It is possible that the only practical and 944 palatable transition mechanisms may require an intermediate 945 transition to an insecure state, or to a state that uses NSEC or 946 NSEC3 records instead of NSEC5. 948 15. IANA Considerations 950 This document updates the IANA registry "Domain Name System (DNS) 951 Parameters" in subregistry "Resource Record (RR) TYPEs", by defining 952 the following new RR types: 954 NSEC5KEY value XXX. 956 NSEC5 value XXX. 958 NSEC5PROOF value XXX. 960 This document creates a new IANA registry for NSEC5 algorithms. This 961 registry is named "DNSSEC NSEC5 Algorithms". The initial content of 962 the registry is: 964 0 is Reserved. 966 1 is FDH-SHA256-SHA256. 968 2-255 is Available for assignment. 970 This document updates the IANA registry "DNS Security Algorithm 971 Numbers" by defining following aliases: 973 XXX is NSEC5-RSASHA256, alias for RSASHA256 (8). 975 XXX is NSEC5-RSASHA512, alias for RSASHA512 (10). 977 XXX is NSEC5-ECDSAP256SHA256 alias for ECDSAP256SHA256 (13). 979 XXX is NSEC5-ECDSAP384SHA384 alias for ECDSAP384SHA384 (14). 981 16. Contributors 983 This document would not be possible without help of Moni Naor 984 (Weizmann Institute), Dimitrios Papadopoulos (Boston University), 985 Sachin Vasant (Cisco Systems), Leonid Reyzin (Boston University), and 986 Asaf Ziv (Weizmann Institute) who contributed to the design of NSEC5, 987 and Ondrej Sury (CZ.NIC Labs) who provided advice on its 988 implementation. 990 17. References 992 17.1. Normative References 994 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 995 STD 13, RFC 1034, November 1987. 997 [RFC1035] Mockapetris, P., "Domain names - implementation and 998 specification", STD 13, RFC 1035, November 1987. 1000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1001 Requirement Levels", BCP 14, RFC 2119, March 1997. 1003 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 1004 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1005 RFC 2136, April 1997. 1007 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 1008 Specification", RFC 2181, July 1997. 1010 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 1011 NCACHE)", RFC 2308, March 1998. 1013 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 1014 Name System (DNS)", RFC 3110, May 2001. 1016 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1017 Standards (PKCS) #1: RSA Cryptography Specifications 1018 Version 2.1", RFC 3447, February 2003. 1020 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1021 Rose, "DNS Security Introduction and Requirements", RFC 1022 4033, March 2005. 1024 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1025 Rose, "Resource Records for the DNS Security Extensions", 1026 RFC 4034, March 2005. 1028 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1029 Rose, "Protocol Modifications for the DNS Security 1030 Extensions", RFC 4035, March 2005. 1032 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1033 Encodings", RFC 4648, October 2006. 1035 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 1036 Security (DNSSEC) Hashed Authenticated Denial of 1037 Existence", RFC 5155, March 2008. 1039 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 1040 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 1042 17.2. Informative References 1044 [nsec5] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., 1045 Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC 1046 Zone Enumeration", July 2014. 1048 [nsec3gpu] 1049 Wander, M., Schwittmann, L., Boelmann, C., and T. Weis, 1050 "GPU-Based NSEC3 Hash Breaking", in IEEE Symp. Network 1051 Computing and Applications (NCA), 2014. 1053 [nsec3walker] 1054 Bernstein, D., "Nsec3 walker", 2011, 1055 . 1057 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 1058 Operational Practices, Version 2", RFC 6781, December 1059 2012. 1061 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 1062 Existence in the DNS", RFC 7129, February 2014. 1064 Appendix A. Full Domain Hash Algorithm 1066 The Full Domain Hash (FDH) is a RSA-based scheme that allows 1067 authentication of hashes using public-key cryptography. 1069 In this document, the notation from [RFC3447] is used. 1071 Used parameters: 1073 (n, e) - RSA public key 1075 K - RSA private key 1077 k - length of the RSA modulus n in octets 1079 Fixed options: 1081 Hash - hash function to be used with MGF1 1083 Used primitives: 1085 I2OSP - Coversion of a nonnegative integer to an octet string as 1086 defined in Section 4.1 of [RFC3447] 1088 OS2IP - Coversion of an octet string to a nonnegative integer as 1089 defined in Section 4.2 of [RFC3447] 1091 RSASP1 - RSA signature primitive as defined in Section 5.2.1 of 1092 [RFC3447] 1094 RSAVP1 - RSA verification primitive as defined in Section 5.2.2 of 1095 [RFC3447] 1097 MGF1 - Mask Generation Function based on a hash function as 1098 defined in Section B.2.1 of [RFC3447] 1100 A.1. FDH signature 1101 FDH_SIGN(K, M) 1103 Input: 1105 K - RSA private key 1107 M - message to be signed, an octet string 1109 Output: 1111 S - signature, an octet string of length k 1113 Steps: 1115 1. EM = MGF1(M, k - 1) 1117 2. m = OS2IP(EM) 1119 3. s = RSASP1(K, m) 1121 4. S = I2OSP(s, k) 1123 5. Output S 1125 A.2. FDH verification 1127 FDH_VERIFY((n, e), M, S) 1129 Input: 1131 (n, e) - RSA public key 1133 M - message whose signature is to be verified, an octet string 1135 S - signature to be verified, an octet string of length k 1137 Output: 1139 "valid signature" or "invalid signature" 1141 Steps: 1143 1. s = OS2IP(S) 1145 2. m = RSAVP1((n, e), s) 1147 3. EM = I2OSP(m, k - 1) 1148 4. EM' = MGF1(M, k - 1) 1150 5. If EM and EM' are the same, output "valid signature"; else output 1151 "invalid signature". 1153 Appendix B. Change Log 1155 Note to RFC Editor: if this document does not obsolete an existing 1156 RFC, please remove this appendix before publication as an RFC. 1158 pre 00 - initial version of the document submitted to mailing list 1159 only 1161 00 - fix NSEC5KEY rollover mechanism, clarify NSEC5PROOF RDATA, 1162 clarify inputs and outputs for NSEC5 proof and NSEC5 hash 1163 computation 1165 Appendix C. Open Issues 1167 Note to RFC Editor: please remove this appendix before publication as 1168 an RFC. 1170 1. Consider alternative way to signalize NSEC5 support. The NSEC5 1171 could use only one DNSSEC algorithm identifier, and the actual 1172 algorithm to be used for signing can be the first byte in DNSKEY 1173 public key field and RRSIG signature field. Similar approach is 1174 used by PRIVATEDNS and PRIVATEOID defined in [RFC4034]. 1176 2. How to add new NSEC5 hashing algorithm. We will need to add new 1177 DNSSEC algorithm identifiers again. 1179 3. NSEC and NSEC3 define optional steps for hash collisions 1180 detection. We don't have a way to avoid them if they really 1181 appear (unlikely). We would have to drop the signing key and 1182 generate a new one. Which cannot be done instantly. 1184 4. Write Special Considerations section. 1186 5. Write Performance Considerations section. 1188 6. Contributor list has to be completed. 1190 Authors' Addresses 1191 Jan Vcelak 1192 CZ.NIC 1193 Milesovska 1136/5 1194 Praha 130 00 1195 CZ 1197 EMail: jan.vcelak@nic.cz 1199 Sharon Goldberg 1200 Boston University 1201 111 Cummington St, MCS135 1202 Boston, MA 02215 1203 USA 1205 EMail: goldbe@cs.bu.edu