idnits 2.17.1 draft-adpkja-dnsop-special-names-problem-03.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 250: '...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 (May 24, 2016) is 2894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA-SPECIAL-USE' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'HUSTON' is defined on line 295, 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: November 25, 2016 DENIC eG 6 A. Durand 7 ICANN 8 W. Kumari 9 Google 10 May 24, 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-03 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. 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 November 25, 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 6761 . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Candidate string evaluation and relationship with ICANN . . . 5 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 80 8.2. Informative References . . . . . . . . . . . . . . . . . 7 81 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 7 82 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 7 84 A.2.1. draft-adpkja-special-names-problem-00 . . . . . . . . 7 85 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 7 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 88 1. Introduction: DNS, Name space or Name Spaces, Name Resolution 89 Protocols 91 For a very long time, DNS and the name space have been perceived as 92 one and the same. However, this has not always been the case; in the 93 past, other name resolution protocols were popular. One can remember 94 NIS, NIS+, host files, UUCP addresses... Most of those have been 95 obsoleted by the DNS in the late 1990s. More information on the 96 history of names and namespaces can be found in 97 [I-D.lewis-domain-names]. 99 More recently, new name resolution protocols have been proposed, each 100 addressing a particular need or a particular community. For example, 101 the DONA handle system has been used by the publication industry. 102 The Apple "Bonjour" set of protocols, inspired by what was available 103 on Appletalk networks, has been developed to perform automatic name 104 resolution on a local IP network. The TOR project is using the onion 105 system to obfuscate communications, the GNU Name System (GNS) system 106 is using block chains to build a decentralized name system to offer 107 "privacy and censorship resistance". Many more have been proposed. 109 Those alternate name resolution protocols do not exist in a vacuum. 110 Application developers have expressed a strong desire to build their 111 software so it will function in any of those universes with minimal 112 changes. Doing so means that the software has to recognize 113 deterministically what kind of name it is dealing with and associate 114 it with the corresponding name resolution protocol. Because of this 115 desired lack of explicit signaling, an algorithmic solution 116 frequently chosen by application developers consists simply to use a 117 special tag padded at the end of a name to indicate an alternate name 118 resolution method. Examples: if a name ends in .local, the software 119 uses the Apple Bonjour protocol based on multicast DNS; if the name 120 ends in .onion, it uses the TOR protocol; if the name ends in .gnu, 121 it uses the GNS protocol, etc... One noteworthy exception to this 122 approach is the DONA system that exists independently and has 123 developed its own interoperability solution with the DNS. 125 A result of the above is that a number of applications have been 126 developed (and massively distributed) that have encoded their 127 favorite "tag" as a DNS TLD in a free-for-all, beginning their 128 existence squatting on that DNS space... .local, .gnu, .onion 129 started out like that. 131 2. IETF RFC6761 Special Names 133 The IETF used a provision from the IETF/ICANN MoU [RFC2860] section 134 4.3 that says that "(a) assignments of domain names for technical 135 uses" is to be considered the purview of IETF (as in, outside of the 136 scope of ICANN) in order to create a way to reserve such names in a 137 list of "special names". That process is documented in [RFC6761] 138 (which curiously does not directly refer the IETF/ICANN MoU). It was 139 first applied for .local and more recently for .onion. When that 140 process was put in place, it was thought it would only be used a 141 handful of times. However, a large number of applications have since 142 been made to the IETF. The .onion evaluation took almost a year and 143 has started a massive (and often heated) discussion in the IETF. 145 This [RFC6761] process to reserve special name has a number of 146 issues, that can be grouped in two categories: 148 o Issues with [RFC6761] itself, including issues discovered during 149 the evaluation of .onion 151 o Higher level issues regarding candidate string evaluation and 152 relationship with ICANN 154 3. Issues with 6761 156 1. It can be use to reserve any names, not just TLDs. For example, 157 it could potentially be used to forbid a registrar to register 158 specific names in any TLD. 160 2. [RFC6761] does not mention if the protocol for which it is 161 requested to reserve a string should be published as an RFC 162 document. Most applications have, so far, come from outside 163 organizations, and the described protocols that have not been 164 developed by the IETF. 166 3. [RFC6761] does not provide clear enough direction as to what 167 party is responsible for carrying out the evaluation. 169 4. There are ambiguities and no formal criteria on how the IETF can 170 (or even whether the IETF should) evaluate the merits of 171 applicants to [RFC6761] reservations. Section 5 of [RFC6761] 172 describes seven questions to be answered by an applicant for 173 [RFC6761] status. However, running this process for the .onion 174 application showed that those seven questions are inadequate for 175 making the determination for whether a particular strings 176 qualifies as requiring special/different treatment. 178 5. Placing a string in the [RFC6761] registry does not guarantee 179 that DNS queries for names within a reserved domain will not be 180 sent over the Internet. As such, the applicant for [RFC6761] 181 status cannot be guaranteed that leakage will not occur and will 182 need to take this into account in the protocol design. Useful 183 reservations of top-level domains should be accompanied by 184 documentation of realistic expectations of each of the seven 185 audiences, and the evaluation of particular requests should 186 consider the practical likelihood of those expectations being met 187 and the implications if they are not. 189 6. The [RFC6761] registry lists the reserved names but does not 190 include direct guidance, neither in free text form nor in machine 191 readable instructions, for any of the seven audiences, relying 192 instead upon a reference for each entry in the Registry to the 193 document that requested its insertion. Such documents might well 194 be opaque to many readers; [RFC6762] is a seventy-page protocol 195 specification, for example, which is arguably not the most 196 effective way to set expectations of non-technical end-users 198 4. Candidate string evaluation and relationship with ICANN 200 1. IETF does not have process to evaluate the proposed strings 201 candidate to [RFC6761] status for things like trademark, IPR, 202 name collision, etc.. Instead, the IETF relies on document 203 reviews, working group and IETF-wide last call, and ultimately a 204 decision is made by the IESG. That decision can be appealed, 205 first to the IAB and second to the ISOC board of trusties. 207 2. The IETF "review" process is not foolproof. [RFC7788] describing 208 the "home networking control protocol" was recently published. 209 That document includes text instructing devices to use names 210 terminating by default with the .home suffix. [RFC7788] did not 211 reference [RFC6761] anywhere and had no IANA sections about this 212 reservation. It was published without anyone noticing this 213 during the entire review process. The issue was caught after the 214 publication, and an errata was published. 216 3. There exists now at least 2 streams to take strings out of the 217 global namespace: IETF RFC6761 "special names" and ICANN "gTLD 218 program" (see [NEW-GTLD]). It is important to observed that the 219 IETF RFC6761 reservations could happen in a ad-hoc fashion at any 220 time, while ICANN delegations typically happen in batches, and 221 the latest gTLD round is closed. Note: the ICANN gTLD 222 application process is described in the applicant guide book 223 [GUIDEBOOK]. 225 4. The major risk is having a conflict when both the IETF and ICANN 226 want to use the same or similar strings. There exist no defined 227 cooperation between ICANN and IETF to avoid this problem. 229 5. There might be limited concerns if IETF were to reserve a string 230 outside of an ICANN gTLD round. The next ICANN gTLD applicant 231 book would simply refer to the existing list at publication time. 232 However, there is a possibility of conflict if an IETF 233 reservation were to happen during an ICANN gTLD round. A 234 hypothetical case study could be somebody trying a denial of 235 service attack early in the ICANN application process by asking 236 the IETF to reserved a string sought after by a competitor. 238 5. Security Considerations 240 This document aims to provide a problem statement that will inform 241 future work. While security and privacy are fundamental 242 considerations, this document expects that future work will include 243 such analysis, and hence no attempt is made to do so here. See among 244 other places [SAC-057] 246 Reserving names has been presented as a way to prevent leakage into 247 the DNS. However, instructing resolvers to not forward the queries 248 (and/or by instructing authoritative servers not to respond) is not a 249 guarantee that such leakage will be prevented. The security (or 250 privacy) of an application MUST NOT rely on names not being exposed 251 to the Internet DNS resolution system. 253 6. IANA Considerations 255 This document has no IANA actions. 257 7. Acknowledgements 259 Thanks to Paul Hoffman for a large amount of editing. 261 8. References 263 8.1. Normative References 265 [IANA-SPECIAL-USE] 266 IANA, "Special-Use Domain Names", 2016, 267 . 270 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 271 Understanding Concerning the Technical Work of the 272 Internet Assigned Numbers Authority", RFC 2860, 273 DOI 10.17487/RFC2860, June 2000, 274 . 276 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 277 RFC 6761, DOI 10.17487/RFC6761, February 2013, 278 . 280 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 281 DOI 10.17487/RFC6762, February 2013, 282 . 284 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 285 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 286 2016, . 288 8.2. Informative References 290 [GUIDEBOOK] 291 ICANN, "gTLD Application Guidebook", June 2012, 292 . 295 [HUSTON] Huston, G., "What's in a Name?", December 2015, 296 . 298 [I-D.lewis-domain-names] 299 Lewis, E., "Domain Names", draft-lewis-domain-names-02 300 (work in progress), January 2016. 302 [NEW-GTLD] 303 ICANN, "New Generic Top-Level Domains", 2016, 304 . 306 [SAC-057] ICANN Security and Stability Advisory Committee, "SSAC 307 Advisory on Internal Name Certificates", March 2013, 308 . 311 Appendix A. Editorial Notes 313 This section (and sub-sections) to be removed prior to publication. 315 A.1. Venue 317 An appropriate forum for discussion of this draft is for now the 318 DNSOP WG. 320 A.2. Change History 322 A.2.1. draft-adpkja-special-names-problem-00 324 Initial draft circulated for comment. 326 Appendix B. Change history 328 [ RFC Editor: Please remove this section before publication] 330 -01 to -02: 332 o A very large number of readability / grammar / reference fixes 333 from Paul Hoffman. 335 -00 to -01: 337 o Significant readability changes. 339 -00: 341 o Initial draft circulated for comment. 343 Authors' Addresses 345 Geoff Huston 346 APNIC 348 Email: gih@apnic.net 350 Peter Koch 351 DENIC eG 352 Kaiserstrasse 75-77 353 Frankfurt 60329 354 Germany 356 Email: pk@denic.de 358 Alain Durand 359 ICANN 361 Email: alain.durand@icann.org 363 Warren Kumari 364 Google 366 Email: warren@kumari.net