idnits 2.17.1 draft-weiler-dnssec-dlv-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 470. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 12, 2007) is 6064 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) ** Downref: Normative reference to an Historic RFC: RFC 4431 == Outdated reference: A later version (-13) exists of draft-ietf-dnsext-nsec3-11 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Expires: March 15, 2008 September 12, 2007 6 DNSSEC Lookaside Validation (DLV) 7 draft-weiler-dnssec-dlv-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 This document may not be modified, and derivative works of it may not 16 be created, except to publish it as an RFC and to translate it into 17 languages other than English. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 15, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 DNSSEC Lookaside Validation (DLV) is a mechanism for publishing 44 DNSSEC trust anchors outside of the DNS delegation chain. It allows 45 validating resolvers to validate DNSSEC-signed data from zones whose 46 ancestors either aren't signed or don't publish Delegation Signer 47 (DS) records for their children. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. DLV Domains . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Overview of Validator Behavior . . . . . . . . . . . . . . . . 4 55 5. Details of Validator Behavior . . . . . . . . . . . . . . . . 5 56 6. Aggressive Negative Caching . . . . . . . . . . . . . . . . . 6 57 6.1. Implementation Notes . . . . . . . . . . . . . . . . . . . 6 58 7. Overlapping DLV Domains . . . . . . . . . . . . . . . . . . . 7 59 8. Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 DNSSEC [RFC4033] [RFC4034] [RFC4035] authenticates DNS data by 72 building public-key signature chains along the DNS delegation chain 73 from a trust anchor. 75 In the present world, with the DNS root and many key top level 76 domains unsigned, the only way for a validating resolver 77 ("validator") to validate the many DNSSEC-signed zones is to maintain 78 a sizable collection of preconfiugred trust anchors. Maintaining 79 multiple preconfigured trust anchors in each DNSSEC-aware validator 80 presents a significant management challenge. 82 This document describes a way to publish trust anchors in the DNS 83 outside of the normal delegation chain, as a way to easily configure 84 many validators within an organization or to "outsource" trust anchor 85 management. 87 Some design trade-offs leading to the mechanism presented here are 88 described in [INI1999-19]. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Architecture 96 DNSSEC Lookaside Validation allows a set of domains, called "DLV 97 domains", to publish secure entry points for zones that are not their 98 own children. 100 With DNSSEC, validators may expect a zone to be secure when they have 101 one of two things: a preconfigured trust anchor for the zone or a 102 validated Delegation Signer (DS) record for the zone in its parent 103 (which presumes a preconfigured trust anchor for the parent or 104 another ancestor). DLV adds a third mechanism: a validated entry in 105 a DLV domain (which presumes a preconfigured trust anchor for the DLV 106 domain). Whenever a DLV domain contains a DLV RRset for a zone, a 107 validator may expect the named zone to be signed. Absence of a DLV 108 RRset for a zone does not necessarily mean that the zone should be 109 expected to be insecure; if the validator has another reason to 110 believe the zone should be secured, validation of that zone's data 111 should still be attempted. 113 3. DLV Domains 115 A DLV domain includes trust statements about descendants of a single 116 zone, called the 'target' zone. For example, the DLV domain 117 trustbroker.example.com could target the org zone and the DLV domain 118 bar.example.com could target the root. 120 A DLV domain contains one or more DLV records [RFC4431] for each of 121 the target's descendant zones that have registered security 122 information with it. For a given zone, the corresponding name in the 123 DLV domain is formed by replacing the target zone name with the DLV 124 domain name. 126 For example, assuming the DLV domain trustbroker.example.com targets 127 the org zone, any DLV records corresponding to the zone example.org 128 can be found at example.trustbroker.example.com. DLV records 129 corresponding to the org zone can be found at the apex of 130 trustbroker.example.com. 132 As another example, assuming the DLV domain bar.example.com targets 133 the root zone, DLV records corresponding to the zone example.org can 134 be found at example.org.bar.example.com. DLV records corresponding 135 to the org zone can be found at org.bar.example.com. And DLV records 136 corresponding to the root zone itself can be found at the apex of 137 bar.example.com. 139 A DLV domain need not contain data other than DLV records, 140 appropriate DNSSEC records validating that data, the apex NS and SOA 141 records, and, optionally, delegations. In most cases, the operator 142 of a DLV domain will probably not want to include any other RR types 143 in the DLV domain. 145 To gain full benefit from aggressive negative caching, described in 146 Section 6, a DLV domain SHOULD NOT use minimally-covering NSEC 147 records, as described in [RFC4470], and it SHOULD NOT use NSEC3 148 records, as described in [I-D.ietf-dnsext-nsec3]. 150 4. Overview of Validator Behavior 152 To minimize load on the DLV domain's authoritative servers as well as 153 query response time, a validator SHOULD first attempt validation 154 using any applicable (non-DLV) trust anchors. If the validation 155 succeeds (with a result of Secure), DLV processing need not occur. 157 When configured with a trust anchor for a DLV domain, a validator 158 SHOULD attempt to validate all responses at and below the target of 159 that DLV domain. 161 To do validation using DLV, a validator looks for a (validated) DLV 162 RRset applicable to the query, as described in the following section, 163 and uses it as though it were a DS RRset to validate the answer using 164 the normal procedures in RFC4035 Section 5. 166 For each response, the validator attempts validation using the 167 "closest enclosing" DLV RRset in the DLV domain, which is the DLV 168 RRset with the longest name that matches the query or could be an 169 ancestor of the QNAME. For example, assuming the DLV domain 170 trustbroker.example.com targets the org zone, and there exist DLV 171 RRsets named trustbroker.example.com (applicable to org), 172 example.trustbroker.example.com (applicable to example.org), and 173 sub.example.trustbroker.example.com (applicable to sub.example.org), 174 a validator would use the sub.example.trustbroker.example.com DLV 175 RRset for validating responses to a query for sub.example.org. 177 The choice of which DLV record(s) to use has a significant impact on 178 the query load seen at DLV domains' authoritative servers. The 179 particular DLV selection rule described in this document results in a 180 higher query load than some other selection rules, but it has some 181 advantages in terms of the security policies that it can implement. 182 More detailed discussion of this DLV selection rule as well as 183 several alternatives that were considered along the way can be found 184 in [INI1999-19]. 186 5. Details of Validator Behavior 188 As above, to minimize load on the DLV domain's authoritative servers 189 as well as query response time, a validator SHOULD first attempt 190 validation using any applicable (non-DLV) trust anchors. If the 191 validation succeeds (with a result of Secure), DLV processing need 192 not occur. 194 To find the closest enclosing DLV RRset for a given query, the 195 validator starts by looking for a DLV RRset corresponding to the 196 QNAME. If it doesn't find a DLV RRset for that name (as confirmed by 197 the presence of a validated NSEC record) and that name is not the 198 apex of the DLV domain, the validator removes the leading label from 199 the name and tries again. This process is repeated until a DLV RRset 200 is found or it is proved that there is no enclosing DLV RRset 201 applicable to the QNAME. In all cases, a validator SHOULD check its 202 cache for the desired DLV RRset before issuing a query. Section 8 203 discusses a slight optimization to this strategy. 205 Having found the closest enclosing DLV RRset or received a proof that 206 no applicable DLV RRset exists, the validator MUST validate that 207 RRset or non-existence proof using the normal procedures in Section 5 208 of RFC4035. In particular, any delegations within the DLV domain 209 need to be followed, with normal DNSSEC validation applied. If 210 validation of the DLV RRset leads to a result of Bogus, then it MUST 211 NOT be used and the validation result for the original response 212 SHOULD be Bogus, also. If validation of the DLV RRset leads to a 213 result of Insecure (the DLV record is in an unsecured portion of the 214 DLV domain), then it MUST NOT be used and the validation result for 215 the original response SHOULD be Insecure, also. (It should be very 216 odd, indeed, to find part of a DLV domain marked as Insecure: this is 217 likely to happen only when there are delegations within the DLV 218 domain and some portions of that domain use different cryptographic 219 signing algorithms.) If the validation of the DLV RRset leads to a 220 result of Secure, the validator then treats that DLV RRset as though 221 it were a DS RRset for the applicable zone and attempts validation 222 using the procedures described in RFC4035 Section 5. 224 In the interest of limiting complexity, validators SHOULD NOT attempt 225 to use DLV to validate data from another DLV domain. 227 6. Aggressive Negative Caching 229 To minimize load on authoritative servers for DLV domains, 230 particularly those with few entries, DLV validators SHOULD implement 231 aggressive negative caching, as defined in this section. 233 Previously, cached negative responses were indexed by QNAME, QCLASS, 234 QTYPE, and the setting of the CD bit (see RFC4035 section 4.7) and 235 only queries matching the index key would be answered from the cache. 236 With aggressive negative caching, the validator, in addition to 237 checking to see if the answer is in its cache before sending a query, 238 checks to see whether any cached and validated NSEC record denies the 239 existence of the sought record(s). 241 Using aggressive negative caching, a validator will not make queries 242 for any name covered by a cached and validated NSEC record. 243 Furthermore, a validator answering queries from clients will 244 synthesize a negative answer whenever it has an applicable validated 245 NSEC in its cache unless the CD bit was set on the incoming query. 247 6.1. Implementation Notes 249 Implementing aggressive negative caching suggests that a validator 250 will need to build an ordered data structure of NSEC records in order 251 to efficiently find covering NSEC records. Only NSEC records from 252 DLV domains need to be included in this data structure 254 Also note that some DLV validator implementations do not synthesize 255 negative answers to insert into outgoing responses -- they only use 256 aggressive negative caching when looking up DLV RRs as part of their 257 internal DLV validation. 259 7. Overlapping DLV Domains 261 It is possible to have multiple DLV domains targeting overlapping 262 portions of the DNS hierarchy. For example, two DLV domains, perhaps 263 operated by different parties, might target the org zone, or one DLV 264 domain might target the root while another targets org. 266 If a validator supports multiple DLV domains, the choice of 267 precedence in case of overlap is left up to the implementation and 268 SHOULD be exposed as a configuration option to the user. (As 269 compared to the choice of DLV records within each domain, a 270 precedence for which is clearly specified in this document.) As a 271 very simple default, a validator could give precedence to the most 272 specific DLV domain. 274 Some other reasonable options include: 275 1. Searching all applicable DLV domains until an applicable DLV 276 record is found that results in a successful validation of the 277 response. In the case where no applicable DLV record is found in 278 any DLV domain, the answer will be treated as Unsecure. 279 2. Applying some sort of precedence to the DLV domains based on 280 their perceived trustworthiness. 281 3. Searching all applicable DLV domains for applicable DLV records 282 and using only the most specific of those DLV records. 283 4. If multiple DLV domains provide applicable DLV records, use a 284 threshold or scoring system (e.g., "best 2 out of 3") to 285 determine the validation result. 287 The above list is surely not complete, and it's possible for 288 validators to have different precedence rules and configuration 289 options for these cases. [INI1999-19] discusses different policies 290 for selecting from multiple DLV records within the same DLV domain. 291 That discussion may also be applicable to the question of which DLV 292 domain to use and may be of interest to implementers of validators 293 that support multiple DLV domains. 295 8. Optimization 297 This section documents an optimization to further reduce query load 298 on DLV servers and improve validator response time. 300 Authoritative servers, when processing a query for a DLV RRset, 301 SHOULD include all DLV RRsets potentially applicable to a query 302 (specifically, all DLV RRsets application to the QNAME and any of its 303 ancestors) in the Additional section of the response as well as NSEC 304 records proving the non-existence of any other applicable DLV records 305 in the DLV domain. Authoritative servers need only include DLV 306 RRsets they're aware of -- RRsets in sub-zones may be omitted. 308 Validators still seek out of the closest enclosing DLV RRset first. 309 If they receive any data about other DLV RRsets in the zone, they MAY 310 cache and use it (assuming that it validates), thus avoiding further 311 round-trips to the DLV domain's authoritative servers. 313 9. Security Considerations 315 Validators MUST NOT use a DLV record unless it has been successfully 316 authenticated. Normally, validators will have a trust anchor for the 317 DLV domain and use DNSSEC to validate the data in it. 319 Aggressive negative caching increases the need for validators to do 320 some basic validation of incoming NSEC records before caching them. 321 In particular, the 'next name' field in the NSEC record MUST be 322 within the zone that generated (and signed) the NSEC. Otherwise, a 323 malicious zone operator could generate an NSEC that reaches out of 324 its zone -- into its ancestor zones, even up into the root zone -- 325 and use that NSEC to spoof away any name that sorts after the name of 326 the NSEC. We call these overreaching NSECs. More insidiously, an 327 attacker could use an overreaching NSEC in combination with a signed 328 wildcard record to substitute a signed positive answer in place of 329 the real data. This checking is not a new requirement -- these 330 attacks are a risk even without aggressive negative caching. 331 However, aggressive negative caching makes the checking more 332 important. Before aggressive negative caching, NSECs were cached 333 only as metadata associated with a particular query. An overreaching 334 NSEC that resulted from a broken zone signing tool or some 335 misconfiguration would only be used by a cache for those queries that 336 it had specifically made before. Only an overreaching NSEC actively 337 served by an attacker could cause misbehavior. With aggressive 338 negative caching, an overreaching NSEC can cause more broader 339 problems even in the absence of an active attacker. This threat can 340 be easily mitigated by checking the bounds on the NSEC. 342 As a reminder, validators MUST NOT use the mere presence of an RRSIG 343 or apex DNSKEY RRset as a trigger for doing validation, whether 344 through the normal DNSSEC hierarchy or DLV. Otherwise, an attacker 345 might perpetrate a downgrade attack by stripping off those RRSIGs or 346 DNSKEYs. 348 RFC4034 Section 8 describes security considerations specific to the 349 DS RR. Those considerations are equally applicable to DLV RRs. Of 350 particular note, the key tag field is used to help select DNSKEY RRs 351 efficiently, but it does not uniquely identify a single DNSKEY RR. 352 It is possible for two distinct DNSKEY RRs to have the same owner 353 name, the same algorithm type, and the same key tag. An 354 implementation that uses only the key tag to select a DNSKEY RR might 355 select the wrong public key in some circumstances. 357 For further discussion of the security implications of DNSSEC see 358 RFC4033, RFC4034, and RFC4035. 360 10. IANA Considerations 362 This document has no IANA actions. 364 DLV makes use of the DLV resource record previously assigned by IANA. 366 11. References 368 11.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 374 Rose, "DNS Security Introduction and Requirements", 375 RFC 4033, March 2005. 377 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 378 Rose, "Resource Records for the DNS Security Extensions", 379 RFC 4034, March 2005. 381 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 382 Rose, "Protocol Modifications for the DNS Security 383 Extensions", RFC 4035, March 2005. 385 [RFC4431] Andrews, M. and S. Weiler, "The DNSSEC Lookaside 386 Validation (DLV) DNS Resource Record", RFC 4431, 387 February 2006. 389 11.2. Informative References 391 [I-D.ietf-dnsext-nsec3] 392 Laurie, B., "DNSSEC Hashed Authenticated Denial of 393 Existence", draft-ietf-dnsext-nsec3-11 (work in progress), 394 July 2007. 396 [INI1999-19] 397 Weiler, S., "Deploying DNSSEC Without a Signed Root", 398 Technical Report 1999-19, Information Networking 399 Institute, Carnegie Mellon University, April 2004. 401 [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC Records 402 and DNSSEC On-line Signing", RFC 4470, April 2006. 404 Appendix A. Acknowledgments 406 Johan Ihren, Paul Vixie, and Suzanne Woolf contributed significantly 407 to the exploration of possible validator algorithms that led to this 408 design. More about those explorations is documented in [INI1999-19]. 410 Johan Ihren and the editor share the blame for aggressive negative 411 caching. 413 Thanks to David B. Johnson and Marvin Sirbu for their patient review 414 of [INI1999-19] which led to this specification being far more 415 complete. 417 Thanks to Mark Andrews, Rob Austein, David Blacka, Stephane 418 Bortzmeyer, Steve Crocker, Wes Hardaker, Alfred Hoenes, Russ Housley, 419 Peter Koch, Olaf Kolkman, Juergen Quittek, and Suzanne Woolf for 420 their valuable comments on this document. 422 Author's Address 424 Samuel Weiler 425 SPARTA, Inc. 426 7110 Samuel Morse Drive 427 Columbia, Maryland 21046 428 US 430 Email: weiler@tislabs.com 432 Full Copyright Statement 434 Copyright (C) The IETF Trust (2007). 436 This document is subject to the rights, licenses and restrictions 437 contained in BCP 78, and except as set forth therein, the authors 438 retain all their rights. 440 This document and the information contained herein are provided on an 441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 443 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 444 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 445 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 448 Intellectual Property 450 The IETF takes no position regarding the validity or scope of any 451 Intellectual Property Rights or other rights that might be claimed to 452 pertain to the implementation or use of the technology described in 453 this document or the extent to which any license under such rights 454 might or might not be available; nor does it represent that it has 455 made any independent effort to identify any such rights. Information 456 on the procedures with respect to rights in RFC documents can be 457 found in BCP 78 and BCP 79. 459 Copies of IPR disclosures made to the IETF Secretariat and any 460 assurances of licenses to be made available, or the result of an 461 attempt made to obtain a general license or permission for the use of 462 such proprietary rights by implementers or users of this 463 specification can be obtained from the IETF on-line IPR repository at 464 http://www.ietf.org/ipr. 466 The IETF invites any interested party to bring to its attention any 467 copyrights, patents or patent applications, or other proprietary 468 rights that may cover technology that may be required to implement 469 this standard. Please address the information to the IETF at 470 ietf-ipr@ietf.org. 472 Acknowledgment 474 Funding for the RFC Editor function is provided by the IETF 475 Administrative Support Activity (IASA).