idnits 2.17.1 draft-adpkja-dnsop-special-names-problem-06.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 283: '...f an application MUST NOT rely on name...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2016) is 2785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA-SPECIAL-USE' is defined on line 298, but no explicit reference was found in the text == Unused Reference: 'GUIDEBOOK' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'HUSTON' is defined on line 334, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-03 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft APNIC 4 Intended status: Informational P. Koch 5 Expires: March 14, 2017 DENIC eG 6 A. Durand 7 ICANN 8 W. Kumari 9 Google 10 September 10, 2016 12 Problem Statement for the Reservation of Special-Use Domain Names using 13 RFC6761 14 draft-adpkja-dnsop-special-names-problem-06 16 Abstract 18 The dominant protocol for name resolution on the Internet is the 19 Domain Name System (DNS). However, other protocols exist that are 20 fundamentally different from the DNS, and may or may not share the 21 same namespace. 23 When an end-user triggers resolution of a name on a system that 24 supports multiple, different protocols or resolution mechanisms, it 25 is desirable that the protocol used is unambiguous, and that requests 26 intended for one protocol are not inadvertently answered using 27 another protocol. 29 RFC 6761 introduced a framework by which a particular domain name 30 could be acknowledged as being special. Various challenges have 31 become apparent with this application of the guidance provided in RFC 32 6761. This document focuses solely on documenting the specific 33 challenges created by RFC 6761 in the form of a problem statement in 34 order to facilitate further discussions of potential solutions. In 35 particular, it refrains from proposing or promoting any solution. 36 Also, the current document does not focus on other general issues 37 related to the use of special use domain names. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on March 14, 2017. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction: DNS, Name Space or Name Spaces, Name Resolution 74 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 4 76 3. Issues with RFC 6761 process . . . . . . . . . . . . . . . . 4 77 4. Issues with the RFC6761 registry . . . . . . . . . . . . . . 5 78 5. Issues Around the IETF Evaluation of Candidate Strings . . . 6 79 6. Other Issues Related to RFC6761 . . . . . . . . . . . . . . . 6 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 85 10.2. Informative References . . . . . . . . . . . . . . . . . 7 86 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8 87 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 8 89 A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 8 90 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 8 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 93 1. Introduction: DNS, Name Space or Name Spaces, Name Resolution 94 Protocols 96 For a very long time, "DNS" and "the name space" have been perceived 97 as the same thing. However, this has not always been the case; in 98 the past, other name resolution protocols (such as NIS, NIS+, host 99 files, UUCP addresses, and others) were popular. Most of those have 100 been obsoleted by the DNS in the late 1990s. More information on the 101 history of names and namespaces can be found in 102 [I-D.lewis-domain-names]. 104 More recently, new name resolution protocols have been proposed, each 105 addressing a particular need or a particular community. For example, 106 the DONA handle system [DONA] has been used by parts of the 107 publication industry. The Apple "Bonjour" set of protocols, inspired 108 by what was available on Appletalk networks, was developed to perform 109 automatic name resolution on a local IP network. The TOR project is 110 using the onion system to obfuscate communications, the GNU Name 111 System (GNS) system is using block chains to build a decentralized 112 name system to offer "privacy and censorship resistance". Many more 113 name resolution protocols have been proposed. 115 These alternate name resolution protocols do not exist in a vacuum. 116 Application developers have expressed a strong desire to build their 117 software to function in any of those universes with minimal changes. 118 In order to do so, the software has to deterministically recognize 119 what kind of name it is dealing with and associate it with the 120 corresponding name resolution protocol. An algorithmic solution 121 frequently chosen by application developers consists simply in using 122 a special tag padded at the end of a name to indicate an alternate 123 name resolution method. For example, if a name ends in .local, the 124 software uses the Apple Bonjour protocol based on multicast DNS; if 125 the name ends in .onion, it uses the TOR protocol; if the name ends 126 in .gnu, it uses the GNS protocol, and so on. One noteworthy 127 exception to this approach is the DONA system that has its own 128 interoperability mechanism with the DNS. Another noteworthy 129 exception is the Frogans technology [FROGANS] which name space uses 130 the character '*' to separate network names from site names and allow 131 any character, including dots on either side of the '*'. 133 A result of the above is that a number of applications have been 134 developed (and massively distributed) that have encoded their 135 favorite "tag" as a DNS TLD in a free-for-all, beginning their 136 existence by squatting on that DNS space; .local, .gnu, .onion 137 started out like that. 139 2. IETF RFC6761 Special Names 141 The IETF used a provision from the IETF/ICANN MoU [RFC2860] section 142 4.3 that says that "(a) assignments of domain names for technical 143 uses" is to be considered the purview of IETF (outside of the scope 144 of ICANN) in order to create a way to reserve such names in a list of 145 "special names". That process is documented in [RFC6761] (which, 146 however, does not directly refer the IETF/ICANN MoU). The [RFC6761] 147 process was first applied for .local, and the more recently for 148 .onion. 150 When the [RFC6761] process was put in place, many thought it would 151 only be used a handful of times. However, a large number of 152 applications have since been made to the IETF. The .onion evaluation 153 took almost a year and has started a massive (and often heated) 154 discussion in the IETF. 156 [RFC6761] has a number of issues. This document groups those issues 157 in several categories. 159 3. Issues with RFC 6761 process 161 a. [RFC6761] does not mention if the protocol using the reserved 162 name should be published as an RFC document. 164 Most applications have, so far, come from outside 165 organizations, and the described protocols that have not been 166 developed by the IETF. 168 b. [RFC6761] does not provide clear enough directions as to which 169 group of people is responsible for carrying out the evaluation 170 for inclusion in the registry. 172 There are ambiguities and no formal criteria on how the IETF 173 can (or even whether the IETF should) evaluate the merits of 174 applicants to [RFC6761] reservations. 176 c. The "seven questions" of [RFC6761] are inadequate for evaluating 177 proposals. 179 Section 5 of [RFC6761] describes seven questions to be 180 answered by an applicant for [RFC6761] status. However, 181 running this process for the .onion application showed that 182 those seven questions are inadequate for making the 183 determination of whether a particular string qualifies for 184 [RFC6761] treatment. 186 d. Some organizations may want to experiment with a reserved name. 188 They may or may not be ready (or willing) to go through a 189 cumbersome process and find [RFC6761] too difficult to deal 190 with. They would like a much simpler registration process, 191 with limited or no burden to apply. 193 e. The [RFC6761] process could be abused. 195 In particular, the process can be abused to reserve a specific 196 string within an existing suffix (or set of suffixes using 197 wildcards) not under the control of IETF. 199 f. [RFC6761] does not have provision for subsequent management of 200 the registry, such as updates, deletions of entries, etc... 202 4. Issues with the RFC6761 registry 204 a. The [RFC6761] registry lacks sufficient documentation supporting 205 a registration. 207 The registry may point to the RFC creating the reservation, 208 but not to the supporting materials. 210 b. The [RFC6761] registry lacks clear directions for applications to 211 select which name resolution method to use upon seeing the 212 special name. 214 In particular, it lists the reserved names but does not 215 include direct guidance, neither in free text form nor in 216 machine-readable instructions, for any of the seven audiences. 217 Instead, the registry relies on a reference for each entry to 218 the document that requested its insertion. Such documents 219 could be difficult to read for many readers; for example, 220 [RFC6762] is a 70-page protocol specification which is not an 221 effective way to set expectations of non-technical end-users. 223 c. Reserving a string in [RFC6761] does not guarantee queries will 224 not leak in the DNS. 226 The applicants for [RFC6761] status cannot be guaranteed that 227 leakage will not occur and will need to take this into account 228 in their protocol design. 230 d. The intended usage or protocol for which the [RFC6761] 231 reservation is made may or may not be successful. 233 In the case of failure of adoption, the reserved string would 234 be wasted. 236 5. Issues Around the IETF Evaluation of Candidate Strings 238 a. The IETF does not have a formal process to evaluate candidate 239 strings for issues such as trademark infringement and name 240 collisions. 242 This leads to concerns about liability risks incurred by 243 adding a particular string to the [RFC6761] registry. 245 b. Submitting the application to IETF last call does not guarantee 246 such issues will be always caught. 248 [RFC7788] describing the "home networking control protocol" 249 was recently published. That document includes text 250 instructing devices to use names terminating by default with 251 the .home suffix. [RFC7788] did not reference [RFC6761] 252 anywhere and had no IANA sections about this reservation. It 253 was published without anyone noticing this during the entire 254 review process. The issue was caught after the publication, 255 and an errata was published. 257 6. Other Issues Related to RFC6761 259 [RFC6761] does not include a mechanism to collaborate with ICANN. 261 The current round of ICANN gTLD (described at [NEW-GTLD]) is, as 262 the time of this writing, closed to new applications. It is, 263 however, not yet completed. Some applications are still under 264 consideration. There is a risk that, without proper collaboration 265 between the IETF and ICANN, a new entry in the [RFC6761] registry 266 could conflict with one of those applications still under review. 267 It should also be noted that discussions have started about 268 forming the next round of ICANN gTLDs, thus this issue will not go 269 away at the conclusion of the current gTLD round. 271 7. Security Considerations 273 This document aims to provide a problem statement that will inform 274 future work. While security and privacy are fundamental 275 considerations, this document expects that future work will include 276 such analysis, and hence no attempt is made to do so here. See 277 [SAC-057] for further considerations. 279 Reserving names has been presented as a way to prevent leakage into 280 the DNS. However, instructing resolvers to not forward the queries 281 (and/or by instructing authoritative servers not to respond) is not a 282 guarantee that such leakage will be prevented. The security (or 283 privacy) of an application MUST NOT rely on names not being exposed 284 to the Internet DNS resolution system. 286 8. IANA Considerations 288 This document has no IANA actions. 290 9. Acknowledgements 292 Thanks to Paul Hoffman for a large amount of editing. 294 10. References 296 10.1. Normative References 298 [IANA-SPECIAL-USE] 299 IANA, "Special-Use Domain Names", 2016, 300 . 303 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 304 Understanding Concerning the Technical Work of the 305 Internet Assigned Numbers Authority", RFC 2860, 306 DOI 10.17487/RFC2860, June 2000, 307 . 309 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 310 RFC 6761, DOI 10.17487/RFC6761, February 2013, 311 . 313 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 314 DOI 10.17487/RFC6762, February 2013, 315 . 317 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 318 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 319 2016, . 321 10.2. Informative References 323 [DONA] DONA, "DONA Foundation", June 2016, 324 . 326 [FROGANS] Frogans Technology, "Frogans Technology", June 2016, 327 . 329 [GUIDEBOOK] 330 ICANN, "gTLD Application Guidebook", June 2012, 331 . 334 [HUSTON] Huston, G., "What's in a Name?", December 2015, 335 . 337 [I-D.lewis-domain-names] 338 Lewis, E., "Domain Names", draft-lewis-domain-names-03 339 (work in progress), June 2016. 341 [NEW-GTLD] 342 ICANN, "New Generic Top-Level Domains", 2016, 343 . 345 [SAC-057] ICANN Security and Stability Advisory Committee, "SSAC 346 Advisory on Internal Name Certificates", March 2013, 347 . 350 Appendix A. Editorial Notes 352 This section (and sub-sections) to be removed prior to publication. 354 A.1. Venue 356 An appropriate forum for discussion of this draft is, for now, the 357 DNSOP WG. 359 A.2. Change History 361 A.2.1. draft-adpkja-special-names-problem-00 363 Initial draft circulated for comment. 365 Appendix B. Change history 367 [ RFC Editor: Please remove this section before publication] 369 -06 to -05: 371 o Clarify the sole focus of this draft is to document problems 372 created by RFC6761, and not the larger issue of NON-DNS TLDs. 374 o Split issue lists and rewrite some for clarity. 376 -05 to -04: 378 o Added two issues to the issue list: market failure and 379 experimental use. 381 -04 to -03: 383 o Minor edits to correct grammar, clarify that the current ICANN 384 gTLD round is closed. 386 -03 to -02: 388 o Significant readability changes to focus the discussion. 390 -01 to -02: 392 o A very large number of readability / grammar / reference fixes 393 from Paul Hoffman. 395 -00 to -01: 397 o Significant readability changes. 399 -00: 401 o Initial draft circulated for comment. 403 Authors' Addresses 405 Geoff Huston 406 APNIC 408 Email: gih@apnic.net 410 Peter Koch 411 DENIC eG 412 Kaiserstrasse 75-77 413 Frankfurt 60329 414 Germany 416 Email: pk@denic.de 418 Alain Durand 419 ICANN 421 Email: alain.durand@icann.org 422 Warren Kumari 423 Google 425 Email: warren@kumari.net