idnits 2.17.00 (12 Aug 2021) /tmp/idnits2311/draft-ietf-dnsext-dnssec-bis-updates-18.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4034, but the abstract doesn't seem to directly say this. It does mention RFC4034 though, so this could be OK. -- The draft header indicates that this document updates RFC5155, but the abstract doesn't seem to directly say this. It does mention RFC5155 though, so this could be OK. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to directly say this. It does mention RFC4035 though, so this could be OK. -- The draft header indicates that this document updates RFC4033, but the abstract doesn't seem to directly say this. It does mention RFC4033 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4033, updated by this document, for RFC5378 checks: 2001-07-13) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 30, 2012) is 3672 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 informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 4641 (Obsoleted by RFC 6781) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Weiler 3 Internet-Draft SPARTA, Inc. 4 Updates: 4033, 4034, 4035, 5155 D. Blacka 5 (if approved) Verisign, Inc. 6 Intended status: Standards Track April 30, 2012 7 Expires: November 1, 2012 9 Clarifications and Implementation Notes for DNSSECbis 10 draft-ietf-dnsext-dnssec-bis-updates-18 12 Abstract 14 This document is a collection of technical clarifications to the 15 DNSSECbis document set. It is meant to serve as a resource to 16 implementors as well as a repository of DNSSECbis errata. 18 This document updates the core DNSSECbis documents (RFC4033, RFC4034, 19 and RFC4035) as well as the NSEC3 specification (RFC5155). It also 20 defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 1, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4 69 1.1. Structure of this Document . . . . . . . . . . . . . . . . 4 70 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 4 72 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2. SHA-2 Support . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Scaling Concerns . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Implement a BAD cache . . . . . . . . . . . . . . . . . . 5 76 4. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 5 78 4.2. Validating Responses to an ANY Query . . . . . . . . . . . 6 79 4.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 6 80 4.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 6 81 5. Interoperability Concerns . . . . . . . . . . . . . . . . . . 7 82 5.1. Errors in Canonical Form Type Code List . . . . . . . . . 7 83 5.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 7 84 5.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 8 85 5.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 8 86 5.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 9 87 5.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 9 88 5.7. Setting the AD Bit on Queries . . . . . . . . . . . . . . 9 89 5.8. Setting the AD Bit on Replies . . . . . . . . . . . . . . 9 90 5.9. Always set the CD bit on Queries . . . . . . . . . . . . . 10 91 5.10. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 10 92 5.11. Mandatory Algorithm Rules . . . . . . . . . . . . . . . . 11 93 5.12. Ignore Extra Signatures From Unknown Keys . . . . . . . . 11 94 6. Minor Corrections and Clarifications . . . . . . . . . . . . . 12 95 6.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 12 96 6.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 12 97 6.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 12 98 6.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 13 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 101 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 103 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 104 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 105 Appendix B. Discussion of Setting the CD Bit . . . . . . . . . . 15 106 Appendix C. Discussion of Trust Anchor Preference Options . . . . 18 107 C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 18 108 C.2. Accept Any Success . . . . . . . . . . . . . . . . . . . . 19 109 C.3. Preference Based on Source . . . . . . . . . . . . . . . . 19 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 112 1. Introduction and Terminology 114 This document lists some additions, clarifications and corrections to 115 the core DNSSECbis specification, as originally described in 116 [RFC4033], [RFC4034], and [RFC4035], and later amended by [RFC5155]. 117 (See section Section 2 for more recent additions to that core 118 document set.) 120 It is intended to serve as a resource for implementors and as a 121 repository of items that need to be addressed when advancing the 122 DNSSECbis documents from Proposed Standard to Draft Standard. 124 1.1. Structure of this Document 126 The clarifications and changes to DNSSECbis are sorted according to 127 their importance, starting with ones which could, if ignored, lead to 128 security problems and progressing down to clarifications that are 129 expected to have little operational impact. 131 1.2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 2. Important Additions to DNSSSECbis 140 This section lists some documents that should be considered core 141 DNSSEC protocol documents in addition to those originally specified 142 in Section 10 of [RFC4033]. 144 2.1. NSEC3 Support 146 [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM 147 records for hashed denial of existence. Validator implementations 148 are strongly encouraged to include support for NSEC3 because a number 149 of highly visible zones use it. Validators that do not support 150 validation of responses using NSEC3 will be hampered in validating 151 large portions of the DNS space. 153 [RFC5155] should be considered part of the DNS Security Document 154 Family as described by [RFC4033], Section 10. 156 Note that the algorithm identifiers defined in RFC5155 (DSA-NSEC3- 157 SHA1 and RSASHA1-NSEC3-SHA1) and RFC5702 (RSASHA256 and RSASHA512) 158 signal that a zone MAY be using NSEC3, rather than NSEC. The zone 159 MAY be using either and validators supporting these algorithms MUST 160 support both NSEC3 and NSEC responses. 162 2.2. SHA-2 Support 164 [RFC4509] describes the use of SHA-256 as a digest algorithm in 165 Delegation Signer (DS) RRs. [RFC5702] describes the use of the 166 RSASHA256 and RSASHA512 algorithms in DNSKEY and RRSIG RRs. 167 Validator implementations are strongly encouraged to include support 168 for these algorithms for DS, DNSKEY, and RRSIG records. 170 Both [RFC4509] and [RFC5702] should also be considered part of the 171 DNS Security Document Family as described by [RFC4033], Section 10. 173 3. Scaling Concerns 175 3.1. Implement a BAD cache 177 Section 4.7 of RFC4035 permits security-aware resolvers to implement 178 a BAD cache. Because of scaling concerns not discussed in this 179 document, that guidance has changed: security-aware resolvers SHOULD 180 implement a BAD cache as described in RFC4035. 182 4. Security Concerns 184 This section provides clarifications that, if overlooked, could lead 185 to security issues. 187 4.1. Clarifications on Non-Existence Proofs 189 [RFC4035] Section 5.4 under-specifies the algorithm for checking non- 190 existence proofs. In particular, the algorithm as presented would 191 incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove 192 the non-existence of RRs in the child zone. 194 An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: 196 o the NS bit set, 197 o the SOA bit clear, and 198 o a signer field that is shorter than the owner name of the NSEC RR, 199 or the original owner name for the NSEC3 RR. 201 Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- 202 existence of any RRs below that zone cut, which include all RRs at 203 that (original) owner name other than DS RRs, and all RRs below that 204 owner name regardless of type. 206 Similarly, the algorithm would also allow an NSEC RR at the same 207 owner name as a DNAME RR, or an NSEC3 RR at the same original owner 208 name as a DNAME, to prove the non-existence of names beneath that 209 DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used 210 to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's 211 (original) owner name. 213 4.2. Validating Responses to an ANY Query 215 [RFC4035] does not address how to validate responses when QTYPE=*. 216 As described in Section 6.2.2 of [RFC1034], a proper response to 217 QTYPE=* may include a subset of the RRsets at a given name. That is, 218 it is not necessary to include all RRsets at the QNAME in the 219 response. 221 When validating a response to QTYPE=*, all received RRsets that match 222 QNAME and QCLASS MUST be validated. If any of those RRsets fail 223 validation, the answer is considered Bogus. If there are no RRsets 224 matching QNAME and QCLASS, that fact MUST be validated according to 225 the rules in [RFC4035] Section 5.4 (as clarified in this document). 226 To be clear, a validator must not expect to receive all records at 227 the QNAME in response to QTYPE=*. 229 4.3. Check for CNAME 231 Section 5 of [RFC4035] says little about validating responses based 232 on (or that should be based on) CNAMEs. When validating a NOERROR/ 233 NODATA response, validators MUST check the CNAME bit in the matching 234 NSEC or NSEC3 RR's type bitmap in addition to the bit for the query 235 type. 237 Without this check, an attacker could successfully transform a 238 positive CNAME response into a NOERROR/NODATA response by (e.g.) 239 simply stripping the CNAME RRset from the response. A naive 240 validator would then note that the QTYPE was not present in the 241 matching NSEC/NSEC3 RR, but fail to notice that the CNAME bit was 242 set, and thus the response should have been a positive CNAME 243 response. 245 4.4. Insecure Delegation Proofs 247 [RFC4035] Section 5.2 specifies that a validator, when proving a 248 delegation is not secure, needs to check for the absence of the DS 249 and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also 250 MUST check for the presence of the NS bit in the matching NSEC (or 251 NSEC3) RR (proving that there is, indeed, a delegation), or 252 alternately make sure that the delegation is covered by an NSEC3 RR 253 with the Opt-Out flag set. 255 Without this check, an attacker could reuse an NSEC or NSEC3 RR 256 matching a non-delegation name to spoof an unsigned delegation at 257 that name. This would claim that an existing signed RRset (or set of 258 signed RRsets) is below an unsigned delegation, thus not signed and 259 vulnerable to further attack. 261 5. Interoperability Concerns 263 5.1. Errors in Canonical Form Type Code List 265 When canonicalizing DNS names (for both ordering and signing), DNS 266 names in the RDATA section of NSEC resource records are not 267 downcased. DNS names in the RDATA section of RRSIG resource records 268 are downcased. 270 The guidance in the above paragraph differs from what has been 271 published before but is consistent with current common practice. 272 [RFC4034] Section 6.2 item 3 says that names in both of these RR 273 types should be downcased. The earlier [RFC3755] says that they 274 should not. Current practice follows neither document fully. 276 Section 6.2 of RFC4034 also erroneously lists HINFO as a record that 277 needs downcasing, and twice at that. Since HINFO records contain no 278 domain names, they are not subject to downcasing. 280 5.2. Unknown DS Message Digest Algorithms 282 Section 5.2 of [RFC4035] includes rules for how to handle delegations 283 to zones that are signed with entirely unsupported public key 284 algorithms, as indicated by the key algorithms shown in those zone's 285 DS RRsets. It does not explicitly address how to handle DS records 286 that use unsupported message digest algorithms. In brief, DS records 287 using unknown or unsupported message digest algorithms MUST be 288 treated the same way as DS records referring to DNSKEY RRs of unknown 289 or unsupported public key algorithms. 291 The existing text says: 293 If the validator does not support any of the algorithms listed in 294 an authenticated DS RRset, then the resolver has no supported 295 authentication path leading from the parent to the child. The 296 resolver should treat this case as it would the case of an 297 authenticated NSEC RRset proving that no DS RRset exists, as 298 described above. 300 In other words, when determining the security status of a zone, a 301 validator disregards any authenticated DS records that specify 302 unknown or unsupported DNSKEY algorithms. If none are left, the zone 303 is treated as if it were unsigned. 305 This document modifies the above text to additionally disregard 306 authenticated DS records using unknown or unsupported message digest 307 algorithms. 309 5.3. Private Algorithms 311 As discussed above, Section 5.2 of [RFC4035] requires that validators 312 make decisions about the security status of zones based on the public 313 key algorithms shown in the DS records for those zones. In the case 314 of private algorithms, as described in [RFC4034] Appendix A.1.1, the 315 eight-bit algorithm field in the DS RR is not conclusive about what 316 algorithm(s) is actually in use. 318 If no private algorithms appear in the DS RRset, or if any supported 319 algorithm appears in the DS RRset, no special processing is needed. 320 Furthermore, if the validator implementation does not support any 321 private algorithms, or only supports private algorithms using an 322 algorithm number not present in the DS RRset, no special processing 323 is needed. 325 In the remaining cases, the security status of the zone depends on 326 whether or not the resolver supports any of the private algorithms in 327 use (provided that these DS records use supported hash functions, as 328 discussed in Section 5.2). In these cases, the resolver MUST 329 retrieve the corresponding DNSKEY for each private algorithm DS 330 record and examine the public key field to determine the algorithm in 331 use. The security-aware resolver MUST ensure that the hash of the 332 DNSKEY RR's owner name and RDATA matches the digest in the DS RR as 333 described in Section 5.2 of [RFC4035], authenticating the DNSKEY. If 334 all of the retrieved and authenticated DNSKEY RRs use unknown or 335 unsupported private algorithms, then the zone is treated as if it 336 were unsigned. 338 Note that if none of the private algorithm DS RRs can be securely 339 matched to DNSKEY RRs and no other DS establishes that the zone is 340 secure, the referral should be considered Bogus data as discussed in 341 [RFC4035]. 343 This clarification facilitates the broader use of private algorithms, 344 as suggested by [RFC4955]. 346 5.4. Caution About Local Policy and Multiple RRSIGs 348 When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 349 suggests that "the local resolver security policy determines whether 350 the resolver also has to test these RRSIG RRs and how to resolve 351 conflicts if these RRSIG RRs lead to differing results." 353 This document specifies that a resolver SHOULD accept any valid RRSIG 354 as sufficient, and only determine that an RRset is Bogus if all 355 RRSIGs fail validation. 357 If a resolver adopts a more restrictive policy, there's a danger that 358 properly-signed data might unnecessarily fail validation due to cache 359 timing issues. Furthermore, certain zone management techniques, like 360 the Double Signature Zone-signing Key Rollover method described in 361 section 4.2.1.2 of [RFC4641], will not work reliably. Such a 362 resolver is also vulnerable to malicious insertion of gibberish 363 signatures. 365 5.5. Key Tag Calculation 367 [RFC4034] Appendix B.1 incorrectly defines the Key Tag field 368 calculation for algorithm 1. It correctly says that the Key Tag is 369 the most significant 16 of the least significant 24 bits of the 370 public key modulus. However, [RFC4034] then goes on to incorrectly 371 say that this is 4th to last and 3rd to last octets of the public key 372 modulus. It is, in fact, the 3rd to last and 2nd to last octets. 374 5.6. Setting the DO Bit on Replies 376 As stated in [RFC3225], the DO bit of the query MUST be copied in the 377 response. However, in order to interoperate with implementations 378 that ignore this rule on sending, resolvers MUST ignore the DO bit in 379 responses. 381 5.7. Setting the AD Bit on Queries 383 The use of the AD bit in the query was previously undefined. This 384 document defines it as a signal indicating that the requester 385 understands and is interested in the value of the AD bit in the 386 response. This allows a requestor to indicate that it understands 387 the AD bit without also requesting DNSSEC data via the DO bit. 389 5.8. Setting the AD Bit on Replies 391 Section 3.2.3 of [RFC4035] describes under which conditions a 392 validating resolver should set or clear the AD bit in a response. In 393 order to interoperate with legacy stub resolvers and middleboxes that 394 neither understand nor ignore the AD bit, validating resolvers SHOULD 395 only set the AD bit when a response both meets the conditions listed 396 in RFC 4035, section 3.2.3, and the request contained either a set DO 397 bit or a set AD bit. 399 5.9. Always set the CD bit on Queries 401 When processing a request with the CD bit set, a resolver SHOULD 402 attempt to return all response data, even data that has failed DNSSEC 403 validation. RFC4035 section 3.2.2 requires a resolver processing a 404 request with the CD bit set to set the CD bit on its upstream 405 queries. 407 This document further specifies that validating resolvers SHOULD set 408 the CD bit on every upstream query. This is regardless of whether 409 the CD bit was set on the incoming query or whether it has a trust 410 anchor at or above the QNAME. 412 [RFC4035] is ambiguous about what to do when a cached response was 413 obtained with the CD bit unset, a case that only arises when the 414 resolver chooses not to set the CD bit on all upstream queries, as 415 specified above. In the typical case, no new query is required, nor 416 does the cache need to track the state of the CD bit used to make a 417 given query. The problem arises when the cached response is a server 418 failure (RCODE 2), which may indicate that the requested data failed 419 DNSSEC validation at an upstream validating resolver. (RFC2308 420 permits caching of server failures for up to five minutes.) In these 421 cases, a new query with the CD bit set is required. 423 Appendix B discusses more of the logic behind the recommendation 424 presented in this section. 426 5.10. Nested Trust Anchors 428 A DNSSEC validator may be configured such that, for a given response, 429 more than one trust anchor could be used to validate the chain of 430 trust to the response zone. For example, imagine a validator 431 configured with trust anchors for "example." and "zone.example." 432 When the validator is asked to validate a response to 433 "www.sub.zone.example.", either trust anchor could apply. 435 When presented with this situation, DNSSEC validators have a choice 436 of which trust anchor(s) to use. Which to use is a matter of 437 implementation choice. Appendix C discusses several possible 438 algorithms. 440 It is possible and advisable to expose the choice of policy as a 441 configuration option. As a default, it is suggested that validators 442 implement the "Accept Any Success" policy described in Appendix C.2 443 while exposing other policies as configuration options. 445 The "Accept Any Success" policy is to try all applicable trust 446 anchors until one gives a validation result of Secure, in which case 447 the final validation result is Secure. If and only if all applicable 448 trust anchors give a result of Insecure, the final validation result 449 is Insecure. If one or more trust anchors lead to a Bogus result and 450 there is no Secure result, then the final validation result is Bogus. 452 5.11. Mandatory Algorithm Rules 454 The last paragraph of RFC4035 Section 2.2 includes rules describing 455 which algorithms must be used to sign a zone. Since these rules have 456 been confusing, they are restated using different language here: 458 The DS RRset and DNSKEY RRset are used to signal which algorithms 459 are used to sign a zone. The presence of an algorithm in either a 460 zone's DS or DNSKEY RRset signals that that algorithm is used to 461 sign the entire zone. 463 A signed zone MUST include a DNSKEY for each algorithm present in 464 the zone's DS RRset and expected trust anchors for the zone. The 465 zone MUST also be signed with each algorithm (though not each key) 466 present in the DNSKEY RRset. It is possible to add algorithms at 467 the DNSKEY that aren't in the DS record, but not vice-versa. If 468 more than one key of the same algorithm is in the DNSKEY RRset, it 469 is sufficient to sign each RRset with any subset of these DNSKEYs. 470 It is acceptable to sign some RRsets with one subset of keys (or 471 key) and other RRsets with a different subset, so long as at least 472 one DNSKEY of each algorithm is used to sign each RRset. 473 Likewise, if there are DS records for multiple keys of the same 474 algorithm, any subset of those may appear in the DNSKEY RRset. 476 Lastly, note that this a requirement at the server side, not the 477 client side. Validators SHOULD accept any single valid path. They 478 SHOULD NOT insist that all algorithms signaled in the DS RRset work, 479 and they MUST NOT insist that all algorithms signaled in the DNSKEY 480 RRset work. A validator MAY have a configuration option to perform a 481 signature completeness test to support troubleshooting. 483 5.12. Ignore Extra Signatures From Unknown Keys 485 Validating resolvers MUST disregard RRSIGs in a zone that do not 486 (currently) have a corresponding DNSKEY in the zone. Similarly, a 487 validating resolver MUST disregard RRSIGs with algorithm types that 488 don't exist in the DNSKEY RRset. 490 Good key rollover and algorithm rollover practices, as discussed in 491 RFC4641 and its successor documents and as suggested by the rules in 492 the previous section, may require that such RRSIGs be present in a 493 zone. 495 6. Minor Corrections and Clarifications 497 6.1. Finding Zone Cuts 499 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 500 for a parent zone. To do that, a resolver may first need to apply 501 special rules to discover what those servers are. 503 As explained in Section 3.1.4.1 of [RFC4035], security-aware name 504 servers need to apply special processing rules to handle the DS RR, 505 and in some situations the resolver may also need to apply special 506 rules to locate the name servers for the parent zone if the resolver 507 does not already have the parent's NS RRset. Section 4.2 of 508 [RFC4035] specifies a mechanism for doing that. 510 6.2. Clarifications on DNSKEY Usage 512 It is possible to use different DNSKEYs to sign different subsets of 513 a zone, constrained only by the rules in Section 5.11. It is even 514 possible to use a different DNSKEY for each RRset in a zone, subject 515 only to practical limits on the size of the DNSKEY RRset and the 516 above rules. However, be aware that there is no way to tell 517 resolvers what a particular DNSKEY is supposed to be used for -- any 518 DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate 519 any RRset in the zone. For example, if a weaker or less trusted 520 DNSKEY is being used to authenticate NSEC RRsets or all dynamically 521 updated records, that same DNSKEY can also be used to sign any other 522 RRsets from the zone. 524 Furthermore, note that the SEP bit setting has no effect on how a 525 DNSKEY may be used -- the validation process is specifically 526 prohibited from using that bit by [RFC4034] section 2.1.2. It is 527 possible to use a DNSKEY without the SEP bit set as the sole secure 528 entry point to the zone, yet use a DNSKEY with the SEP bit set to 529 sign all RRsets in the zone (other than the DNSKEY RRset). It is 530 also possible to use a single DNSKEY, with or without the SEP bit 531 set, to sign the entire zone, including the DNSKEY RRset itself. 533 6.3. Errors in Examples 535 The text in [RFC4035] Section C.1 refers to the examples in B.1 as 536 "x.w.example.com" while B.1 uses "x.w.example". This is painfully 537 obvious in the second paragraph where it states that the RRSIG labels 538 field value of 3 indicates that the answer was not the result of 539 wildcard expansion. This is true for "x.w.example" but not for 540 "x.w.example.com", which of course has a label count of 4 541 (antithetically, a label count of 3 would imply the answer was the 542 result of a wildcard expansion). 544 The first paragraph of [RFC4035] Section C.6 also has a minor error: 545 the reference to "a.z.w.w.example" should instead be "a.z.w.example", 546 as in the previous line. 548 6.4. Errors in RFC 5155 550 A NSEC3 record that matches an Empty Non-Terminal effectively has no 551 type associated with it. This NSEC3 record has an empty type bit 552 map. Section 3.2.1 of [RFC5155] contains the statement: 554 Blocks with no types present MUST NOT be included. 556 However, the same section contains a regular expression: 558 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 560 The plus sign in the regular expression indicates that there is one 561 or more of the preceding element. This means that there must be at 562 least one window block. If this window block has no types, it 563 contradicts with the first statement. Therefore, the correct text in 564 RFC 5155 3.2.1 should be: 566 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 568 7. IANA Considerations 570 This document specifies no IANA Actions. 572 8. Security Considerations 574 This document adds SHA-2 and NSEC3 support to the core DNSSEC 575 protocol. Security considerations for those features are discussed 576 in the documents defining them. Additionally, this document 577 addresses some ambiguities and omissions in the core DNSSEC documents 578 that, if not recognized and addressed in implementations, could lead 579 to security failures. In particular, the validation algorithm 580 clarifications in Section 4 are critical for preserving the security 581 properties DNSSEC offers. Furthermore, failure to address some of 582 the interoperability concerns in Section 5 could limit the ability to 583 later change or expand DNSSEC, including adding new algorithms. 585 The recommendation in Section 5.9 to always set the CD bit has 586 security implications. By setting the CD bit, a resolver will not 587 benefit from more stringent validation rules or a more complete set 588 of trust anchors at an upstream validator. 590 9. References 592 9.1. Normative References 594 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 595 STD 13, RFC 1034, November 1987. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 601 RFC 3225, December 2001. 603 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 604 Rose, "DNS Security Introduction and Requirements", 605 RFC 4033, March 2005. 607 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 608 Rose, "Resource Records for the DNS Security Extensions", 609 RFC 4034, March 2005. 611 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 612 Rose, "Protocol Modifications for the DNS Security 613 Extensions", RFC 4035, March 2005. 615 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 616 (DS) Resource Records (RRs)", RFC 4509, May 2006. 618 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 619 Security (DNSSEC) Hashed Authenticated Denial of 620 Existence", RFC 5155, March 2008. 622 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 623 and RRSIG Resource Records for DNSSEC", RFC 5702, 624 October 2009. 626 9.2. Informative References 628 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 629 Signer (DS)", RFC 3755, May 2004. 631 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 632 RFC 4641, September 2006. 634 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 635 July 2007. 637 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 638 Trust Anchors", RFC 5011, September 2007. 640 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 641 November 2007. 643 Appendix A. Acknowledgments 645 The editors would like the thank Rob Austein for his previous work as 646 an editor of this document. 648 The editors are extremely grateful to those who, in addition to 649 finding errors and omissions in the DNSSECbis document set, have 650 provided text suitable for inclusion in this document. 652 The lack of specificity about handling private algorithms, as 653 described in Section 5.3, and the lack of specificity in handling ANY 654 queries, as described in Section 4.2, were discovered by David 655 Blacka. 657 The error in algorithm 1 key tag calculation, as described in 658 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 659 contributed text for Section 5.5. 661 The bug relating to delegation NSEC RR's in Section 4.1 was found by 662 Roy Badami. Roy Arends found the related problem with DNAME. 664 The errors in the [RFC4035] examples were found by Roy Arends, who 665 also contributed text for Section 6.3 of this document. 667 Text on the mandatory algorithm rules was derived from suggestions by 668 Matthijs Mekking and Ed Lewis. 670 The CD bit logic was analyzed in depth by David Blacka, Olafur 671 Gudmundsson, Mike St. Johns, and Andrew Sullivan. 673 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 674 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 675 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, 676 and Scott Rose for their substantive comments on the text of this 677 document. 679 Appendix B. Discussion of Setting the CD Bit 681 RFC 4035 may be read as relying on the implicit assumption that there 682 is at most one validating system between the stub resolver and the 683 authoritative server for a given zone. It is entirely possible, 684 however, for more than one validator to exist between a stub resolver 685 and an authoritative server. If these different validators have 686 disjoint trust anchors configured, then it is possible that each 687 would be able to validate some portion of the DNS tree but neither is 688 able to validate all of it. Accordingly, it might be argued that it 689 is desirable not to set the CD bit on upstream queries, because that 690 allows for maximal validation. 692 In section Section 5.9 of this document, it is recommended to set the 693 CD bit on an upstream query even when the incoming query arrives with 694 CD=0. This is for two reasons: it encourages a more predictable 695 validation experience as only one validator is always doing the 696 validation, and it ensures that all DNSSEC data that exists may be 697 available from the local cache should a query with CD=1 arrive. 699 As a matter of policy, it is possible to set the CD bit differently 700 than suggested in Section 5.9. A different choice will, of course, 701 not always yield the benefits listed above. It is beyond the scope 702 of this document to outline all of the considerations and counter 703 considerations for all possible policies. Nevertheless, it is 704 possible to describe three approaches and their underlying philosophy 705 of operation. These are laid out in the tables below. 707 The table that describes each model has five columns. The first 708 column indicates the value of the CD bit that the resolver receives 709 (for instance, on the name server side in an iterative resolver, or 710 as local policy or from the API in the case of a stub). The second 711 column indicates whether the query needs to be forwarded for 712 resolution (F) or can be satisfied from a local cache (C). The third 713 column is a line number, so that it can be referred to later in the 714 table. The fourth column indicates any relevant conditions at the 715 resolver: whether the resolver has a covering trust anchor and so on. 716 If there are no parameters here, the column is empty. The fifth and 717 final column indicates what action the resolver takes. 719 The tables differentiate between "cached data" and "cached RCODE=2". 720 This is a shorthand; the point is that one has to treat RCODE=2 as 721 special, because it might indicate a validation failure somewhere 722 upstream. The distinction is really between "cached RCODE=2" and 723 "cached everything else". 725 The tables are probably easiest to think of in terms of describing 726 what happens when a stub resolver sends a query to an intermediate 727 resolver, but they are perfectly general and can be applied to any 728 validating resolver. 730 Model 1: "always set" 732 This model is so named because the validating resolver sets the CD 733 bit on queries it makes regardless of whether it has a covering trust 734 anchor for the query. The general philosophy represented by this 735 table is that only one resolver should be responsible for validation 736 irrespective of the possibility that an upstream resolver may be 737 present with trust anchors that cover different or additional QNAMEs. 738 It is the model recommended in Section 5.9 of this document. 740 CD F/C line conditions action 741 ==================================================================== 742 1 F A1 Set CD=1 on upstream query 743 0 F A2 Set CD=1 on upstream query 744 1 C A3 Return the cache contents 745 (data or RCODE=2) 746 0 C A4 no covering TA Return cache contents 747 (data or RCODE=2) 748 0 C A5 covering TA Validate cached result and 749 return it. 751 Model 2: "never set when receiving CD=0" 753 This model is so named because it sets CD=0 on upstream queries for 754 all received CD=0 queries even if it has a covering trust anchor. 755 The general philosophy represented by this table is that more than 756 one resolver may take responsibility for validating a QNAME and that 757 a validation failure for a QNAME by any resolver in the chain is a 758 validation failure for the query. Using this model is NOT 759 RECOMMENDED. 761 CD F/C line conditions action 762 ==================================================================== 763 1 F N1 Set CD=1 on upstream query 764 0 F N2 Set CD=0 on upstream query 765 1 C N3 cached data Return cached data 766 1 C N4 cached RCODE=2 Treat as line N1 767 0 C N5 no covering TA Return cache contents 768 (data or RCODE=2) 769 0 C N6 covering TA & Treat as line N2 770 cached data was 771 generated with CD=1 772 0 C N7 covering TA & Validate and return 773 cached data was 774 generated with CD=0 776 Model 3: "sometimes set" 778 This model is so named because it sets the CD bit on upstream queries 779 triggered by received CD=0 queries based on whether the validator has 780 a trust anchor configured that covers the query. If there is no 781 covering trust anchor, the resolver clears the CD bit in the upstream 782 query. If there is a covering trust anchor, the resolver sets CD=1 783 and performs validation itself. The general philosophy represented 784 by this table is that a resolver should try and validate QNAMEs for 785 which is has trust anchors and should not preclude validation by 786 other resolvers for QNAMEs for which it does not have covering trust 787 anchors. Using this model is NOT RECOMMENDED. 789 CD F/C line conditions action 790 ==================================================================== 791 1 F S1 Set CD=1 on upstream query 792 0 F S2 covering TA Set CD=1 on upstream query 793 0 F S3 no covering TA Set CD=0 on upstream query 794 1 C S4 cached data Return cached data 795 1 C S5 cached RCODE=2 Treat as line S1 796 0 C S6 cached data was Return cache contents 797 generated with 798 CD=0 799 0 C S7 cached data was Validate & return cache 800 generated with contents 801 CD=1 & 802 covering TA 803 0 C S8 cached RCODE=2 Return cache contents 804 0 C S9 cached data Treat as line S3 805 was generated 806 with CD=1 & 807 no covering 808 TA 810 Appendix C. Discussion of Trust Anchor Preference Options 812 This section presents several different policies for validating 813 resolvers to use when they have a choice of trust anchors available 814 for validating a given answer. 816 C.1. Closest Encloser 818 One policy is to choose the trust anchor closest to the QNAME of the 819 response. For example, consider a validator configured with trust 820 anchors for "example." and "zone.example." When asked to validate a 821 response for "www.sub.zone.example.", a validator using the "Closest 822 Encloser" policy would choose the "zone.example." trust anchor. 824 This policy has the advantage of allowing the operator to trivially 825 override a parent zone's trust anchor with one that the operator can 826 validate in a stronger way, perhaps because the resolver operator is 827 affiliated with the zone in question. This policy also minimizes the 828 number of public key operations needed, which is of benefit in 829 resource-constrained environments. 831 This policy has the disadvantage of giving the user some unexpected 832 and unnecessary validation failures when sub-zone trust anchors are 833 neglected. As a concrete example, consider a validator that 834 configured a trust anchor for "zone.example." in 2009 and one for 835 "example." in 2011. In 2012, "zone.example." rolls its KSK and 836 updates its DS records, but the validator operator doesn't update its 837 trust anchor. With the "closest encloser" policy, the validator gets 838 validation failures. 840 C.2. Accept Any Success 842 Another policy is to try all applicable trust anchors until one gives 843 a validation result of Secure, in which case the final validation 844 result is Secure. If and only if all applicable trust anchors give a 845 result of Insecure, the final validation result is Insecure. If one 846 or more trust anchors lead to a Bogus result and there is no Secure 847 result, then the final validation result is Bogus. 849 This has the advantage of causing the fewest validation failures, 850 which may deliver a better user experience. If one trust anchor is 851 out of date (as in our above example), the user may still be able to 852 get a Secure validation result (and see DNS responses). 854 This policy has the disadvantage of making the validator subject to 855 the compromise of the weakest of these trust anchors while making it 856 relatively painless to keep old trust anchors configured in 857 perpetuity. 859 C.3. Preference Based on Source 861 When the trust anchors have come from different sources (e.g. 862 automated updates ([RFC5011]), one or more DLV registries 863 ([RFC5074]), and manually configured), a validator may wish to choose 864 between them based on the perceived reliability of those sources. 865 The order of precedence might be exposed as a configuration option. 867 For example, a validator might choose to prefer trust anchors found 868 in a DLV registry over those manually configured on the theory that 869 the manually configured ones will not be as aggressively maintained. 871 Conversely, a validator might choose to prefer manually configured 872 trust anchors over those obtained from a DLV registry on the theory 873 that the manually configured ones have been more carefully 874 authenticated. 876 Or the validator might do something more complex: prefer a sub-set of 877 manually configured trust anchors (based on a configuration option), 878 then trust anchors that have been updated using the RFC5011 879 mechanism, then trust anchors from one DLV registry, then trust 880 anchors from a different DLV registry, then the rest of the manually 881 configured trust anchors. 883 Authors' Addresses 885 Samuel Weiler 886 SPARTA, Inc. 887 7110 Samuel Morse Drive 888 Columbia, Maryland 21046 889 US 891 Email: weiler@tislabs.com 893 David Blacka 894 Verisign, Inc. 895 12061 Bluemont Way 896 Reston, VA 20190 897 US 899 Email: davidb@verisign.com