idnits 2.17.00 (12 Aug 2021) /tmp/idnits50577/draft-ietf-dnsop-delegation-only-01.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 RFC4035, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4035, updated by this document, for RFC5378 checks: 2002-10-29) -- 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 (July 13, 2020) is 677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DNSSEC' is mentioned on line 82, but not defined == Missing Reference: 'TBD' is mentioned on line 420, but not defined -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP P. Wouters 3 Internet-Draft Red Hat 4 Updates: 4035 (if approved) W. Hardaker 5 Intended status: Informational USC/ISI 6 Expires: January 14, 2021 July 13, 2020 8 The DELEGATION_ONLY DNSKEY flag 9 draft-ietf-dnsop-delegation-only-01 11 Abstract 13 This document introduces a new DNSKEY flag called DELEGATION_ONLY 14 that indicates that this zone will only produce delegation responses 15 for data outside of its own apex (or _underscore labels). That is, 16 the Answer Section for queries that do not involve the apex (or 17 _underscore labels) of the zone is empty, and only glue records in 18 the Authority Section and Additional Section will be acceptable data 19 in the response message. Additionally, it indicates that it is not 20 expected that the parent of this delegation-only zone bypasses or 21 removes the delegation to this zone. DNSSEC Validating Resolvers can 22 use this flag to mark any data that violates the DELEGATION_ONLY 23 policy as Bogus. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 14, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The Deep Signing problem . . . . . . . . . . . . . . . . . . 3 62 3.1. Affected parties and their roles . . . . . . . . . . . . 4 63 4. The DELEGATION_ONLY DNSKEY flag . . . . . . . . . . . . . . . 5 64 5. _underscore label exception . . . . . . . . . . . . . . . . . 6 65 6. Parental Transparency . . . . . . . . . . . . . . . . . . . . 6 66 7. Marking zone keys DELEGATION_ONLY . . . . . . . . . . . . . . 6 67 7.1. Marking the Root DNSKEY DELEGATION_ONLY . . . . . . . . . 7 68 7.2. Migrating to and from DELEGATION_ONLY . . . . . . . . . . 7 69 8. Operational Considerations . . . . . . . . . . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 72 11. Human Rights Considerations . . . . . . . . . . . . . . . . . 9 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 14.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 The DNS Security Extensions [DNSSEC] use public key cryptography to 83 create an hierarchical trust base with the DNSSEC root public keys at 84 the top, followed by Top Level domain (TLD) keys one level 85 underneath. While the root and most TLD zones are assumed to be 86 exclusively delegation-only zones, there is currently no 87 interoperable and automatable mechanism for auditing these zones to 88 ensure they behave as a delegation-only zone. This creates a target 89 for malicious use of these zones - either by their owners or through 90 coercion. 92 This document defines a mechanism for delegation-only zone owners to 93 create a DNSKEY that indicates it will only delegate the remainder of 94 the DNS tree to lower-level zones. This allows for easier delegation 95 policy verification and logging and auditing of DNS responses served 96 by their infrastructure. 98 Specifically, this document introduces a new DNSKEY flag allowing 99 zone owners to commit to only signing records relating to delegation. 100 If a DNSSEC validator discovers any non-delegation zone data signed 101 by a flagged key, this data can be interpreted as Bogus. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 3. The Deep Signing problem 113 The hierarchical model of DNS and DNSSEC ([RFC1034], [RFC1035], 114 [RFC4033], [RFC4034] and [RFC4035]) comes with the property that a 115 zone at one point in the hierarchy can define, and therefor override, 116 everything below it in the DNS tree. And this is possible to achieve 117 on a per-client basis. 119 For example, the owner of the DNSSEC root key could generate a 120 specially crafted zone file that ignores the intended NS records for 121 ".org" and "example.org". It could place an AAAA record for 122 "www.example.org" directly into the specially crafted root zone, with 123 a corresponding RRSIG signed by the root DNSKEY itself. Validating 124 resolvers would find this record perfectly acceptable, as it was 125 signed by a key within the proper chain of trust (in this case, a 126 root DNSKEY). This specially crafted zone could then even be served 127 to specific clients in an effort to subvert a portion of the DNS 128 ecosystem for a portion of the Internet. 130 Similarly, the TLD "example" could circumvent company.example for 131 certain clients. It is important to note that this can be done 132 without changing the upstream DS record or trust anchor -- the DNSKEY 133 is (again) already in the trust path and is merely signing deeper DNS 134 records than the zone owner's clients may have expected it to sign. 136 It is important to note that this "feature" has always been present. 137 Since the creation of the DNS, it has always been possible to serve 138 "split zones". Specifically, it is not a problem created by DNSSEC 139 -- DNSSEC was not designed to protect against this use case. 141 Exposing such targeted attacks requires a transparency audit 142 infrastructure similar to what is deployed for PKIX ([RFC6962]). 143 However, a DNSSEC version would need to log significantly more data, 144 as all signed DNS data used by a DNSKEY must be recorded in order to 145 prove that data signed by a parent zone's DNSKEY was out of expected 146 policy. The very distributed nature of the DNS combined with the 147 typically frequent zone resigning rate makes such transparency logs 148 prohibitively expensive and nearly impossible to operate. 150 Additionally, it would require zone owners to expose all their zone 151 data to any public log operators, thereby introducing privacy 152 implications and exposing all relevant DNS data to a public archive. 153 This may be acceptable for some domains, such as the root, where DNS 154 data is already considered public. However, other delegation domains 155 have legal implications that prohibit them from participating in such 156 a system. 158 Furthermore, there is no signalling mechanism that lets validating 159 resolvers know which zones are supposedly delegation-only, and what 160 zones can be logged. Today there are over 1500 TLDs in the root 161 zone, some of which may be considered delegation-only while others 162 may not be. At the time of this writing, the list of entries in the 163 public suffix list contains over 8800 entries as well, with 73 wild- 164 card entries (prefixed with a "*") indicating that all of their 165 (unknown number of) children are public registration points. In the 166 absence of an interoperable mechanism (like this draft provides), it 167 is infeasible that a validating resolver or auditing log could know 168 which of these zones are delegation-only without individual policy 169 statements from each of them. [todo: xref psl] 171 3.1. Affected parties and their roles 173 Upon deployment of this specification, the following parties would be 174 potentially benefit or be affected by: 176 Authoritative parent: If (and only if) an authoritative parent is a 177 "delegation only" zone, it could generate a DNSKEY with the 178 DELEGATION_ONLY flag set, indicating a verifiable promise to the 179 world that will not sign any records other than delegation records. 181 Authoritative Child / Delegated Zone: child zones existing underneath 182 a marked delegation-only zone get the added benefit of knowing their 183 parent will not (and cannot) sign DNS records within the child's 184 portion of the DNS tree using the marked DNSKEY. 186 Validating Resolver: A validating resolver that supports verifying 187 the DELEGATION_ONLY flag is capable of rejecting or discarding any 188 data from an authoritative parent that incorrectly signs non- 189 delegation records too low in the DNS tree. If the validating 190 resolver supports a (future-defined) DNSSEC transparency audit log as 191 well, it may submit the appropriate data to a DNSSEC transparency log 192 that appropriately tracks DNSSEC signatures. 194 DNSSEC Transparency Log (optional future): a DNSSEC transparency log 195 would create a non-modifiable trace of log entries submitted to it, 196 for public verification, similar to [RFC6962]. What it chooses to 197 accept into its log might be only certain zone data, or any zone with 198 a marked DNSKEY. 200 Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still 201 useful per the discussion in the Validating Resolvers role: the 202 resolver will reject incorrectly signed, non-delegation data. 203 However, malicious parent zones are still capable of creating two (or 204 more) DNSKEYs, one with the DELEGATION_ONLY flag and one without. 205 However, they would also have to publish those DS records as well, 206 which is detectable by DNSSEC monitoring platforms, regardless of the 207 existence of a DNSSEC Transparency Log. Any zone with multiple DS 208 records that link to both a DELEGATION_ONLY marked and an unmarked 209 DNSKEY would be considered suspicious (or at least in transition). 210 Circumventing this through obfuscation would require the collusion of 211 their parent as well. Finally, a DELEGATION_ONLY flagged DNSKEY for 212 the root zone cannot be overridden easily, as it would require a 213 trust anchor update in all validating resolvers. 215 4. The DELEGATION_ONLY DNSKEY flag 217 This document introduces a new DNSKEY flag called DELEGATION_ONLY. 218 When this flag is set on a DNSKEY with its Secure Entry Point (SEP) 219 flag set, the zone commits to only produce Authoritative Answers for 220 the apex (and _underscore label) records. Note that DS records and 221 its DNSSEC signatures are still allowed as this data is authoritative 222 at the parent, not the child. This commits a parent in the DNS 223 hierarchy to only publish signed DS records and unsigned glue records 224 (NS and A/AAAA) for its child zones. It will no longer be able to 225 ignore (or briefly delete, see below) a child delegation and publish 226 authoritative data in its place. 228 For such a parent to take over data that belongs to its child zone, 229 it has two choices. It can (temporarily) remove its own DNSKEY 230 DELEGATION_ONLY flag or it can replace the NS and DS records of its 231 child zone with its own data (destinations and key references) so it 232 can sign DNS data that belongs to its own child zone. However, both 233 of these actions cannot be hidden, thus exposing such malicious 234 behaviour when combined with DNSSEC Transparency logs. 236 A zone that publishes a DNSKEY with the DELEGATION_ONLY flag also 237 signifies that it is not expecting its own parent to skip it, thereby 238 bypassing its DELEGATION_ONLY flag. 240 5. _underscore label exception 242 Some protocols, such as the DANE protocol [RFC6698] use a number of 243 labels that start with an underscore (_) prefix to publish 244 information about the zone itself. For example, the TLSA record for 245 www.example.com is published at the location 246 _443._tcp.www.example.com. These records are semantically part of 247 the zone itself and are not delegated child zones. Any chain of 248 labels that each start with an underscore (_) is not considered to 249 violate the DELEGATION_ONLY flag limitation of being DELEGATION_ONLY, 250 as this data is logically part of the zone itself and is never meant 251 to be interpreted as an independent delegated child zone. 253 6. Parental Transparency 255 A parent zone, such as the root zone, a TLD or any public suffix list 256 delegation point, that has published a key with the DELEGATION_ONLY 257 flag can no longer make an exception for a single delegated zone 258 without removing the DELEGATION_ONLY flag, switching off its 259 published policy. This action would be highly visible, and for some 260 domains such as the root or TLDs, require human interaction to notify 261 the stake holders to prevent loss of trust. 263 Removing the DELEGATION_ONLY flag from a DNSKEY requires that the 264 zone first publishes an additional updated DS record to its parent. 266 In the case of the root key, it would require updating out-of-band 267 root key meta information and/or perform an [RFC5011] style rollover 268 for the same key with updated DNSKEY flags. Due to the timings of 269 such a rollover, it would take at least 30 days for the first 270 validating resolvers to pick up this policy change. It would also be 271 a highly visible event. 273 Replacing the NS and DS records of a child zone can still be done in 274 a targeted attack mode, but these events are something that can be 275 easily tracked by a transparency infrastructure similar to what is 276 now in use for the WebPKI using [RFC6962](bis). With client 277 implementations of transparency, all DELEGATION_ONLY flag changes 278 would be logged and become visible to the owner of attacked child 279 zones, exposing a parent's malicious behaviour. 281 7. Marking zone keys DELEGATION_ONLY 283 Even before a parent DNSKEY (or the root key) has set the 284 DELEGATION_ONLY flag, zones can already signal their own willingness 285 to commit to being DELEGATION_ONLY zones. Any changes of that state 286 in a zone DNSKEY will require those zones to submit a new DS record 287 to their parent. Setting the DELEGATION_ONLY flag would trigger 288 DNSSEC Transparency clients to start monitoring for actions by the 289 zone or its parents that would be bypassing the DELEGATION_ONLY 290 policy of the zone. Validating resolvers would mark any data in 291 violation of the DELEGATION_ONLY policy as Bogus. 293 7.1. Marking the Root DNSKEY DELEGATION_ONLY 295 Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and 296 deployed resolvers are configured with the new DNSKEY, all TLDs will 297 be ensured that the Root DNSKEY can no longer be abused to override 298 child zone data. Until the Root KSK DNSKEY sets this flag, software 299 SHOULD imply this flag is always set, as this is the current 300 expectation of the Root Zone. 302 7.2. Migrating to and from DELEGATION_ONLY 304 There might be multiple DNSKEYs with the SEP flag set in a zone. For 305 the purpose of declaring a zone as DELEGATION_ONLY, only those 306 DNSKEY's that have a corresponding DS record at the parent MUST be 307 considered. If multiple DS records appear at the parent, some of 308 which point to DNSKEYs with and some of which point to DNSKEYs 309 without the DELEGATION_ONLY flag set, the zone MUST be considered 310 DELEGATION_ONLY. This situation will occur when a zone is rolling 311 its DNSKEY key at the same time as it is committing to a 312 DELEGATION_ONLY zone (or the reverse). 314 8. Operational Considerations 316 Setting or unsetting the DELEGATION_ONLY flag must be handled like 317 any other Key Signing Key rollover procedure, with the appropriate 318 wait times to give resolvers the chance to update their caches. 320 Some TLDs offer a service where small domains can be hosted in-zone 321 at the TLD zone itself. In that case, the TLD MUST NOT set the 322 DELEGATION_ONLY flag. Another solution for such TLDs is to create 323 delegations for these child zones with the same or different DNSKEY 324 as used in the parent zone itself. 326 If a zone is publishing glue records for a number of zones, and the 327 zone that contains the authoritative records for this glue is 328 deleted, a resigning of the zone will make this orphaned glue 329 authoritative within the zone. However, with the DELEGATION_ONLY 330 flag set, this (signed) DNSSEC data will be considered Bogus as it 331 violations the commitment to only delegate. This may impact domains 332 that depended on this unsigned glue. Note that glue handling differs 333 per zone. Some TLDs already remove the glue records if no 334 authoritative child is left in its zone that matches these glue 335 records. 337 For example, if "example.com" and "example.net" use NS records 338 pointing to "ns.example.net", then if "example.net" is deleted from 339 the ".net" zone, and the previously unsigned glue of "ns.example.net" 340 is now signed by the ".net" zone, the "example.com" zone will lose 341 its NS records and fail to resolve. 343 The use of Empty Non Terminals (ENT) is fine, as long as the ENT's 344 ends in a proper delegation with NS (and hopefully DS) records. 346 Some TLDs publish their nameserver (NS) records straight within their 347 TLD (eg "ns1.example") which makes these names indistinguishable from 348 real delegations with respect to the DELEGATION_ONLY flag. These NS 349 entries would have to be moved to their own delegation zone (eg 350 "ns1.nic.example") which in itself cannot be a DELEGATION_ONLY zone. 352 Some TLDs have a requirement for certain Fully Qualified Domain Names 353 (FQDN) within their TLD, such as "whois.example" or "nic.example". 354 These usually appear as signed data of the TLD and not as a delegated 355 child zone. These names would have to be converted to delegated 356 zones before enabling the DELEGATION_ONLY flag. 358 The bind DNS software has an option called "delegation_only zones" 359 which is an option that means something completely different. It 360 refers to ignoring wildcard records in specified zones that are 361 deemed delegation-only zones. 363 9. Security Considerations 365 Some parental attacks cannot be detected when the validating 366 resolver's cache is empty. Care should be taken by resolvers to not 367 unnecessarily empty their cache. This is specifically important for 368 roaming clients that re-connect frequently to different wireless or 369 mobile data networks. 371 Resolvers should be aware of DELEGATION_ONLY status of a parental 372 domain and not consume Authoritative or Additional sections with data 373 that is placed to attempt to bypass the DELEGATION_ONLY restriction. 374 If "example.org" is a DELEGATION_ONLY zone, and a query for 375 "www.example.org" results in non-authoritative data for A records for 376 "www.example.org" or "mail.example.org", these records should be 377 rejected as Bogus, irrespective of whether these were signed by the 378 appropriate "example.org" DNSSEC key. 380 This DELEGATION_ONLY mechanism is not designed to completely foil 381 attacks (since parent's can simply change a child's referral data), 382 but rather to empower transparency logging mechanisms. 384 10. Privacy Considerations 386 Some of the protection offered by the DELEGATION_ONLY flag is only 387 available when DNS resolvers report changes in the signing depth of 388 high level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This 389 reporting can reveal that a particular node is trying to access a 390 certain DNS name. Defensive measures to prevent exposing users 391 should be taken when implementing DNSSEC Transparency. It is 392 expected that DNSSEC Transparency behaviour will be written up in a 393 separate document. 395 11. Human Rights Considerations 397 The DNS protocol's hierarchy limits zones authority to themselves and 398 their child zones only. While this provides a finer grained trust 399 model compared to a simple list of trusted entities, such as used in 400 the WebPKI, it consolidates a lot of power in the top of the DNS 401 hierarchy. With the increased reliance on DNSSEC for securely 402 identifying resources, such as DANE records, it becomes very 403 important to audit those entities high up in the hierarchy to not 404 abuse or be co-erced into abusing control of the independent child 405 zones. The protocol extension specifically aims at increasing 406 parental transparency and blocks some parental attacks from those 407 parents who have publicly claimed to never override their child zone 408 data. 410 Parents using the DELEGATION_ONLY flag publication to increase their 411 public trust are still able to remove child zones from their zone, 412 for example in cases of legal compliance or to prevent malicious 413 activity happening in its child zone. But these parents can only do 414 so publicly and can no longer surreptitiously take control of their 415 own child zones. 417 12. IANA Considerations 419 This document defines a new DNSKEY flag, the DELEGATION_ONLY flag, 420 whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS 421 Registry. 423 13. Acknowledgements 425 The authors wishes to thank Thomas H. Ptacek for his insistence on 426 this matter. 428 Thanks to the following IETF participants: Viktor Dukhovni, Shumon 429 Huque, Geoff Huston, Rick Lamb Sam Weiler and Paul Vixie. 431 14. References 433 14.1. Normative References 435 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 436 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 437 . 439 [RFC1035] Mockapetris, P., "Domain names - implementation and 440 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 441 November 1987, . 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 449 Rose, "Protocol Modifications for the DNS Security 450 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 451 . 453 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 454 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 455 September 2007, . 457 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 458 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 459 May 2017, . 461 14.2. Informative References 463 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 464 Rose, "DNS Security Introduction and Requirements", 465 RFC 4033, DOI 10.17487/RFC4033, March 2005, 466 . 468 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 469 Rose, "Resource Records for the DNS Security Extensions", 470 RFC 4034, DOI 10.17487/RFC4034, March 2005, 471 . 473 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 474 of Named Entities (DANE) Transport Layer Security (TLS) 475 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 476 2012, . 478 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 479 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 480 . 482 Authors' Addresses 484 Paul Wouters 485 Red Hat 487 Email: pwouters@redhat.com 489 Wes Hardaker 490 USC/ISI 491 P.O. Box 382 492 Davis, CA 95617 493 US 495 Email: ietf@hardakers.net