idnits 2.17.00 (12 Aug 2021) /tmp/idnits38935/draft-larson-dnsop-trust-anchor-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 365. 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 copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (November 13, 2007) is 5302 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations M. Larson 3 Internet-Draft VeriSign 4 Expires: May 16, 2008 O. Gudmundsson 5 OGUD Consulting LLC 6 November 13, 2007 8 DNSSEC Trust Anchor Configuration and Maintenance 9 draft-larson-dnsop-trust-anchor-02 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 16, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document recommends a preferred format for specifying trust 43 anchors in DNSSEC validating security-aware resolvers and describes 44 how such a resolver should initialize trust anchors for use. This 45 document also describes different mechanisms for keeping trust 46 anchors up to date over time. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Trust Anchor Format . . . . . . . . . . . . . . . . . . . . . 4 52 3. Trust Anchor Priming . . . . . . . . . . . . . . . . . . . . . 5 53 4. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . . 7 54 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 56 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 57 8. Internationalization considerations . . . . . . . . . . . . . 11 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 59 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 60 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 62 Intellectual Property and Copyright Statements . . . . . . . . . . 14 64 1. Introduction 66 The DNSSEC standards documents ([2], [3] and [4]) describe the need 67 for trust anchors and how they are used. A validating security-aware 68 resolver (subsequently referred to as a "validating resolver") needs 69 to be configured with one or more trust anchors, which specify the 70 public keys of signed zones. To authenticate DNS data, a validating 71 resolver builds a chain of trust from a configured trust anchor to 72 that data. 74 In a widespread public DNSSEC deployment, the DNS root zone would be 75 signed and a validating resolver would need to be configured with at 76 least the root zone's trust anchor. A validating resolver might need 77 additional trust anchors configured to accommodate islands of 78 security. (An island of security is a signed, delegated zone that 79 does not have an authentication chain from its delegating parent.) 80 For example, consider the situation where the root zone is signed but 81 a given top-level domain (TLD) zone is not. Various second-level 82 zones under this unsigned TLD might be signed and resolver operators 83 might want to validate responses from those zones, requiring a 84 validating resolver to be configured with those zones' trust anchors. 86 Because many validating resolvers would be configured with trust 87 anchors in a widespread DNSSEC deployment, there is a benefit to 88 creating a common trust anchor format. A similar situation has 89 occurred with the "root hints", the list of root name server names 90 and IP addresses: this information is distributed in standard master 91 file format and many resolver implementations support this common 92 format. 94 To simplify this trust anchor configuration process that will occur 95 on a large number of resolvers, this document offers guidance to 96 validating resolver implementers by specifying a standardized format 97 for describing trust anchors. The document also describes how a 98 validating resolver should initialize or "prime" trust anchors before 99 first use. Finally, the document lists options for keeping trust 100 anchor information current over time. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [1]. 106 2. Trust Anchor Format 108 A trust anchor is a DNSSEC public key configured in a validating 109 resolver. A validating resolver's configuration MUST allow one or 110 more trust anchors to be specified. According to the definition in 111 Section 2 of RFC 4033 [2], a trust anchor can be specified as either 112 a DNSKEY resource record (RR) or a DS RR, which contains the hash of 113 the specific DNSKEY RR. (DS records are defined in Section 5 of RFC 114 4034 [3].) 116 This document RECOMMENDS that a trust anchor be specified as a DS RR. 117 A DS RR used to specify a trust anchor in this manner SHOULD use a 118 digest algorithm of SHA-256 [5], which is DS digest type 2. DS RRs 119 using SHA-1 (DS digest type 1) to specify trust anchors are NOT 120 RECOMMENDED: RFC 4509 encourages the use of DS RRs using SHA-256 over 121 those using SHA-1. 123 Specifying a trust anchor using a DS RR instead of a DNSKEY RR offers 124 a slight advantage because it forces the resolver to make a DNS query 125 to obtain the trust anchor's complete DNSKEY RRSet during a priming 126 operation (described below). If only a DNSKEY record were specified, 127 a resolver implementers could conceivably avoid priming the trust 128 anchor. But priming is desirable because it causes the resolver to 129 retrieve an up-to-date version of a zone's DNSKEY RRSet from one of 130 the zone's authoritative servers. It should be noted that in 131 practice, priming is almost always required because data in the trust 132 anchor zone will usually be signed with a different key than the one 133 configured as the trust anchor, thus requiring the validating 134 resolver to obtain all keys in the DNSKEY RRSet. 136 Using a DS RR is also recommended because it is smaller than the 137 DNSKEY RR and is easier to enter manually, either by typing or 138 cutting and pasting. 140 Another advantage of configuring a trust anchor using a DS RR is that 141 the entire hash of the public key in the DS RDATA need not 142 necessarily be specified. A validating resolver MAY support 143 configuration using a truncated DS hash value as a human-factors 144 convenience: shorter strings are easier to type and less prone to 145 error when entered manually. Even with a truncated hash configured, 146 a validating resolver can still verify that the corresponding DNSKEY 147 is present in the trust anchor zone's apex DNSKEY RRSet. 149 3. Trust Anchor Priming 151 A validating resolver needs to obtain and validate the DNSKEY RRSet 152 corresponding to a configured DS RR for that trust anchor to be 153 usable in DNSSEC validation. This process is called "priming" the 154 trust anchor. Priming can occur when the validating resolver starts, 155 but a validating resolver SHOULD defer priming of individual trust 156 anchors until each is first needed for verification. This priming on 157 demand is especially important when a validating resolver is 158 configured with a large number of trust anchors to avoid sending a 159 large number of DNS queries on start-up. This section adds 160 additional details to the discussion of trust anchors in Section 5 of 161 RFC 4035 [4]. 163 Following are the steps a validating resolver SHOULD take to prime a 164 configured trust anchor: 166 1. Read the trust anchor's DS RR from the validating resolver's 167 configuration (e.g., a text file). 169 2. Look up the DNSKEY RRSet corresponding to the owner name of the 170 DS RR. (The validating resolver can either perform iterative 171 resolution or request recursive service from a recursive name 172 server, depending on its capabilities.) 174 3. Verify that the DNSKEY RR corresponding to the configured DS RR 175 (i.e., the DNSKEY whose hash appears in the DS record) appears in 176 the DNSKEY RRSet and that the DNSKEY RR has the Zone Key Flag 177 (DNSKEY RDATA bit 7) set. 179 4. Verify that the DNSKEY RRSet is signed by one of the DNSKEYs 180 found in the previous step, i.e., that there exists a valid RRSIG 181 (cryptographically and temporally) for the DNSKEY RRSet generated 182 with the private key corresponding to the DNSKEY found in the 183 previous step. 185 If the validating resolver can successfully complete the steps above, 186 all DNSKEY RRs in the RRSet ought to be considered authenticated and 187 used authenticate RRSets at or below the trust anchor. 189 If any of the steps above result in an error, the validating resolver 190 SHOULD log them. 192 If there are multiple trust anchors configured for a zone, any one of 193 them is sufficient to validate data in the zone. For this reason, 194 old trust anchors SHOULD be removed from a validating resolver's 195 trust anchor list soon after the corresponding keys are no longer 196 used by the zone. A validating resolver should remove a trust anchor 197 that has been revoked as indicated by the REVOKE bit in the 198 corresponding DNSKEY record as described in RFC 5011. RFC5011 [6] 200 If a validating resolver is unable to to retrieve a signed DNSKEY 201 RRSet corresponding to a trust anchor (i.e., prime the trust anchor), 202 it SHOULD log this condition as an error. Inability to prime a 203 zone's trust anchor will likely result in the validating resolver's 204 inability to validate data from the corresponding zone and cause the 205 resolver to return an error in response to the original DNS query. 207 4. Trust Anchor Maintenance 209 Trust anchors correspond to zones' key signing keys and these keys do 210 change in the course of normal operation. Validating resolver 211 operators MUST ensure that configured trust anchor information 212 remains current and does not go stale: each configured trust anchor 213 DS RR SHOULD correspond to a DNSKEY RR in the trust anchor zone's 214 apex DNSKEY RRSet. This process is called trust anchor maintenance. 215 (Initial trust anchor configuration requires human intervention to 216 verify the trust anchor's authenticity using out-of-band means and is 217 outside the scope of this document.) 219 This section provides a brief overview of some possible mechanisms to 220 keep trust anchor information current: 222 Manual configuration: The validating resolver operator MAY choose to 223 maintain trust anchor information completely manually. In this 224 case, the operator assumes responsibility for noticing stale trust 225 anchor information (i.e., DS records that no longer point to a 226 corresponding DNSKEY RR in the trust anchor zone's apex DNSKEY 227 RRSet) and updating that information. This process MAY require 228 the operator to use the same out-of-band verification mechanism 229 used to initial configuration to ensure that the new trust anchor 230 DS RR is trustworthy. Because manual maintenance is burdensome 231 and prone to error, and because other automated trust anchor 232 maintenance processes either exist or are in development, manual 233 trust anchor maintenance is NOT RECOMMENDED. 235 DNSSEC In-band Update: The IETF DNS Extensions Working Group has 236 developed a protocol to automatically update DNSSEC trust anchors, 237 which is described in RFC 5011. RFC5011 [6] This protocol relies 238 on a small DNSSEC protocol change (an additional flag in the 239 DNSKEY record) and can be implemented either in a validating 240 resolver itself or in an external program with access to the 241 validating resolver's trust anchor configuration data. 243 Trusted update mechanism: Updated trust anchor information MAY be 244 obtained via a trusted non-DNS update mechanism. One possibility 245 is the operating system update mechanism provided by most software 246 vendors. Operators already place considerable trust in this 247 mechanism, so it is reasonable to extend this trust to allow 248 distribution and update of DNSSEC public key material. Another 249 possibility is to obtain trust anchor configuration directly from 250 the validating resolver software vendor. This mechanism is 251 realistically only feasible for updating a small number of trust 252 anchors, such as for the top-level domains. In a public DNSSEC 253 deployment, the root zone would be signed and only the root's 254 trust anchor would need updating. 256 5. Acknowledgments 258 This work was undertaken at the suggestion of the DNSSEC Deployment 259 working group (www.dnssec-deployment.org). 261 6. Security considerations 263 This document proposes a standard format for documenting DNSSEC trust 264 anchors. Configuration of trust anchors, especially those obtained 265 from third parties as part of an automated process, is a critical 266 security operation. The procedures described above describe the 267 minimal checks that should be performed and reporting that should be 268 done when configuring trust anchors. 270 In a widespread DNSSEC deployment, the root zone and many TLD zones 271 would be signed, thus greatly reducing the number trust anchors that 272 validating resolvers would need to store and keep track of. 274 7. IANA considerations 276 This document does not have any IANA actions. 278 8. Internationalization considerations 280 There are no new internationalization considerations introduced by 281 this memo. 283 9. References 285 9.1. Normative References 287 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 288 Levels", BCP 14, RFC 2119, March 1997. 290 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 291 "DNS Security Introduction and Requirements", RFC 4033, 292 March 2005. 294 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 295 "Resource Records for the DNS Security Extensions", RFC 4034, 296 March 2005. 298 [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 299 "Protocol Modifications for the DNS Security Extensions", 300 RFC 4035, March 2005. 302 [5] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) 303 Resource Records (RRs)", RFC 4509, May 2006. 305 [6] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 306 Anchors", RFC 5011, September 2007. 308 9.2. Informative References 309 Authors' Addresses 311 Matt Larson 312 VeriSign, Inc. 313 21345 Ridgetop Circle 314 Dulles, VA 20166-6503 315 USA 317 Email: mlarson@verisign.com 319 Olafur Gudmundsson 320 OGUD Consulting LLC 321 3821 Village Park Drive 322 Chevy Chase, MD 20815 323 USA 325 Email: ogud@ogud.com 327 Full Copyright Statement 329 Copyright (C) The IETF Trust (2007). 331 This document is subject to the rights, licenses and restrictions 332 contained in BCP 78, and except as set forth therein, the authors 333 retain all their rights. 335 This document and the information contained herein are provided on an 336 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 337 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 338 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 339 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 340 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 341 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 343 Intellectual Property 345 The IETF takes no position regarding the validity or scope of any 346 Intellectual Property Rights or other rights that might be claimed to 347 pertain to the implementation or use of the technology described in 348 this document or the extent to which any license under such rights 349 might or might not be available; nor does it represent that it has 350 made any independent effort to identify any such rights. Information 351 on the procedures with respect to rights in RFC documents can be 352 found in BCP 78 and BCP 79. 354 Copies of IPR disclosures made to the IETF Secretariat and any 355 assurances of licenses to be made available, or the result of an 356 attempt made to obtain a general license or permission for the use of 357 such proprietary rights by implementers or users of this 358 specification can be obtained from the IETF on-line IPR repository at 359 http://www.ietf.org/ipr. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights that may cover technology that may be required to implement 364 this standard. Please address the information to the IETF at 365 ietf-ipr@ietf.org. 367 Acknowledgment 369 Funding for the RFC Editor function is provided by the IETF 370 Administrative Support Activity (IASA).