idnits 2.17.1 draft-pwouters-powerbind-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 (June 29, 2018) is 2121 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DNSSEC' is mentioned on line 74, but not defined == Missing Reference: 'TBD' is mentioned on line 252, 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, Ed. 3 Internet-Draft Red Hat 4 Updates: 4035 (if approved) L. Xia 5 Intended status: Informational Huawei 6 Expires: December 31, 2018 W. Hardaker 7 USC/ISI 8 June 29, 2018 10 The Delegation_Only DNSKEY flag 11 draft-pwouters-powerbind-01 13 Abstract 15 This document introduces a new DNSKEY flag called DELEGATION_ONLY 16 that indicates that the particular zone will never sign zone data 17 across a label. That is, every label (dot) underneath is considered 18 a zone cut and must have its own (signed) delegation. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 31, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The Deep Link State problem . . . . . . . . . . . . . . . . . 3 57 4. Limiting the scope of a DNSKEY RRset to just delegations . . 3 58 5. Parental Transparency . . . . . . . . . . . . . . . . . . . . 4 59 6. Marking the root key DELEGATION_ONLY . . . . . . . . . . . . 4 60 7. Marking TLD keys DELEGATION_ONLY . . . . . . . . . . . . . . 4 61 8. Migrating to and from DELEGATION_ONLY . . . . . . . . . . . . 5 62 9. Similarities to the Public Suffix List . . . . . . . . . . . 5 63 10. Operational Considerations . . . . . . . . . . . . . . . . . 5 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 14.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The DNS Security Extensions [DNSSEC] use public key cryptography to 75 create an hierarchical trust base with the DNSSEC root public keys at 76 the top, followed by Top Level domain (TLD) keys one level 77 underneath. While the root and TLD zones are asumed to be almost 78 exclusively delegation-only zones, there is currently no method to 79 audit these zones to ensure they behave as a delegation-only zone. 80 This creates an attractive target for malicious use of these zones - 81 either by their owners or through coercion. For example, the DNSSEC 82 root key could simply sign an A record and TLSA record for 83 "www.example.com", overriding the authority of "com" and 84 "example.com". If such a change is done in a targetted attack, the 85 attack would be near impossible to detect without prior knowledge of 86 what zone contents are legitimate within a given zone. This document 87 defines a mechanism for zone owners, at DNSKEY creation time, to 88 indicate they will only delegate the remainder of the tree to lower- 89 level zones, allowing easier logging and auditing of DNS responses 90 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 that traverses a 94 single label and if any such signed data is encountered by validating 95 resolvers, that this data should be interpreted as BOGUS. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 3. The Deep Link State problem 105 The hierarchical model of DNS and DNSSEC ([RFC4033], [RFC4034] and 106 [RFC4035]) comes with the property that a zone at one point in the 107 hierarchy can define, and therefor override, everything in the DNS 108 tree from their point and below. For example, the DNSSEC root key 109 could ignore the NS records for ".org" and "example.org" and could 110 place a record "www.example.org" directly into its own zone, with a 111 corresponding RRSIG signed by the root key itself. Even if resolvers 112 would defend against this attack by not allowing RRSIG's to span 113 across a potential zone cut, the zone operator (any level higher in 114 the hierarchy than the target victim) could briefly remove the NS and 115 DS records, and create a "legitimate" DNS entry for 116 "www.example.org", hiding the normal zonecuts. The attacker can then 117 publish DNS addresses records (e.g. A and AAAA records), as well as 118 records used for authentication (e.g. TLSA, SMIME, OPENPGPKEY, SSHP 119 or IPSECKEY records). 121 Exposing such targetted attacks requires a transparency audit setup 122 ([RFC6962]) that needs to log all signed DNS data to prove that data 123 signed by a parental DNSKEY was out of expected policy. The very 124 distributed nature of DNS makes such transparency logs prohibitively 125 expensive and nearly impossible to operate. Additionally, it would 126 expose all zone data to any public log operators, thereby exposing 127 all DNS data to a public archive. This data could then be used for 128 other malicious purposes. 130 4. Limiting the scope of a DNSKEY RRset to just delegations 132 This document introduces a new DNSKEY flag called DELEGATION_ONLY. 133 When this flag is set on a DNSKEY with SEP bit set (KSK), the zone 134 owner commits to not sign any data that crosses a label down in the 135 hierarchy. This commits a parent in the DNS hierarchy to only sign 136 NS and DS records (i.e. all non-glue, delegation records) for its 137 child zones. It will no longer be able to ignore (or briefly delete, 138 see below) a child delegation and publish data crossing zone labels 139 by pretending the next label is not a zone cut. 141 For such a parent to take over data that belongs to its child zone, 142 it has two choices. It can (temporarilly) remove its own DNSKEY 143 DELEGATION_ONLY flag or it can replace the NS and DS records of its 144 child zone with its own data (destinations and key references) so it 145 can sign DNS data that belongs to its own child zone. However, both 146 of these actions cannot be hidden, thus exposing such malicious 147 behavior when combined with public transparency logs. 149 5. Parental Transparency 151 A parent zone, such as the root zone, a TLD or any public suffix list 152 delegation point, that has published a key with the DELEGATION_ONLY 153 flag can no longer make an exception for a single delegated zone 154 without removing the DELEGATION_ONLY flag, switching off its 155 published policy. This action would be highly visible, and for some 156 domains such as the root or TLDs, require human interaction to notify 157 the stake holders to prevent loss of trust. 159 Removing the DELEGATION_ONLY flag from a DNSKEY requires that the 160 zone signals a new DS record to its parent, as changing any DNSKEY 161 flag requires changes to the DS record data for that corresponds to 162 it. 164 In the case of the root key, it would require updating out-of-band 165 root key meta information and/or perform an [RFC5011] style rollover 166 for the same key with updated DNSKEY flags. Due to the timings of 167 such a rollover, it would take at least 30 days for the first 168 validating resolvers to even pick this policy change. It would also 169 be a highly visible event. 171 Replacing the NS and DS records of a child zone can still be done in 172 a targetted attack mode, but these events are something that can be 173 easilly tracked by a transparency infrastructure similar to what is 174 now in use for the WebPKI using [RFC6962](bis). With client 175 implementations of transparency, all records would be logged and 176 become visible to the owner of attacked child zones, exposing a 177 parent's malicious actions. 179 6. Marking the root key DELEGATION_ONLY 181 Once the root key is marked with a DELEGATION_ONLY flag, and deployed 182 resolvers are configured with the new key, all TLDs will be ensured 183 that the root key can no longer be abused to create "deep link" data. 184 Until the root key sets this bit, software MAY imply this bit is 185 always set, as this is the current expectation of the root zone. 187 7. Marking TLD keys DELEGATION_ONLY 189 Even before the root key has been marked with DELEGATION_ONLY, TLDs 190 can already signal their own willingness to commit being 191 DELEGATION_ONLY zones. Any changes of that state in a TLD DNSKEY 192 will require those TLDs to submit a new DS record to the root. 194 8. Migrating to and from DELEGATION_ONLY 196 There might be multiple DNSKEYs with the SEP bit set in a zone. For 197 the purpose of delcaring a zone as DELEGATION_ONLY, only those 198 DNSKEY's that have a corresponding DS record at the parent MUST be 199 considered. If multiple DS records appear at the parent, some of 200 which point to DNSKEY's with and some of which point to DNSKEY's 201 without the DELEGATION_ONLY flag set, the zone MUST be considered 202 DELEGATION_ONLY. This situation will occur when a zone is rolling 203 its DNSKEY key at the same time as it is commiting to a 204 DELEGATION_ONLY zone (or the reverse). 206 9. Similarities to the Public Suffix List 208 The DELEGATION_ONLY flag has a strong overlap in functionality with 209 the Public Suffix List; both signal a formal split of authority 210 between parent and child. The DELEGATION_ONLY flag allows zones to 211 formally state their intention. 213 10. Operational Considerations 215 Setting or unsetting the DELEGATION_ONLY flag must be handled like 216 any other Key Signing Key rollover procedure, with the appropriate 217 wait times to give resolvers the chance to update their caches. 219 Some TLDs offer a service where small domains can be hosted in-zone 220 at the TLD zone itself. In that case, the TLD MUST NOT set the 221 DELEGATION_ONLY flag. Another solution for such TLDs is to create 222 delegations for these child zones with the same or different DNSKEY 223 as used in the parent zone itself. 225 If a zone is publishing glue records for a number of zones, and the 226 zone that contains the authoritative records for this glue is 227 deleted, a resigning of the zone will make this orphaned glue 228 authoritative within the zone. However, with the DELEGATION_ONLY bit 229 set, this (signed) DNSSEC data will be considered BOGUS as it 230 violations the commitment to only delegate. This may impact domains 231 that depended on this unsigned glue. 233 For example, if "example.com" and "example.net" use NS records 234 pointing to "ns.example.net", then if "example.net" is deleted from 235 the ".net" zone, and the previously unsigned glue of "ns.example.net" 236 is now signed by the ".net" zone, the "example.com" zone will lose 237 its NS records and fail to resolve. 239 The bind DNS software has an option called "delegation_only zones" 240 which is an option that means something completely different. It 241 refers to ignoring wildcard records in specified zones that are 242 deemed delegation-only zones. 244 11. Security Considerations 246 There are no negative security impacts of using the DELEGATION_ONLY 247 bit? 249 12. IANA Considerations 251 This document defines a new DNSKEY flag, the DELEGATION_ONLY flag, 252 whose value [TBD] has been allocated by IANA from the DNSKEY FLAGS 253 registry. 255 13. Acknowledgements 257 The author wishes to thank Thomas H. Ptacek for his insistence on 258 this matter. 260 Thanks to the following IETF participants: Viktor Dukhovni, Shumon 261 Huque, Geoff Huston, Rick Lamb and Sam Weiler. 263 14. References 265 14.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, . 272 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 273 Rose, "Protocol Modifications for the DNS Security 274 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 275 . 277 [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) 278 Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011, 279 September 2007, . 281 14.2. Informative References 283 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 284 Rose, "DNS Security Introduction and Requirements", 285 RFC 4033, DOI 10.17487/RFC4033, March 2005, 286 . 288 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 289 Rose, "Resource Records for the DNS Security Extensions", 290 RFC 4034, DOI 10.17487/RFC4034, March 2005, 291 . 293 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 294 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 295 . 297 Authors' Addresses 299 Paul Wouters (editor) 300 Red Hat 302 Email: pwouters@redhat.com 304 Liang Xia 305 Huawei 307 Email: frank.xialiang@huawei.com 309 Wes Hardaker 310 USC/ISI 311 P.O. Box 382 312 Davis, CA 95617 313 US 315 Email: ietf@hardakers.net