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