idnits 2.17.1 draft-adpkja-dnsop-special-names-problem-04.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 261: '...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 (June 28, 2016) is 2859 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA-SPECIAL-USE' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'HUSTON' is defined on line 312, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-02 Summary: 1 error (**), 0 flaws (~~), 4 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: December 30, 2016 DENIC eG 6 A. Durand 7 ICANN 8 W. Kumari 9 Google 10 June 28, 2016 12 Problem Statement for the Reservation of Top-Level Domains in the 13 Special-Use Domain Names Registry 14 draft-adpkja-dnsop-special-names-problem-04 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 aims to document those challenges in the form of 33 a problem statement in order to facilitate further discussion of 34 potential solutions. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 30, 2016. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction: DNS, Name space or Name Spaces, Name Resolution 71 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. IETF RFC6761 Special Names . . . . . . . . . . . . . . . . . 3 73 3. Issues with RFC 6761 Itself . . . . . . . . . . . . . . . . . 4 74 4. Issues with Evaluating Candidate String and Relationship to 75 the ICANN Process . . . . . . . . . . . . . . . . . . . . . . 5 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 81 8.2. Informative References . . . . . . . . . . . . . . . . . 7 82 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 7 83 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 8 85 A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 8 86 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction: DNS, Name space or Name Spaces, Name Resolution 90 Protocols 92 For a very long time, "DNS" and "the name space" have been perceived 93 as the same thing. However, this has not always been the case; in 94 the past, other name resolution protocols (such as NIS, NIS+, host 95 files, UUCP addresses, and others) were popular. Most of those have 96 been obsoleted by the DNS in the late 1990s. More information on the 97 history of names and namespaces can be found in 98 [I-D.lewis-domain-names]. 100 More recently, new name resolution protocols have been proposed, each 101 addressing a particular need or a particular community. For example, 102 the DONA handle system [DONA] has been used by parts of the 103 publication industry. The Apple "Bonjour" set of protocols, inspired 104 by what was available on Appletalk networks, was developed to perform 105 automatic name resolution on a local IP network. The TOR project is 106 using the onion system to obfuscate communications, the GNU Name 107 System (GNS) system is using block chains to build a decentralized 108 name system to offer "privacy and censorship resistance". Many more 109 name resolution protocols have been proposed. 111 These alternate name resolution protocols do not exist in a vacuum. 112 Application developers have expressed a strong desire to build their 113 software to function in any of those universes with minimal changes. 114 In order to do so, the software has to deterministically recognize 115 what kind of name it is dealing with and associate it with the 116 corresponding name resolution protocol. An algorithmic solution 117 frequently chosen by application developers consists simply to use a 118 special tag padded at the end of a name to indicate an alternate name 119 resolution method. For example, if a name ends in .local, the 120 software uses the Apple Bonjour protocol based on multicast DNS; if 121 the name ends in .onion, it uses the TOR protocol; if the name ends 122 in .gnu, it uses the GNS protocol, and so on. One noteworthy 123 exception to this approach is the DONA system that has its own 124 interoperability mechanism with the DNS. Another noteworthy 125 exception is the Frogans technology [FROGANS] which name space uses 126 the character '*' to separate network names from site names and allow 127 any character, including dots on either side of the '*'. 129 A result of the above is that a number of applications have been 130 developed (and massively distributed) that have encoded their 131 favorite "tag" as a DNS TLD in a free-for-all, beginning their 132 existence by squatting on that DNS space; .local, .gnu, .onion 133 started out like that. 135 2. IETF RFC6761 Special Names 137 The IETF used a provision from the IETF/ICANN MoU [RFC2860] section 138 4.3 that says that "(a) assignments of domain names for technical 139 uses" is to be considered the purview of IETF (outside of the scope 140 of ICANN) in order to create a way to reserve such names in a list of 141 "special names". That process is documented in [RFC6761] (which, 142 however, does not directly refer the IETF/ICANN MoU). The [RFC6761] 143 process was first applied for .local, and the more recently for 144 .onion. 146 When the [RFC6761] process was put in place, it was thought it would 147 only be used a handful of times. However, a large number of 148 applications have since been made to the IETF. The .onion evaluation 149 took almost a year and has started a massive (and often heated) 150 discussion in the IETF. 152 This [RFC6761] process to reserve special name has many issues. This 153 document groups the issues that have been brought up in two general 154 categories: 156 o Issues with [RFC6761] itself, including issues discovered during 157 the evaluation of .onion 159 o Issues regarding evaluating candidate strings and the relationship 160 of this process with ICANN's processes 162 3. Issues with RFC 6761 Itself 164 1. [RFC6761] can be used to reserve any names, not just TLDs. For 165 example, it could potentially be used to forbid a registrar to 166 register specific names in any TLD. 168 2. [RFC6761] does not mention if the protocol using the reserved 169 name should be published as an RFC document. Most applications 170 have, so far, come from outside organizations, and the described 171 protocols that have not been developed by the IETF. 173 3. [RFC6761] does not provide clear enough direction as to which 174 group of people is responsible for carrying out the evaluation 175 for inclusion in the registry. 177 4. There are ambiguities and no formal criteria on how the IETF can 178 (or even whether the IETF should) evaluate the merits of 179 applicants to [RFC6761] reservations. Section 5 of [RFC6761] 180 describes seven questions to be answered by an applicant for 181 [RFC6761] status. However, running this process for the .onion 182 application showed that those seven questions are inadequate for 183 making the determination for whether a particular strings 184 qualifies for [RFC6761] treatment. 186 5. Placing a string in the [RFC6761] registry does not guarantee 187 that DNS queries for names within a reserved domain will not be 188 sent over the Internet. As such, the applicant for [RFC6761] 189 status cannot be guaranteed that leakage will not occur and will 190 need to take this into account in their protocol design. Useful 191 reservations of top-level domains should be accompanied by 192 documentation of realistic expectations of each of the seven 193 audiences, and the evaluation of particular requests should 194 consider the practical likelihood of those expectations being met 195 and the implications if they are not. 197 6. The [RFC6761] registry lists the reserved names but does not 198 include direct guidance, neither in free text form nor in machine 199 readable instructions, for any of the seven audiences. Instead, 200 the registry relies on a reference for each entry to the document 201 that requested its insertion. Such documents could be difficult 202 to read for many readers; for example, [RFC6762] is a 70-page 203 protocol specification which is not an effective way to set 204 expectations of non-technical end-users. 206 4. Issues with Evaluating Candidate String and Relationship to the 207 ICANN Process 209 1. The IETF does not have process to evaluate candidate strings for 210 issues such as trademark, name collision, and so on. Instead, 211 the IETF relies on document reviews, working group and IETF-wide 212 last call, and ultimately a decision is made by the IESG. That 213 decision can be appealed, first to the IAB and second to the ISOC 214 board of trusties. 216 2. The IETF review process is not foolproof. [RFC7788] describing 217 the "home networking control protocol" was recently published. 218 That document includes text instructing devices to use names 219 terminating by default with the .home suffix. [RFC7788] did not 220 reference [RFC6761] anywhere and had no IANA sections about this 221 reservation. It was published without anyone noticing this 222 during the entire review process. The issue was caught after the 223 publication, and an errata was published. 225 3. There exists now at least two streams to take strings out of the 226 global namespace: the IETF's special-use domain names (described 227 in [RFC6761]) and ICANN's gTLD program (described at [NEW-GTLD]). 228 [RFC6761] reservations happen in a ad-hoc fashion at different 229 times, while ICANN's gTLD delegations typically happen in 230 batches. (The ICANN gTLD application process is described in the 231 applicant guide book [GUIDEBOOK]). One should note that the 232 current round of ICANN gTLD is closed to new applications, but 233 not yet completed as some applications are still under 234 consideration. One should note that discussions have started 235 about forming the next round of ICANN gTLDs. 237 4. There is a significant risk of conflict when both the IETF and 238 ICANN want to register the same string, and also when they want 239 to register similar strings. There currently is no defined 240 mechanism for cooperation between ICANN and IETF to avoid these 241 problems. 243 5. There could be conflict if an IETF reservation were to be made 244 during a possible future ICANN gTLD round. A hypothetical case 245 for this would be somebody trying prevent a competitor from 246 getting a gTLD by asking the IETF to reserve that string or a 247 similar string. 249 5. Security Considerations 251 This document aims to provide a problem statement that will inform 252 future work. While security and privacy are fundamental 253 considerations, this document expects that future work will include 254 such analysis, and hence no attempt is made to do so here. See 255 [SAC-057] for further considerations. 257 Reserving names has been presented as a way to prevent leakage into 258 the DNS. However, instructing resolvers to not forward the queries 259 (and/or by instructing authoritative servers not to respond) is not a 260 guarantee that such leakage will be prevented. The security (or 261 privacy) of an application MUST NOT rely on names not being exposed 262 to the Internet DNS resolution system. 264 6. IANA Considerations 266 This document has no IANA actions. 268 7. Acknowledgements 270 Thanks to Paul Hoffman for a large amount of editing. 272 8. References 274 8.1. Normative References 276 [IANA-SPECIAL-USE] 277 IANA, "Special-Use Domain Names", 2016, 278 . 281 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 282 Understanding Concerning the Technical Work of the 283 Internet Assigned Numbers Authority", RFC 2860, 284 DOI 10.17487/RFC2860, June 2000, 285 . 287 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 288 RFC 6761, DOI 10.17487/RFC6761, February 2013, 289 . 291 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 292 DOI 10.17487/RFC6762, February 2013, 293 . 295 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 296 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 297 2016, . 299 8.2. Informative References 301 [DONA] DONA, "DONA Foundation", June 2016, 302 . 304 [FROGANS] Frogans Technology, "Frogans Technology", June 2016, 305 . 307 [GUIDEBOOK] 308 ICANN, "gTLD Application Guidebook", June 2012, 309 . 312 [HUSTON] Huston, G., "What's in a Name?", December 2015, 313 . 315 [I-D.lewis-domain-names] 316 Lewis, E., "Domain Names", draft-lewis-domain-names-02 317 (work in progress), January 2016. 319 [NEW-GTLD] 320 ICANN, "New Generic Top-Level Domains", 2016, 321 . 323 [SAC-057] ICANN Security and Stability Advisory Committee, "SSAC 324 Advisory on Internal Name Certificates", March 2013, 325 . 328 Appendix A. Editorial Notes 330 This section (and sub-sections) to be removed prior to publication. 332 A.1. Venue 334 An appropriate forum for discussion of this draft is for now the 335 DNSOP WG. 337 A.2. Change History 339 A.2.1. draft-adpkja-special-names-problem-00 341 Initial draft circulated for comment. 343 Appendix B. Change history 345 [ RFC Editor: Please remove this section before publication] 347 -01 to -02: 349 o A very large number of readability / grammar / reference fixes 350 from Paul Hoffman. 352 -00 to -01: 354 o Significant readability changes. 356 -00: 358 o Initial draft circulated for comment. 360 Authors' Addresses 362 Geoff Huston 363 APNIC 365 Email: gih@apnic.net 367 Peter Koch 368 DENIC eG 369 Kaiserstrasse 75-77 370 Frankfurt 60329 371 Germany 373 Email: pk@denic.de 374 Alain Durand 375 ICANN 377 Email: alain.durand@icann.org 379 Warren Kumari 380 Google 382 Email: warren@kumari.net