idnits 2.17.1 draft-ietf-dnsop-delegation-only-02.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 (February 21, 2021) is 1153 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 413, 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: August 25, 2021 February 21, 2021 8 The DELEGATION_ONLY DNSKEY flag 9 draft-ietf-dnsop-delegation-only-02 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 August 25, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . 5 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 different "views" of the same zone name to different clients. 139 Specifically, it is not a problem created by DNSSEC -- DNSSEC was not 140 designed to protect against this use case. 142 Exposing such targeted attacks requires a transparency audit 143 infrastructure similar to what is deployed for PKIX ([RFC6962]). 144 However, a DNSSEC version would need to log significantly more data, 145 as all signed DNS data signed by a DNSKEY must be recorded in order 146 to prove that data signed by a parent zone's DNSKEY was out of 147 expected policy. The very distributed nature of the DNS combined 148 with the typically frequent zone resigning rate makes such 149 transparency logs prohibitively expensive and nearly impossible to 150 operate. 152 Furthermore, there is no signalling mechanism that lets validating 153 resolvers know which zones are supposedly delegation-only and what 154 zones can be logged. Today there are over 1500 TLDs in the root 155 zone, some of which may be considered delegation-only while others 156 may not be. At the time of this writing, the list of entries in the 157 public suffix list contains over 8800 entries as well, with 73 wild- 158 card entries (prefixed with a "*") indicating that all of their 159 (unknown number of) children are public registration points. In the 160 absence of an interoperable mechanism (like this draft provides), it 161 is infeasible that a validating resolver or auditing log could know 162 which of these zones are delegation-only without individual policy 163 statements from each of them. [todo: xref psl] 165 3.1. Affected parties and their roles 167 Upon deployment of this specification, the following parties would be 168 potentially benefit or be affected by: 170 Authoritative parent: If (and only if) an authoritative parent is a 171 "delegation only" zone, it could generate a DNSKEY with the 172 DELEGATION_ONLY flag set, indicating a verifiable promise to the 173 world that will not sign any records other than delegation records. 175 Authoritative Child / Delegated Zone: child zones existing underneath 176 a marked delegation-only zone get the added benefit of knowing their 177 parent will not (and cannot) sign DNS records within the child's 178 portion of the DNS tree using the marked DNSKEY. 180 Validating Resolver: A validating resolver that supports verifying 181 the DELEGATION_ONLY flag is capable of rejecting or discarding any 182 data from an authoritative parent that incorrectly signs non- 183 delegation records too low in the DNS tree. If the validating 184 resolver supports a (future-defined) DNSSEC transparency audit log as 185 well, it may submit the appropriate data to a DNSSEC transparency log 186 that appropriately tracks DNSSEC signatures. 188 DNSSEC Transparency Log (optional future): a DNSSEC transparency log 189 would create a non-modifiable trace of log entries submitted to it, 190 for public verification, similar to [RFC6962]. What it chooses to 191 accept into its log might be only certain zone data, or any zone with 192 a marked DNSKEY. 194 Note that without a DNSSEC Log, the DELEGATION_ONLY flag is still 195 useful per the discussion in the Validating Resolvers role: the 196 resolver will reject incorrectly signed, non-delegation data. 197 However, malicious parent zones are still capable of creating two (or 198 more) DNSKEYs, one with the DELEGATION_ONLY flag and one without. 199 However, they would also have to publish those DS records as well, 200 which is detectable by DNSSEC monitoring platforms, regardless of the 201 existence of a DNSSEC Transparency Log. Any zone with multiple DS 202 records that link to both a DELEGATION_ONLY marked and an unmarked 203 DNSKEY would be considered suspicious (or at least in transition). 204 Circumventing this through obfuscation would require the collusion of 205 their parent as well. 207 4. The DELEGATION_ONLY DNSKEY flag 209 This document introduces a new DNSKEY flag called DELEGATION_ONLY. 210 When this flag is set on a DNSKEY that is a trust anchor with a 211 corresponding DS record at its parent, the zone commits to only 212 produce Authoritative Answers for the apex (and _underscore label) 213 records. Note that DS records and its DNSSEC signatures are still 214 allowed as this data is authoritative at the parent, not the child. 215 This commits a parent in the DNS hierarchy to only publish signed DS 216 records and unsigned glue records (NS and A/AAAA) for its child 217 zones. It will no longer be able to ignore (or briefly delete, see 218 below) a child delegation and publish authoritative data in its 219 place. 221 For such a parent to take over data that belongs to its child zone, 222 it has two choices. It can (temporarily) remove its own DNSKEY 223 DELEGATION_ONLY flag or it can replace the NS and DS records of its 224 child zone with its own data (destinations and key references) so it 225 can sign DNS data that belongs to its own child zone. However, both 226 of these actions cannot be hidden, thus exposing such malicious 227 behaviour when combined with DNSSEC Transparency logs. 229 A zone that publishes a DNSKEY with the DELEGATION_ONLY flag also 230 signifies that it is not expecting its own parent to skip it, thereby 231 bypassing its DELEGATION_ONLY flag. 233 5. _underscore label exception 235 Some protocols, such as the DANE protocol [RFC6698] use a number of 236 labels that start with an underscore (_) prefix to publish 237 information about the zone itself. For example, the TLSA record for 238 www.example.com is published at the location 239 _443._tcp.www.example.com. These records are semantically part of 240 the zone itself and are not delegated child zones. Any chain of 241 labels that each start with an underscore (_) is not considered to 242 violate the DELEGATION_ONLY flag limitation of being DELEGATION_ONLY, 243 as this data is logically part of the zone itself and is never meant 244 to be interpreted as an independent delegated child zone. 246 6. Parental Transparency 248 A parent zone, such as the root zone, a TLD or any public suffix list 249 delegation point, that has published a key with the DELEGATION_ONLY 250 flag can no longer make an exception for a single delegated zone 251 without removing the DELEGATION_ONLY flag, switching off its 252 published policy. This action would be highly visible, and for some 253 domains such as the root or TLDs, require human interaction to notify 254 the stake holders to prevent loss of trust. 256 Removing the DELEGATION_ONLY flag from a DNSKEY requires that the 257 zone first publishes an additional updated DS record to its parent. 259 In the case of the root key, it would require updating out-of-band 260 root key meta information and/or perform an [RFC5011] style rollover 261 for the same key with updated DNSKEY flags. Due to the timings of 262 such a rollover, it would take at least 30 days for the first 263 validating resolvers to pick up this policy change. It would also be 264 a highly visible event. 266 Replacing the NS and DS records of a child zone can still be done in 267 a targeted attack mode, but these events are something that can be 268 easily tracked by a transparency infrastructure similar to what is 269 now in use for the WebPKI using [RFC6962](bis). With client 270 implementations of transparency, all DELEGATION_ONLY flag changes 271 would be logged and become visible to the owner of attacked child 272 zones, exposing a parent's malicious behaviour. 274 7. Marking zone keys DELEGATION_ONLY 276 Even before a parent DNSKEY (or the root key) has set the 277 DELEGATION_ONLY flag, zones can already signal their own willingness 278 to commit to being DELEGATION_ONLY zones. Any changes of that state 279 in a zone DNSKEY will require those zones to submit a new DS record 280 to their parent. Setting the DELEGATION_ONLY flag would trigger 281 DNSSEC Transparency clients to start monitoring for actions by the 282 zone or its parents that would be bypassing the DELEGATION_ONLY 283 policy of the zone. Validating resolvers would mark any data in 284 violation of the DELEGATION_ONLY policy as Bogus. 286 7.1. Marking the Root DNSKEY DELEGATION_ONLY 288 Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and 289 deployed resolvers are configured with the new DNSKEY, all TLDs will 290 be ensured that the Root DNSKEY can no longer be abused to override 291 child zone data. Until the Root KSK DNSKEY sets this flag, software 292 SHOULD imply this flag is always set, as this is the current 293 expectation of the Root Zone. 295 7.2. Migrating to and from DELEGATION_ONLY 297 There might be multiple DNSKEY records that are suitable to act as a 298 trustanchor for a zone. For the purpose of declaring a zone as 299 DELEGATION_ONLY, only those DNSKEY's that have a corresponding DS 300 record at the parent MUST be considered. If multiple DS records 301 appear at the parent, some of which point to DNSKEYs with and some of 302 which point to DNSKEYs without the DELEGATION_ONLY flag set, the zone 303 MUST be considered DELEGATION_ONLY. This situation will occur when a 304 zone is rolling its DNSKEY key at the same time as it is committing 305 to a DELEGATION_ONLY zone (or the reverse). 307 8. Operational Considerations 309 Setting or unsetting the DELEGATION_ONLY flag must be handled like 310 any other Key Signing Key rollover procedure, with the appropriate 311 wait times to give resolvers the chance to update their caches. 313 Some TLDs offer a service where small domains can be hosted in-zone 314 at the TLD zone itself. In that case, the TLD MUST NOT set the 315 DELEGATION_ONLY flag. Another solution for such TLDs is to create 316 delegations for these child zones with the same or different DNSKEY 317 as used in the parent zone itself. 319 If a zone is publishing glue records for a number of zones, and the 320 zone that contains the authoritative records for this glue is 321 deleted, a resigning of the zone will make this orphaned glue 322 authoritative within the zone. However, with the DELEGATION_ONLY 323 flag set, this (signed) DNSSEC data will be considered Bogus as it 324 violations the commitment to only delegate. This may impact domains 325 that depended on this unsigned glue. Note that glue handling differs 326 per zone. Some TLDs already remove the glue records if no 327 authoritative child is left in its zone that matches these glue 328 records. 330 For example, if "example.com" and "example.net" use NS records 331 pointing to "ns.example.net", then if "example.net" is deleted from 332 the ".net" zone, and the previously unsigned glue of "ns.example.net" 333 is now signed by the ".net" zone, the "example.com" zone will lose 334 its NS records and fail to resolve. 336 The use of Empty Non Terminals (ENT) is fine, as long as the ENT's 337 ends in a proper delegation with NS (and hopefully DS) records. 339 Some TLDs publish their nameserver (NS) records straight within their 340 TLD (eg "ns1.example") which makes these names indistinguishable from 341 real delegations with respect to the DELEGATION_ONLY flag. These NS 342 entries would have to be moved to their own delegation zone (eg 343 "ns1.nic.example") which in itself cannot be a DELEGATION_ONLY zone. 345 Some TLDs have a requirement for certain Fully Qualified Domain Names 346 (FQDN) within their TLD, such as "whois.example" or "nic.example". 347 These usually appear as signed data of the TLD and not as a delegated 348 child zone. These names would have to be converted to delegated 349 zones before enabling the DELEGATION_ONLY flag. 351 The bind DNS software has an option called "delegation_only zones" 352 which is an option that means something completely different. It 353 refers to ignoring wildcard records in specified zones that are 354 deemed delegation-only zones. 356 9. Security Considerations 358 Some parental attacks cannot be detected when the validating 359 resolver's cache is empty. Care should be taken by resolvers to not 360 unnecessarily empty their cache. This is specifically important for 361 roaming clients that re-connect frequently to different wireless or 362 mobile data networks. 364 Resolvers should be aware of DELEGATION_ONLY status of a parental 365 domain and not consume Authoritative or Additional sections with data 366 that is placed to attempt to bypass the DELEGATION_ONLY restriction. 367 If "example.org" is a DELEGATION_ONLY zone, and a query for 368 "www.example.org" results in non-authoritative data for A records for 369 "www.example.org" or "mail.example.org", these records should be 370 rejected as Bogus, irrespective of whether these were signed by the 371 appropriate "example.org" DNSSEC key. 373 This DELEGATION_ONLY mechanism is not designed to completely foil 374 attacks (since parent's can simply change a child's referral data), 375 but rather to empower transparency logging mechanisms. 377 10. Privacy Considerations 379 Some of the protection offered by the DELEGATION_ONLY flag is only 380 available when DNS resolvers report changes in the signing depth of 381 high level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This 382 reporting can reveal that a particular node is trying to access a 383 certain DNS name. Defensive measures to prevent exposing users 384 should be taken when implementing DNSSEC Transparency. It is 385 expected that DNSSEC Transparency behaviour will be written up in a 386 separate document. 388 11. Human Rights Considerations 390 The DNS protocol's hierarchy limits zones authority to themselves and 391 their child zones only. While this provides a finer grained trust 392 model compared to a simple list of trusted entities, such as used in 393 the WebPKI, it consolidates a lot of power in the top of the DNS 394 hierarchy. With the increased reliance on DNSSEC for securely 395 identifying resources, such as DANE records, it becomes very 396 important to audit those entities high up in the hierarchy to not 397 abuse or be co-erced into abusing control of the independent child 398 zones. The protocol extension specifically aims at increasing 399 parental transparency and blocks some parental attacks from those 400 parents who have publicly claimed to never override their child zone 401 data. 403 Parents using the DELEGATION_ONLY flag publication to increase their 404 public trust are still able to remove child zones from their zone, 405 for example in cases of legal compliance or to prevent malicious 406 activity happening in its child zone. But these parents can only do 407 so publicly and can no longer surreptitiously take control of their 408 own child zones. 410 12. IANA Considerations 412 This document defines a new DNSKEY flag, the DELEGATION_ONLY flag, 413 whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS 414 Registry. 416 13. Acknowledgements 418 The authors wishes to thank Thomas H. Ptacek for his insistence on 419 this matter. 421 Thanks to the following IETF participants: Viktor Dukhovni, Shumon 422 Huque, Geoff Huston, Rick Lamb Sam Weiler and Paul Vixie. 424 14. References 426 14.1. Normative References 428 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 429 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 430 . 432 [RFC1035] Mockapetris, P., "Domain names - implementation and 433 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 434 November 1987, . 436 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 437 Requirement Levels", BCP 14, RFC 2119, 438 DOI 10.17487/RFC2119, March 1997, 439 . 441 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 442 Rose, "Protocol Modifications for the DNS Security 443 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 444 . 446 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 447 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 448 September 2007, . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 14.2. Informative References 456 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 457 Rose, "DNS Security Introduction and Requirements", 458 RFC 4033, DOI 10.17487/RFC4033, March 2005, 459 . 461 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 462 Rose, "Resource Records for the DNS Security Extensions", 463 RFC 4034, DOI 10.17487/RFC4034, March 2005, 464 . 466 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 467 of Named Entities (DANE) Transport Layer Security (TLS) 468 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 469 2012, . 471 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 472 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 473 . 475 Authors' Addresses 477 Paul Wouters 478 Red Hat 480 Email: pwouters@redhat.com 482 Wes Hardaker 483 USC/ISI 484 P.O. Box 382 485 Davis, CA 95617 486 US 488 Email: ietf@hardakers.net