idnits 2.17.1 draft-pwouters-powerbind-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 (March 10, 2019) is 1867 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 329, 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: September 11, 2019 March 10, 2019 8 The DELEGATION_ONLY DNSKEY flag 9 draft-pwouters-powerbind-02 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 aside from records at the apex of the zone or delegation records for 16 its children. That is, every label (dot) underneath is considered a 17 zone cut and must have its own (signed) delegation. DNSSEC 18 Validating Resolvers can use this bit to mark any data that violates 19 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 http://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 September 11, 2019. 38 Copyright Notice 40 Copyright (c) 2019 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 (http://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 Link State problem . . . . . . . . . . . . . . . . . 3 58 4. The DELEGATION_ONLY DNSKEY flag . . . . . . . . . . . . . . . 3 59 4.1. _underscore label exception . . . . . . . . . . . . . . . 4 60 4.2. Parent Zone Transparency . . . . . . . . . . . . . . . . 4 61 4.3. Marking the Root DNSKEY DELEGATION_ONLY . . . . . . . . . 5 62 4.4. Migrating to and from DELEGATION_ONLY . . . . . . . . . . 5 63 4.5. Allowed record types for labels inside 64 DELEGATION_ONLY zones . . . . . . . . . . . . . . . . . . 5 65 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. Human Rights Considerations . . . . . . . . . . . . . . . . . 7 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 11.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The DNS Security Extensions [DNSSEC] use public key cryptography to 79 create a 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 TLD zones are asumed to be almost 82 exclusively delegation-only zones, there is currently no method to 83 audit these zones to ensure they behave as a delegation-only zone. 84 This creates an attractive target for malicious use of these zones - 85 either by their owners or through coercion. 87 This document defines a mechanism for zone owners, at DNSKEY creation 88 time, to indicate they will only delegate the remainder of the tree 89 to lower-level zones, allowing easier delegation policy verification, 90 logging and auditing of DNS responses they serve. 92 This document introduces a new DNSKEY flag allowing zone owners to 93 commit that the zone will never sign any DNS data aside from records 94 at the zone apex and child delegation records, and if any such signed 95 data is encountered by validating resolvers, that this data should be 96 interpreted as BOGUS. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 3. The Deep Link State problem 106 The hierarchical model of DNS and DNSSEC ([RFC4033], [RFC4034] and 107 [RFC4035]) comes with the property that a zone at one point in the 108 hierarchy can define, and therefor override, everything in the DNS 109 tree from their point and below. For example, the DNSSEC root key 110 could ignore the NS records for ".org" and "example.org" and could 111 place a record "www.example.org" directly into its own zone, with a 112 corresponding RRSIG signed by the root key itself. Even if resolvers 113 would defend against this attack by not allowing RRSIG's to span 114 across a potential zone cut, the zone operator (any level higher in 115 the hierarchy than the target victim) could briefly remove the NS and 116 DS records, and create a "legitimate" DNS entry for 117 "www.example.org", hiding the normal zone cuts. The attacker can 118 then publish DNS addresses records (e.g. A and AAAA records), as 119 well as records used for authentication (e.g. TLSA, SMIME, 120 OPENPGPKEY, SSHP or IPSECKEY records). 122 Exposing such targeted attacks would require a transparency audit 123 setup ([RFC6962]) that would need to log all signed DNS data to prove 124 that data signed by a parent zone's DNSKEY was out of expected 125 policy. The very distributed nature of the DNS makes such 126 transparency logs prohibitively expensive and nearly impossible to 127 operate. Additionally, it would require zone owners to expose all 128 their zone data to any public log operators, thereby introducing 129 privacy implications and exposing all relevant DNS data to a public 130 archive. Though this may be acceptable for some domains, such as the 131 root, where data is already public, other delegation domains have 132 legal implications that prohibit them from participating in such a 133 system. 135 4. The DELEGATION_ONLY DNSKEY flag 137 This document introduces a new DNSKEY flag called DELEGATION_ONLY. 138 When this flag is set on a DNSKEY with its Secure Entry Point (SEP) 139 bit set - that is the DNSKEY is a Key Signing Key (KSK) - the zone 140 owner commits to not sign any data aside from its records at the apex 141 of the zone and delegation records for its children. This commits a 142 parent in the DNS hierarchy to only publish signed DS records and 143 unsigned glue records (NS and A/AAAA) for its child zones. It will 144 no longer be able to ignore (or briefly delete, see below) a child 145 delegation and publish data beyond its own label by pretending the 146 next label is not a zone cut. 148 For such a parent to take over data that belongs to its child zone, 149 it has two choices. It can (temporarily) remove its own DNSKEY 150 DELEGATION_ONLY flag or it can replace the NS and DS records of its 151 child zone with its own data (destinations and key references) so it 152 can sign DNS data that belongs to its own child zone. However, both 153 of these actions cannot be hidden, thus exposing such malicious 154 behavior when combined with DNSSEC Transparency logs. 156 4.1. _underscore label exception 158 Some protocols, such as the DANE protocol [RFC6698] use a number of 159 labels that start with an underscore (_) prefix to publish 160 information about the zone itself. For example, the TLSA record for 161 example.com is published at the location _443._tcp.example.com. 162 These records are semantically part of the zone itself and are not 163 delegated child zones. Any chain of labels consisting of only labels 164 each starting with an underscore (_) under the apex of the zone is 165 not considered to violate the DELEGATION_ONLY flag limitation of 166 being DELEGATION_ONLY, as this data is logically part of the zone 167 itself and is never meant to be interpreted as an independent 168 delegated child zone. 170 4.2. Parent Zone Transparency 172 A parent zone, such as the root zone, a TLD or any public suffix list 173 delegation point, that has published a key with the DELEGATION_ONLY 174 flag can no longer make an exception for a single delegated zone 175 without removing the DELEGATION_ONLY flag, switching off its 176 published policy. This action would be highly visible, and for some 177 domains such as the root or TLDs, require human interaction to notify 178 the stake holders to prevent loss of trust. 180 Removing the DELEGATION_ONLY flag from a DNSKEY requires that the 181 zone first publishes an additional updated DS record to its parent. 183 In the case of the root key, it would require updating out-of-band 184 root key meta information and/or performing an [RFC5011] style 185 rollover for the same key with updated DNSKEY flags. Due to the 186 timings of such a rollover, it would take at least 30 days for the 187 first validating resolvers to process this policy change. It would 188 also be a highly visible event. 190 Replacing the NS and DS records of a child zone can still be done in 191 a targeted attack by a parent, but these events are something that 192 can be easily tracked by a transparency infrastructure similar to 193 what is now in use for the WebPKI using [RFC6962](bis). With client 194 implementations of transparency, all DELEGATION_ONLY flag changes 195 would be logged and become visible to the owner of attacked child 196 zones, exposing a parent's malicious actions. 198 4.3. Marking the Root DNSKEY DELEGATION_ONLY 200 Once the Root DNSKEY is marked with a DELEGATION_ONLY flag and 201 deployed resolvers are configured with the new DNSKEY, all TLDs will 202 be assured that the Root DNSKEY can no longer be abused to override 203 child zone data. Until the Root KSK DNSKEY sets this bit, software 204 SHOULD imply this bit is always set, as this is the current 205 expectation of the Root Zone. 207 4.4. Migrating to and from DELEGATION_ONLY 209 There might be multiple DNSKEYs with the SEP bit set in a zone. For 210 the purpose of declaring a zone as DELEGATION_ONLY, only those 211 DNSKEY's that have a corresponding DS record at the parent MUST be 212 considered. If multiple DS records appear at the parent, some of 213 which point to DNSKEY's with the DELEGATION_ONLY flag set and some of 214 which point to DNSKEY's without the DELEGATION_ONLY flag set, the 215 zone MUST be considered DELEGATION_ONLY. This situation will occur 216 when a zone is rolling its DNSKEY key at the same time as it is 217 committing to a DELEGATION_ONLY zone (or the reverse). During the 218 overlap, the zone is considered to be a delegation-only zone. 220 4.5. Allowed record types for labels inside DELEGATION_ONLY zones 222 Some labels within a DELEGATION_ONLY marked zone must be published by 223 a parent in order to properly sign its zone and its child's referral 224 data. Thus, any published and signed zone data deeper than the zone 225 apex MUST only include DNS TYPEs of glue (NS, A and AAAA), DS, NSEC 226 and NSEC3 records. 228 5. Operational Considerations 230 Setting or unsetting the DELEGATION_ONLY flag must be handled like 231 any other Key Signing Key rollover procedure, with the appropriate 232 wait times to give resolvers the chance to update their caches. 234 Some TLDs offer a service where small domains can be hosted in-zone 235 at the TLD zone itself. In that case, the TLD MUST NOT set the 236 DELEGATION_ONLY flag. Another solution for such TLDs is to create 237 delegations for these child zones with the same or different DNSKEY 238 as used in the parent zone itself. 240 Zones setting the DELEGATION_ONLY flag can no longer publish non- 241 delegation records in their zone. That means that for those RRTYPEs 242 that take DNS targets as parameters (NS, MX, SRV, ...), the targets 243 cannot have their own host names on the zone. Instead, a sub-zone 244 needs to be created to place those targets in. If "example.com" has 245 an NS record pointing to "ns0.example.com", this entry needs to be 246 moved to a sub-zone such as ns0.nic.example.com before the zone can 247 be switched to DELEGATION_ONLY. Otherwise, the signed record 248 "ns0.example.com" would be interpreted as the parent's hostile 249 takeover of the child zone "ns0.example.com". Similarly, an MX 250 target pointing to "mail.example.com" would have to be moved to a 251 sub-zone, such as "mail.nic.example.com". The zone "nic.example.com" 252 MUST NOT be made DELEGATION_ONLY in that case, otherwise it would 253 have the exact same problem. 255 If a zone is publishing glue records for a number of zones, and the 256 zone that contains the authoritative records for this glue is 257 deleted, a resigning of the zone will make this orphaned glue 258 authoritative within the zone. However, with the DELEGATION_ONLY bit 259 set, this (signed) DNSSEC data will be considered BOGUS as it 260 violations the commitment to only delegate. This may impact domains 261 that depend on these incorrect glue records. 263 For example, if "example.com" and "example.net" use NS records 264 pointing to "ns.example.net", then if "example.net" is deleted from 265 the ".net" zone, and the previously unsigned glue of "ns.example.net" 266 is now signed by the ".net" zone, the "example.com" zone will lose 267 its NS records and fail to resolve. 269 The bind DNS software has an option called "delegation_only zones" 270 which is an option that means something completely different. It 271 refers to ignoring wildcard records in specified zones that are 272 deemed delegation-only zones. 274 6. Security Considerations 276 Some parent zone attacks cannot be detected when the validating 277 resolver's cache is empty. Care should be taken by resolvers to not 278 unnecessarily empty their cache. This is specifically important for 279 roaming clients that re-connect frequently to different wireless or 280 mobile data networks. 282 The DELEGATION_ONLY DNSKEY flag is only valid for DNSKEY's that have 283 the SEP bit set. It MUST be ignored on DNSKEY's without the SEP bit 284 set. 286 This DELEGATION_ONLY mechanism is not designed to completely foil 287 attacks (since parent's can simply change a child's referral data), 288 but rather to empower transparency logging mechanisms. 290 7. Privacy Considerations 292 Some of the protection offered by the DELEGATION_ONLY flag is only 293 available when DNS resolvers report changes in the signing depth of 294 high level (root or TLD) DNSKEYs to gain DNSSEC Transparency. This 295 reporting can reveal that a particular node is trying to access a 296 certain DNS name. Defensive measures to prevent exposing users 297 should be taken when implementing DNSSEC Transparency. It is 298 expected that DNSSEC Transparency behaviour will be written up in a 299 separate document. 301 8. Human Rights Considerations 303 The DNS protocol's hierarchy limits zones authority to themselves and 304 their child zones only. While this provides a finer grained trust 305 model compared to a simple list of all-powerful trusted entities, 306 such as those used in the WebPKI, it consolidates a lot of power in 307 the few keys at the top of the DNS hierarchy. With the increased 308 reliance on DNSSEC for securely identifying resources, such as DANE 309 records, it is important to monitor and audit the keys at the top of 310 the DNS hierarchy to prevent their abuse and coercion of child zones. 311 This DNS protocol extension specifically aims at increasing parent 312 zone transparency and blocks some parent zone attacks from those 313 parents who have publicly claimed to never override their child zone 314 data and thus increases the security and stability of DNS and DNSSEC. 316 Zones publishing the DELEGATION_ONLY flag to increase their public 317 trust are still able to remove child zones from their zone, for 318 example in cases of legal compliance or to prevent malicious activity 319 happening in its child zones. But these parents can only do so 320 publicly and can no longer surreptitiously take control of their own 321 child zones. This protocol extension does not limit legal 322 enforcement of child zones by their parent zones other than making it 323 visible for everyone when a childzone is legally taken over for 324 compliance or legal reasons. 326 9. IANA Considerations 328 This document defines a new DNSKEY flag, the DELEGATION_ONLY flag, 329 whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS 330 Registry. 332 10. Acknowledgements 334 The authors thank Thomas H. Ptacek for his insistence on pointing 335 out the trust issues at the top of the DNSSEC hierarchy. 337 Thanks to the following IETF participants: Viktor Dukhovni, Shumon 338 Huque, Geoff Huston, Rick Lamb, Andrew McConachie and Sam Weiler. 340 11. References 342 11.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, 346 DOI 10.17487/RFC2119, March 1997, . 349 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 350 Rose, "Protocol Modifications for the DNS Security 351 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 352 . 354 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 355 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 356 September 2007, . 358 11.2. Informative References 360 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 361 Rose, "DNS Security Introduction and Requirements", 362 RFC 4033, DOI 10.17487/RFC4033, March 2005, 363 . 365 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 366 Rose, "Resource Records for the DNS Security Extensions", 367 RFC 4034, DOI 10.17487/RFC4034, March 2005, 368 . 370 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 371 of Named Entities (DANE) Transport Layer Security (TLS) 372 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 373 2012, . 375 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 376 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 377 . 379 Authors' Addresses 381 Paul Wouters 382 Red Hat 384 Email: pwouters@redhat.com 386 Wes Hardaker 387 USC/ISI 388 P.O. Box 382 389 Davis, CA 95617 390 US 392 Email: ietf@hardakers.net