idnits 2.17.1 draft-hardaker-dnsop-private-namespace-options-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 02, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SAC113' is mentioned on line 312, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Hardaker 3 Internet-Draft USC/ISI 4 Intended status: Standards Track November 02, 2020 5 Expires: May 6, 2021 7 DNS Private Namespace Options 8 draft-hardaker-dnsop-private-namespace-options-00 10 Abstract 12 This document discusses the trade-offs between various options about 13 creating a private namespace within top level domains within the root 14 zone. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on May 6, 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Document state . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Analysis of choices . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. TLD choices . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2.1. Working state aside . . . . . . . . . . . . . . . . . 4 57 2.2.2. Analysis of an unsigned TLD (eg .internal) . . . . . 5 58 2.2.3. Analysis of a special-use TLD (eg .zz) . . . . . . . 5 59 3. Other considerations . . . . . . . . . . . . . . . . . . . . 6 60 3.1. a unsigned delegated domain - .internal . . . . . . . . . 6 61 3.2. a special-use domain - .zz . . . . . . . . . . . . . . . 6 62 4. Deployment considerations . . . . . . . . . . . . . . . . . . 7 63 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Selecting good TLD names . . . . . . . . . . . . . . . . 7 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 HATS: The author is not wearing any hats while writing this document. 77 Deployed DNS clients within the Internet typically communicate with 78 upstream resolvers using their own in-application stub resolver. 79 These upstream resolvers may be run by ISPs, or may be a customer- 80 premises equipment (CPE) that may or may not forward requests to its 81 upstream ISP. 83 In an entirely singular Internet DNS there would be no name 84 collisions as all data is uniquely named. However, the prevalence of 85 local private name spaces within companies, organizations, 86 governments, home LANs, etc have shown that existence of a single, 87 unique naming system rarely exists. The deployment of Internet of 88 Things (IoT) devices is only accelerating this trend for private 89 namespaces by devices that bootstrap their names with the easy 90 solution of "just make one up until the customer provides us with a 91 better one", followed by the customer never providing one. This 92 document makes no judgment on whether this is right or wrong, and 93 takes this assumption as simply the state of the current world. 95 The for special use names is well spelled out in [RFC6761]. 96 [RFC8244] provides additional insight into areas that are still under 97 discussion and where work is needed. Recently ICANN's SSAC has 98 issued [SAC113] entitled "SSAC Advisory on Private-Use TLDs", wherein 99 it suggests the creation of a private-use DNS TLD. 101 This document considers the aspects associated with DNSSEC and the 102 potential choices for a private-use TLD (also see [RFC8244] bullet 103 21). Specifically, we consider the case where somewhere in the 104 resolution path DNSSEC validation is in use, potentially at an end- 105 device (phone, laptop, etc), a CPE, or at an ISP's resolver. 107 1.1. Document state 109 This document is not a fully complete analysis, but rather a starting 110 point for discussion and continued analysis by both the author and 111 others that wish to contribute. 113 1.2. Requirements notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 2. Analysis of choices 123 Note that this analysis is not (yet) exhaustive. It does describe 124 some of the differences in the two approaches. 126 2.1. Assumptions 128 We make the following assumptions to begin: 130 1. A local environment needs to use both the Global Internet's DNS 131 (GID), as well as at least one private name space as well. 133 2. A end-device, a CPE and/or a resolver may choose to validate DNS 134 requests. 136 3. The validating resolver wishes to validate both responses from 137 the GID as well as local names using DNSSEC. 139 4. The validating resolver will, thus, need Trust Anchors (TAs) for 140 both the GID and all private namespaces, or will need a list of 141 names which are assumed insecure and exemptions to the GID. 143 5. The device may (unfortunately) move to another network where 144 private namespace resolution is not available, and thus queries 145 to it will leak to the GID. This is extremely common today. 147 6. We take as accepted consensus that anything protocol needing a 148 private name space that is not user visible can be properly 149 housed under .arpa. This document assumes a private-namespace 150 TLD is needed, as discussed in other documents ([SAC113, etc]) to 151 aid in user presentation and understanding. This document does 152 not make judgment on whether this or user-education may be the 153 right approach to this problem. 155 2.2. TLD choices 157 Given these assumptions, we consider the cases where a private 158 namespace TLD exists that is: 160 1. Is a special-use domain per [RFC6761], and does not (and will 161 never) exist in the GID. In this document, we refer to this as 162 ".internal" for discussion purposes only following conventions in 163 [draft-wkumari-dnsop-internal]. 165 2. Is an unsigned delegation within the (GID's) DNS root, with NS 166 records likely pointing eventually to something like 127.0.53.53. 167 In this document, we refer to this as ".zz" following convention 168 in [draft-ietf-dnsop-private-use-tld]. We note that [draft-ietf- 169 dnsop-alt-tld] also proposed a private namespace (".alt") that 170 also fits into this category. 172 This document recognizes that .zz itself is actually not necessarily 173 a normal special use domain, and [RFC6761] may not apply as its an 174 ISO reversed name. However, in other aspects it will behave like a 175 special-use registered domain and its under current consideration by 176 dnsop so we leave it in here as the example name. 178 In summary: 180 o .internal is an unsigned TLD 182 o .zz is a special-use-like TLD that MUST never be assigned 184 2.2.1. Working state aside 186 The next two sections mix together DNSSEC validation at end-devices 187 and resolvers; it would add significant more clarity to discuss them 188 individually, which will be done in a future version. 190 2.2.2. Analysis of an unsigned TLD (eg .internal) 192 An unsigned TLD such as .internal will: 194 o Exist within the DNS root 196 o have NS records pointing to something.arpa with on A/AAAA 197 resolution 199 2.2.2.1. non-validating end-devices querying within .internal will: 201 o inside the private network the client will: 203 * Believe the upstream resolver's responses 205 o outside the private network the client will: 207 * Believe the upstream resolver's NXDOMAIN responses for anything 208 deeper than .internal itself (IE, api.example.internal/A will 209 return NXDOMAIN) 211 2.2.2.2. validating end-devices querying within .internal will: 213 o inside the private network the client will: 215 * must be configured with a private TA to enable DNSSEC within 216 the private network (creating an island of trust) 218 * If unconfigured, it will believe the upstream resolver's 219 responses because its delegated insecure, and therefore has no 220 basis to distrust the answers 222 o outside the private network the client will: 224 * if not configured with a TA, all answers to .internal will 225 either be NXDOMAIN or spoofable 227 * if configured with a TA, all answers will be detected as BOGUS 229 2.2.3. Analysis of a special-use TLD (eg .zz) 231 A special-use TLD will: 233 o Not exist within the DNS root 235 o Proven by the root's NSEC chain 237 2.2.3.1. non-validating end-devices querying within .zz will: 239 o inside the private network the client will: 241 * Believe the upstream resolver's responses 243 o outside the private network the client will: 245 * Believe the upstream resolver's NXDOMAIN or spoofed answers for 246 all data within the .zz domain. 248 2.2.3.2. validating end-devices querying within .zz will: 250 o inside the private network the client will: 252 * with an upstream resolver 254 * self-resolving: 256 + needs a configured TA or a configured negative trust anchor 258 + possibly automatically obtained configuration with a 259 bootstrapping mechanism, or-preconfigured in a ROM image 261 o outside the private network the client will: 263 * if not configured with a TA, all answers to .internal will 264 either be NXDOMAIN or spoofable 266 * if configured with a TA, all answers will be detected as BOGUS 268 3. Other considerations 270 3.1. a unsigned delegated domain - .internal 272 o configuration of new TAs 274 o requires collaboration between the IETF and ICANN , since the TLD 275 will exist and falls outside the scope of [RFC6761]. This process 276 can be slow. 278 3.2. a special-use domain - .zz 280 o May require invoking [RFC6761] (depending on .zz or not .zz) 282 o may require more configuration per-device 284 4. Deployment considerations 286 During initial deployment of either of these, there is a fundamental 287 difference for validating resolvers. 289 Specifically, until all validating resolvers are updated with a new 290 TA for specific instances under a special-use TLD (e.g. .zz), the 291 resolvers will fail to validate any names underneath as .zz is 292 provable insecure. This could take a while to update all deployed 293 validating resolvers. 295 On the other hand, deploying a newly allocated, unsigned TLD will 296 take a long time in process both within the IETF and within ICANN. 298 And each may have impacts on what error processing results, based on 299 the differing resolution characteristics (Section 2.2.2, 300 Section 2.2.3). 302 5. Recommendation 304 This author recommends that the IETF take on both tracks 305 simultaneously, and: 307 1. starts the process of communicating with ICANN and ISO about the 308 use of .zz, or selects another name to use under [RFC6761] as a 309 special-use name. 311 2. Issues a request to the ICANN board via the IAB to follow the 312 guidance of [SAC113] and reserve a string or set of strings for 313 use as a private-namespace(s) as an unsigned TLD. The ICANN 314 board can not act on their own, based on ICANN bilaws, but can 315 take requests from the IETF via the IAB to act. 317 This leaves vendors the freedom to chose that path that best meets 318 their specific requirements. Recommendations about how to best 319 select one given their situation is hinted above, but should be more 320 formally written down in this document or others. 322 5.1. Selecting good TLD names 324 Unfortunately, here be dragons. Selecting a good name has been 325 discussed multiple times in the IETF, and has always resulted in a 326 lack of consensus. In part, this is because the IETF doesn't have 327 the skillsets needed to hold a discussion about what language 328 element(s) would be best for universal adoption and usage. 330 Instead, this author recommends that we direct ICANN to select the 331 names that should be used for both of these cases. ICANN has 332 significant more skill breadth in the area of selecting names best 333 suited to be understood by end-users. This discussion will not be 334 faster, however, within ICANN but this author believes a resolution 335 in that SDO will be more likely successful. 337 Thus, the IETF can make the technical recommendation and ICANN can 338 implement these two choices. 340 6. Security Considerations 342 TBD 344 (though much of this draft is a security considerations itself) 346 7. IANA Considerations 348 TBD 350 8. References 352 8.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 360 RFC 6761, DOI 10.17487/RFC6761, February 2013, 361 . 363 8.2. Informative References 365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 367 May 2017, . 369 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 370 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 371 October 2017, . 373 Appendix A. Acknowledgments 375 Large portions of the technical analysis in this document derives 376 from a discussion with Roy Arends and Warren Kumari (back when we 377 could stand in front of a whiteboard together). 379 Author's Address 381 Wes Hardaker 382 USC/ISI 384 Email: ietf@hardakers.net