idnits 2.17.00 (12 Aug 2021) /tmp/idnits3388/draft-ietf-dnsext-dnssec-bis-updates-17.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 (March 12, 2012) is 3721 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 March 12, 2012 7 Expires: September 13, 2012 9 Clarifications and Implementation Notes for DNSSECbis 10 draft-ietf-dnsext-dnssec-bis-updates-17 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 September 13, 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 . . . . . . . . . . 16 106 Appendix C. Discussion of Trust Anchor Preference Options . . . . 18 107 C.1. Closest Encloser . . . . . . . . . . . . . . . . . . . . . 19 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 This section does not apply to stub resolvers. 403 When processing a request with the CD bit set, a resolver SHOULD 404 attempt to return all response data, even data that has failed DNSSEC 405 validation. RFC4035 section 3.2.2 requires a resolver processing a 406 request with the CD bit set to set the CD bit on its upstream 407 queries. 409 This document further specifies that validating resolvers SHOULD set 410 the CD bit on every upstream query. This is regardless of whether 411 the CD bit was set on the incoming query or whether it has a trust 412 anchor at or above the QNAME. 414 [RFC4035] is ambiguous about what to do when a cached response was 415 obtained with the CD bit unset, a case that only arises when the 416 resolver chooses not to set the CD bit on all upstream queries, as 417 specified above. In the typical case, no new query is required, nor 418 does the cache need to track the state of the CD bit used to make a 419 given query. The problem arises when the cached response is a server 420 failure (RCODE 2), which may indicate that the requested data failed 421 DNSSEC validation at an upstream validating resolver. (RFC2308 422 permits caching of server failures for up to five minutes.) In these 423 cases, a new query with the CD bit set is required. 425 Appendix B discusses more of the logic behind the recommendation 426 presented in this section. 428 5.10. Nested Trust Anchors 430 A DNSSEC validator may be configured such that, for a given response, 431 more than one trust anchor could be used to validate the chain of 432 trust to the response zone. For example, imagine a validator 433 configured with trust anchors for "example." and "zone.example." 434 When the validator is asked to validate a response to 435 "www.sub.zone.example.", either trust anchor could apply. 437 When presented with this situation, DNSSEC validators have a choice 438 of which trust anchor(s) to use. Which to use is a matter of 439 implementation choice. Appendix C discusses several possible 440 algorithms. 442 It is possible and advisable to expose the choice of policy as a 443 configuration option. As a default, it is suggested that validators 444 implement the "Accept Any Success" policy described in Appendix C.2 445 while exposing other policies as configuration options. 447 The "Accept Any Success" policy is to try all applicable trust 448 anchors until one gives a validation result of Secure, in which case 449 the final validation result is Secure. If and only if all applicable 450 trust anchors give a result of Insecure, the final validation result 451 is Insecure. If one or more trust anchors lead to a Bogus result and 452 there is no Secure result, then the final validation result is Bogus. 454 5.11. Mandatory Algorithm Rules 456 The last paragraph of RFC4035 Section 2.2 includes rules describing 457 which algorithms must be used to sign a zone. Since these rules have 458 been confusing, they are restated using different language here: 460 The DS RRset and DNSKEY RRset are used to signal which algorithms 461 are used to sign a zone. The presence of an algorithm in either a 462 zone's DS or DNSKEY RRset signals that that algorithm is used to 463 sign the entire zone. 465 A signed zone MUST include a DNSKEY for each algorithm present in 466 the zone's DS RRset and expected trust anchors for the zone. The 467 zone MUST also be signed with each algorithm (though not each key) 468 present in the DNSKEY RRset. It is possible to add algorithms at 469 the DNSKEY that aren't in the DS record, but not vice-versa. If 470 more than one key of the same algorithm is in the DNSKEY RRset, it 471 is sufficient to sign each RRset with any subset of these DNSKEYs. 472 It is acceptable to sign some RRsets with one subset of keys (or 473 key) and other RRsets with a different subset, so long as at least 474 one DNSKEY of each algorithm is used to sign each RRset. 475 Likewise, if there are DS records for multiple keys of the same 476 algorithm, any subset of those may appear in the DNSKEY RRset. 478 Lastly, note that this a requirement at the server side, not the 479 client side. Validators SHOULD accept any single valid path. They 480 SHOULD NOT insist that all algorithms signaled in the DS RRset work, 481 and they MUST NOT insist that all algorithms signaled in the DNSKEY 482 RRset work. A validator MAY have a configuration option to perform a 483 signature completeness test to support troubleshooting. 485 5.12. Ignore Extra Signatures From Unknown Keys 487 Validating resolvers MUST disregard RRSIGs in a zone that do not 488 (currently) have a corresponding DNSKEY in the zone. Similarly, a 489 validating resolver MUST disregard RRSIGs with algorithm types that 490 don't exist in the DNSKEY RRset. 492 Good key rollover and algorithm rollover practices, as discussed in 493 RFC4641 and its successor documents and as suggested by the rules in 494 the previous section, may require that such RRSIGs be present in a 495 zone. 497 6. Minor Corrections and Clarifications 499 6.1. Finding Zone Cuts 501 Appendix C.8 of [RFC4035] discusses sending DS queries to the servers 502 for a parent zone. To do that, a resolver may first need to apply 503 special rules to discover what those servers are. 505 As explained in Section 3.1.4.1 of [RFC4035], security-aware name 506 servers need to apply special processing rules to handle the DS RR, 507 and in some situations the resolver may also need to apply special 508 rules to locate the name servers for the parent zone if the resolver 509 does not already have the parent's NS RRset. Section 4.2 of 510 [RFC4035] specifies a mechanism for doing that. 512 6.2. Clarifications on DNSKEY Usage 514 It is possible to use different DNSKEYs to sign different subsets of 515 a zone, constrained only by the rules in Section 5.11. It is even 516 possible to use a different DNSKEY for each RRset in a zone, subject 517 only to practical limits on the size of the DNSKEY RRset and the 518 above rules. However, be aware that there is no way to tell 519 resolvers what a particular DNSKEY is supposed to be used for -- any 520 DNSKEY in the zone's signed DNSKEY RRset may be used to authenticate 521 any RRset in the zone. For example, if a weaker or less trusted 522 DNSKEY is being used to authenticate NSEC RRsets or all dynamically 523 updated records, that same DNSKEY can also be used to sign any other 524 RRsets from the zone. 526 Furthermore, note that the SEP bit setting has no effect on how a 527 DNSKEY may be used -- the validation process is specifically 528 prohibited from using that bit by [RFC4034] section 2.1.2. It is 529 possible to use a DNSKEY without the SEP bit set as the sole secure 530 entry point to the zone, yet use a DNSKEY with the SEP bit set to 531 sign all RRsets in the zone (other than the DNSKEY RRset). It is 532 also possible to use a single DNSKEY, with or without the SEP bit 533 set, to sign the entire zone, including the DNSKEY RRset itself. 535 6.3. Errors in Examples 537 The text in [RFC4035] Section C.1 refers to the examples in B.1 as 538 "x.w.example.com" while B.1 uses "x.w.example". This is painfully 539 obvious in the second paragraph where it states that the RRSIG labels 540 field value of 3 indicates that the answer was not the result of 541 wildcard expansion. This is true for "x.w.example" but not for 542 "x.w.example.com", which of course has a label count of 4 543 (antithetically, a label count of 3 would imply the answer was the 544 result of a wildcard expansion). 546 The first paragraph of [RFC4035] Section C.6 also has a minor error: 547 the reference to "a.z.w.w.example" should instead be "a.z.w.example", 548 as in the previous line. 550 6.4. Errors in RFC 5155 552 A NSEC3 record that matches an Empty Non-Terminal effectively has no 553 type associated with it. This NSEC3 record has an empty type bit 554 map. Section 3.2.1 of [RFC5155] contains the statement: 556 Blocks with no types present MUST NOT be included. 558 However, the same section contains a regular expression: 560 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ 562 The plus sign in the regular expression indicates that there is one 563 or more of the preceding element. This means that there must be at 564 least one window block. If this window block has no types, it 565 contradicts with the first statement. Therefore, the correct text in 566 RFC 5155 3.2.1 should be: 568 Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* 570 7. IANA Considerations 572 This document specifies no IANA Actions. 574 8. Security Considerations 576 This document adds SHA-2 and NSEC3 support to the core DNSSEC 577 protocol. Security considerations for those features are discussed 578 in the documents defining them. Additionally, this document 579 addresses some ambiguities and omissions in the core DNSSEC documents 580 that, if not recognized and addressed in implementations, could lead 581 to security failures. In particular, the validation algorithm 582 clarifications in Section 4 are critical for preserving the security 583 properties DNSSEC offers. Furthermore, failure to address some of 584 the interoperability concerns in Section 5 could limit the ability to 585 later change or expand DNSSEC, including adding new algorithms. 587 The recommendation in Section 5.9 to always set the CD bit has 588 security implications. By setting the CD bit, a resolver will not 589 benefit from more stringent validation rules or a more complete set 590 of trust anchors at an upstream validator. 592 9. References 594 9.1. Normative References 596 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 597 STD 13, RFC 1034, November 1987. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 603 RFC 3225, December 2001. 605 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 606 Rose, "DNS Security Introduction and Requirements", 607 RFC 4033, March 2005. 609 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 610 Rose, "Resource Records for the DNS Security Extensions", 611 RFC 4034, March 2005. 613 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 614 Rose, "Protocol Modifications for the DNS Security 615 Extensions", RFC 4035, March 2005. 617 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 618 (DS) Resource Records (RRs)", RFC 4509, May 2006. 620 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 621 Security (DNSSEC) Hashed Authenticated Denial of 622 Existence", RFC 5155, March 2008. 624 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 625 and RRSIG Resource Records for DNSSEC", RFC 5702, 626 October 2009. 628 9.2. Informative References 630 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation 631 Signer (DS)", RFC 3755, May 2004. 633 [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 634 RFC 4641, September 2006. 636 [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, 637 July 2007. 639 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 640 Trust Anchors", RFC 5011, September 2007. 642 [RFC5074] Weiler, S., "DNSSEC Lookaside Validation (DLV)", RFC 5074, 643 November 2007. 645 Appendix A. Acknowledgments 647 The editors would like the thank Rob Austein for his previous work as 648 an editor of this document. 650 The editors are extremely grateful to those who, in addition to 651 finding errors and omissions in the DNSSECbis document set, have 652 provided text suitable for inclusion in this document. 654 The lack of specificity about handling private algorithms, as 655 described in Section 5.3, and the lack of specificity in handling ANY 656 queries, as described in Section 4.2, were discovered by David 657 Blacka. 659 The error in algorithm 1 key tag calculation, as described in 660 Section 5.5, was found by Abhijit Hayatnagarkar. Donald Eastlake 661 contributed text for Section 5.5. 663 The bug relating to delegation NSEC RR's in Section 4.1 was found by 664 Roy Badami. Roy Arends found the related problem with DNAME. 666 The errors in the [RFC4035] examples were found by Roy Arends, who 667 also contributed text for Section 6.3 of this document. 669 Text on the mandatory algorithm rules was derived from suggestions by 670 Matthijs Mekking and Ed Lewis. 672 The CD bit logic was analyzed in depth by David Blacka, Olafur 673 Gudmundsson, Mike St. Johns, and Andrew Sullivan. 675 The editors would like to thank Alfred Hoenes, Ed Lewis, Danny Mayer, 676 Olafur Gudmundsson, Suzanne Woolf, Rickard Bellgrim, Mike St. Johns, 677 Mark Andrews, Wouter Wijngaards, Matthijs Mekking, Andrew Sullivan, 678 and Scott Rose for their substantive comments on the text of this 679 document. 681 Appendix B. Discussion of Setting the CD Bit 683 RFC 4035 may be read as relying on the implicit assumption that there 684 is at most one validating system between the stub resolver and the 685 authoritative server for a given zone. It is entirely possible, 686 however, for more than one validator to exist between a stub resolver 687 and an authoritative server. If these different validators have 688 disjoint trust anchors configured, then it is possible that each 689 would be able to validate some portion of the DNS tree but neither is 690 able to validate all of it. Accordingly, it might be argued that it 691 is desirable not to set the CD bit on upstream queries, because that 692 allows for maximal validation. 694 In section Section 5.9 of this document, it is recommended to set the 695 CD bit on an upstream query even when the incoming query arrives with 696 CD=0. This is for two reasons: it encourages a more predictable 697 validation experience as only one validator is always doing the 698 validation, and it ensures that all DNSSEC data that exists may be 699 available from the local cache should a query with CD=1 arrive. 701 As a matter of policy, it is possible to set the CD bit differently 702 than suggested in Section 5.9. A different choice will, of course, 703 not always yield the benefits listed above. It is beyond the scope 704 of this document to outline all of the considerations and counter 705 considerations for all possible policies. Nevertheless, it is 706 possible to describe three approaches and their underlying philosophy 707 of operation. These are laid out in the tables below. 709 The table that describes each model has five columns. The first 710 column indicates the value of the CD bit that the resolver receives 711 (for instance, on the name server side in an iterative resolver, or 712 as local policy or from the API in the case of a stub). The second 713 column indicates whether the query needs to be forwarded for 714 resolution (F) or can be satisfied from a local cache (C). The third 715 column is a line number, so that it can be referred to later in the 716 table. The fourth column indicates any relevant conditions at the 717 resolver: whether the resolver has a covering trust anchor and so on. 718 If there are no parameters here, the column is empty. The fifth and 719 final column indicates what action the resolver takes. 721 The tables differentiate between "cached data" and "cached RCODE=2". 722 This is a shorthand; the point is that one has to treat RCODE=2 as 723 special, because it might indicate a validation failure somewhere 724 upstream. The distinction is really between "cached RCODE=2" and 725 "cached everything else". 727 The tables are probably easiest to think of in terms of describing 728 what happens when a stub resolver sends a query to an intermediate 729 resolver, but they are perfectly general and can be applied to any 730 validating resolver. 732 Model 1: "always set" 734 This model is so named because the validating resolver sets the CD 735 bit on queries it makes regardless of whether it has a covering trust 736 anchor for the query. The general philosophy represented by this 737 table is that only one resolver should be responsible for validation 738 irrespective of the possibility that an upstream resolver may be 739 present with trust anchors that cover different or additional QNAMEs. 740 It is the model recommended in Section 5.9 of this document. 742 CD F/C line conditions action 743 ==================================================================== 744 1 F A1 Set CD=1 on upstream query 745 0 F A2 Set CD=1 on upstream query 746 1 C A3 Return the cache contents 747 (data or RCODE=2) 748 0 C A4 no covering TA Return cache contents 749 (data or RCODE=2) 750 0 C A5 covering TA Validate cached result and 751 return it. 753 Model 2: "never set when receiving CD=0" 755 This model is so named because it sets CD=0 on upstream queries for 756 all received CD=0 queries even if it has a covering trust anchor. 757 The general philosophy represented by this table is that more than 758 one resolver may take responsibility for validating a QNAME and that 759 a validation failure for a QNAME by any resolver in the chain is a 760 validation failure for the query. Using this model is NOT 761 RECOMMENDED. 763 CD F/C line conditions action 764 ==================================================================== 765 1 F N1 Set CD=1 on upstream query 766 0 F N2 Set CD=0 on upstream query 767 1 C N3 cached data Return cached data 768 1 C N4 cached RCODE=2 Treat as line N1 769 0 C N5 no covering TA Return cache contents 770 (data or RCODE=2) 771 0 C N6 covering TA & Treat as line N2 772 cached data was 773 generated with CD=1 774 0 C N7 covering TA & Validate and return 775 cached data was 776 generated with CD=0 778 Model 3: "sometimes set" 780 This model is so named because it sets the CD bit on upstream queries 781 triggered by received CD=0 queries based on whether the validator has 782 a trust anchor configured that covers the query. If there is no 783 covering trust anchor, the resolver clears the CD bit in the upstream 784 query. If there is a covering trust anchor, the resolver sets CD=1 785 and performs validation itself. The general philosophy represented 786 by this table is that a resolver should try and validate QNAMEs for 787 which is has trust anchors and should not preclude validation by 788 other resolvers for QNAMEs for which it does not have covering trust 789 anchors. Using this model is NOT RECOMMENDED. 791 CD F/C line conditions action 792 ==================================================================== 793 1 F S1 Set CD=1 on upstream query 794 0 F S2 covering TA Set CD=1 on upstream query 795 0 F S3 no covering TA Set CD=0 on upstream query 796 1 C S4 cached data Return cached data 797 1 C S5 cached RCODE=2 Treat as line S1 798 0 C S6 cached data was Return cache contents 799 generated with 800 CD=0 801 0 C S7 cached data was Validate & return cache 802 generated with contents 803 CD=1 & 804 covering TA 805 0 C S8 cached RCODE=2 Return cache contents 806 0 C S9 cached data Treat as line S3 807 was generated 808 with CD=1 & 809 no covering 810 TA 812 Appendix C. Discussion of Trust Anchor Preference Options 814 This section presents several different policies for validating 815 resolvers to use when they have a choice of trust anchors available 816 for validating a given answer. 818 C.1. Closest Encloser 820 One policy is to choose the trust anchor closest to the QNAME of the 821 response. For example, consider a validator configured with trust 822 anchors for "example." and "zone.example." When asked to validate a 823 response for "www.sub.zone.example.", a validator using the "Closest 824 Encloser" policy would choose the "zone.example." trust anchor. 826 This policy has the advantage of allowing the operator to trivially 827 override a parent zone's trust anchor with one that the operator can 828 validate in a stronger way, perhaps because the resolver operator is 829 affiliated with the zone in question. This policy also minimizes the 830 number of public key operations needed, which is of benefit in 831 resource-constrained environments. 833 This policy has the disadvantage of giving the user some unexpected 834 and unnecessary validation failures when sub-zone trust anchors are 835 neglected. As a concrete example, consider a validator that 836 configured a trust anchor for "zone.example." in 2009 and one for 837 "example." in 2011. In 2012, "zone.example." rolls its KSK and 838 updates its DS records, but the validator operator doesn't update its 839 trust anchor. With the "closest encloser" policy, the validator gets 840 validation failures. 842 C.2. Accept Any Success 844 Another policy is to try all applicable trust anchors until one gives 845 a validation result of Secure, in which case the final validation 846 result is Secure. If and only if all applicable trust anchors give a 847 result of Insecure, the final validation result is Insecure. If one 848 or more trust anchors lead to a Bogus result and there is no Secure 849 result, then the final validation result is Bogus. 851 This has the advantage of causing the fewest validation failures, 852 which may deliver a better user experience. If one trust anchor is 853 out of date (as in our above example), the user may still be able to 854 get a Secure validation result (and see DNS responses). 856 This policy has the disadvantage of making the validator subject to 857 the compromise of the weakest of these trust anchors while making it 858 relatively painless to keep old trust anchors configured in 859 perpetuity. 861 C.3. Preference Based on Source 863 When the trust anchors have come from different sources (e.g. 864 automated updates ([RFC5011]), one or more DLV registries 865 ([RFC5074]), and manually configured), a validator may wish to choose 866 between them based on the perceived reliability of those sources. 867 The order of precedence might be exposed as a configuration option. 869 For example, a validator might choose to prefer trust anchors found 870 in a DLV registry over those manually configured on the theory that 871 the manually configured ones will not be as aggressively maintained. 873 Conversely, a validator might choose to prefer manually configured 874 trust anchors over those obtained from a DLV registry on the theory 875 that the manually configured ones have been more carefully 876 authenticated. 878 Or the validator might do something more complex: prefer a sub-set of 879 manually configured trust anchors (based on a configuration option), 880 then trust anchors that have been updated using the RFC5011 881 mechanism, then trust anchors from one DLV registry, then trust 882 anchors from a different DLV registry, then the rest of the manually 883 configured trust anchors. 885 Authors' Addresses 887 Samuel Weiler 888 SPARTA, Inc. 889 7110 Samuel Morse Drive 890 Columbia, Maryland 21046 891 US 893 Email: weiler@tislabs.com 895 David Blacka 896 Verisign, Inc. 897 12061 Bluemont Way 898 Reston, VA 20190 899 US 901 Email: davidb@verisign.com