idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-exit-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2015) is 3221 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Grothoff 3 Internet-Draft INRIA 4 Intended status: Informational M. Wachs 5 Expires: December 24, 2015 Technische Universitaet Muenchen 6 H. Wolf, Ed. 7 GNU consensus 8 J. Appelbaum 9 L. Ryge 10 Tor Project Inc. 11 June 30, 2015 13 The .exit Special-Use Domain Name of Tor 14 draft-grothoff-iesg-special-use-p2p-exit-00 16 Abstract 18 This document registers a Special-Use Domain Name for use with the 19 Tor Project, as per RFC6761. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 24, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology and Conventions Used in This Document . . . . . . 3 58 4. The "EXIT" Client Source Routing pTLD . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 8.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 The Domain Name System (DNS) is primarily used to map human-memorable 70 names to IP addresses, which are used for routing but generally not 71 meaningful for humans. 73 The Tor project supports the use of names to specify where the user 74 wishes to exit the P2P overlay. 76 As compatibility with applications using domain names is desired, 77 this mechanism requires an exclusive alternative Top-Level Domains to 78 avoid conflict between the Tor namespace and the DNS hierarchy. 80 In order to avoid interoperability issues with DNS as well as to 81 address security and privacy concerns, this document registers the 82 "EXIT" Special-Use Domain Names for use within the Tor network, as 83 per [RFC6761]. 85 The Tor network uses this pTLD to control overlay routing and to 86 securely specify path selection choices [TOR-PATH]. 88 2. Applicability 90 [RFC6761] Section 3 states: 92 "[I]f a domain name has special properties that affect the way 93 hardware and software implementations handle the name, that apply 94 universally regardless of what network the implementation may be 95 connected to, then that domain name may be a candidate for having 96 the IETF declare it to be a Special-Use Domain Name and specify 97 what special treatment implementations should give to that name. 98 On the other hand, if declaring a given name to be special would 99 result in no change to any implementations, then that suggests 100 that the name may not be special in any material way, and it may 101 be more appropriate to use the existing DNS mechanisms [RFC1034] 102 to provide the desired delegation, data, or lack-of-data, for the 103 name in question. Where the desired behaviour can be achieved via 104 the existing domain name registration processes, that process 105 should be used. Reservation of a Special-Use Domain Name is not a 106 mechanism for circumventing normal domain name registration 107 processes." 109 The set "EXIT" pTLD reserved by this document meets this requirement, 110 as it has the following specificities: 112 o "EXIT" resolution does not depend on the DNS context: The name 113 specifies a Tor exit node, and thus the response is not even 114 really DNS-compatible; Tor uses its own P2P protocols for 115 resolving the destination specified in an .exit name. 117 o When Tor is properly implemented, the implementation MUST 118 intercept queries for the "EXIT" to ensure that these Tor-specific 119 names cannot leak into the DNS. 121 o Finally, in order for Tor to properly interoperate with DNS and to 122 provide security and privacy features matching user expectations, 123 this document specifies desirable changes in existing DNS software 124 and DNS operations. 126 3. Terminology and Conventions Used in This Document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 The word "peer" is used in the meaning of a individual system on the 133 network. 135 The abbreviation "pTLD" is used in this document to mean a pseudo 136 Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] 137 reserved to P2P Systems in this document. A pTLD is mentioned in 138 capitals, and within double quotes to mark the difference with a 139 regular DNS gTLD. 141 In this document, ".tld" (lowercase, with quotes) means: any domain 142 or hostname within the scope of a given pTLD, while .tld (lowercase, 143 without quotes) refers to an adjective form. 145 The word "NXDOMAIN" refers to an alternate expression for the "Name 146 Error" RCODE as described in section 4.1.1 of [RFC1035]. When 147 referring to "NXDOMAIN" and negative caching [RFC2308] response, this 148 document means an authoritative (AA=1) name error (RCODE=3) response 149 exclusively. 151 The Tor-related names such as 'circuit', 'exit', 'node', 'relay', 152 'stream', and related Tor terms are described in [Dingledine2004] and 153 the Tor protocol specification [TOR-PROTOCOL]. 155 4. The "EXIT" Client Source Routing pTLD 157 The .exit suffix is used as an in-band source routing control 158 channel, usually for selection of a specific Tor relay during path 159 creation as the last node in the Tor circuit. 161 It may be used to access a DNS host via specific Torservers, in the 162 form "hostname.nickname-or-fingerprint.exit", where the "hostname" is 163 a valid hostname, and the "nickname-or-fingerprint" is either the 164 nickname of a Tor relay in the Tor network consensus, or the hex- 165 encoded SHA1 digest of the given node's public key (fingerprint). 167 For example, "gnu.org.noisetor.exit" will route the client to 168 "gnu.org" via the Tor node nicknamed "noisetor". Using the 169 fingerprint instead of the nickname ensures that the path selection 170 uses a specific Tor exit node, and is harder to remember: e.g., 171 "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". 173 When Tor sees an address in this format, it uses the specified 174 "nickname-or-fingerprint" as the exit node. If no "hostname" 175 component is given, Tor defaults to the published IPv4 address of the 176 Tor exit node [TOR-EXTSOCKS]. 178 Because "hostname" is allegedly valid, the total length of a .exit 179 construct may exceed the maximum length allowed for domain names. 180 Moreover, the resolution of "hostname" happens at the exit node. 181 Trying to resolve such invalid domain names, including chaining .exit 182 names will likely return a DNS lookup failure at the first exit node. 184 The "EXIT" domain is special in the following ways: 186 1. Users can use these names as they would other domain names, 187 entering them anywhere that they would otherwise enter a 188 conventional DNS domain name. 190 Since .exit names correspond to a Tor-specific routing construct 191 to reach target hosts via chosen Tor exit nodes, users need to be 192 aware that they do not belong to regular DNS and that the actual 193 target precedes the second-level domain name. 195 2. Application software MAY recognize that .exit domains are special 196 and when they do SHOULD NOT pass requests for these domains to 197 DNS resolvers and libraries. 199 As mentioned in items 4 and 5 below, regular DNS resolution is 200 expected to respond with NXDOMAIN. Therefore, if it can 201 differentiate between DNS and P2P name resolution, application 202 software: 204 * MUST expect NXDOMAIN as the only valid DNS response, and 206 * SHOULD treat other answers from DNS as errors. 208 Tor-aware applications MAY also use Tor resolvers directly. 210 3. Name resolution APIs and libraries SHOULD either respond to 211 requests for .exit names by resolving them via the Tor protocol, 212 or respond with NXDOMAIN. 214 4. Caching DNS servers SHOULD recognize .exit names as special and 215 SHOULD NOT, by default, attempt to look up NS records for them, 216 or otherwise query authoritative DNS servers in an attempt to 217 resolve .exit names. Instead, caching DNS servers SHOULD, by 218 default, generate immediate negative responses for all such 219 queries. 221 5. Authoritative DNS servers are not expected to treat .exit domain 222 requests specially. In practice, they MUST answer with NXDOMAIN, 223 as "EXIT" is not available via global DNS resolution, and not 224 doing so MAY put users' privacy at risk (see item 6). 226 6. DNS server operators SHOULD be aware that .exit names are 227 reserved for use with Tor, and MUST NOT override their resolution 228 (e.g., to redirect users to another service or error 229 information). 231 7. DNS registries/registrars MUST NOT grant any request to register 232 .exit names. This helps avoid conflicts [SAC45]. These names 233 are defined by the Tor address specification, and they fall 234 outside the set of names available for allocation by registries/ 235 registrars. 237 5. Security Considerations 239 Specific software performs the resolution of the six Special-Use 240 Domain Names presented in this document; this resolution process 241 happens outside of the scope of DNS. Leakage of requests to such 242 domains to the global operational DNS can cause interception of 243 traffic that might be misused to monitor, censor, or abuse the user's 244 trust, and lead to privacy issues with potentially tragic 245 consequences for the user. 247 This document reserves these Top-Level Domain names to minimize the 248 possibility of confusion, conflict, and especially privacy risks for 249 users. 251 In the introduction of this document, there's a requirement that DNS 252 operators do not override resolution of the "EXIT" Names. This is a 253 regulatory measure and cannot prevent such malicious abuse in 254 practice. Its purpose is to limit any information leak that would 255 result from incorrectly configured systems, and to avoid that 256 resolvers make unnecessary contact to the DNS Root Zone for such 257 domains. Verisign, Inc., as well as several Internet service 258 providers (ISPs) have notoriously abused their position to override 259 NXDOMAIN responses to their customers in the past 260 [SSAC-NXDOMAIN-Abuse]. For example, if a DNS operator would decide 261 to override NXDOMAIN and send advertising to leaked .onion sites, the 262 information leak to the DNS would extend to the advertising server, 263 with unpredictable consequences. Thus, implementors should be aware 264 that any positive response coming from DNS must be considered with 265 extra care, as it suggests a leak to DNS has been made, contrary to 266 user's privacy expectations. 268 The reality of X.509 Certificate Authorities (CAs) creating 269 misleading certificates for these pTLDs due to ignorance stresses the 270 need to document their special use. Certificate Authorities MUST NOT 271 create certificates for "EXIT" Top-level domains. Nevertheless, 272 clients SHOULD accept certificates for these Top-Level domains as 273 they may be created legitimately by local proxies on the fly. 275 Finally, legacy applications that do not explicitly support the pTLD 276 significantly increase the risk of pTLD queries escaping to DNS, as 277 they are entirely dependent on the correct configuration on the 278 operating system. 280 6. IANA Considerations 282 The Internet Assigned Numbers Authority (IANA) reserved the following 283 entries in the Special-Use Domain Names registry [RFC6761]: 285 .exit 287 [TO REMOVE: the assignement URL is https://www.iana.org/assignments/ 288 special-use-domain-names/ ] 290 7. Acknowledgements 292 The authors thank the I2P and Namecoin developers for their 293 constructive feedback, as well as Mark Nottingham for his proof- 294 reading and valuable feedback. The authors also thank the members of 295 DNSOP WG for their critiques and suggestions. 297 8. References 299 8.1. Normative References 301 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 302 STD 13, RFC 1034, November 1987. 304 [RFC1035] Mockapetris, P., "Domain names - implementation and 305 specification", STD 13, RFC 1035, November 1987. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 311 NCACHE)", RFC 2308, March 1998. 313 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 314 RFC 6761, February 2013. 316 8.2. Informative References 318 [Dingledine2004] 319 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 320 second-generation onion router", 2004, . 323 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 324 Top Level Domain Queries at the Root Level of the Domain 325 Name System", November 2010, 326 . 329 [SSAC-NXDOMAIN-Abuse] 330 ICANN Security and Stability Advisory Committee, 331 "Redirection in the COM and NET Domains", July 2004, 332 . 335 [TOR-EXTSOCKS] 336 Mathewson, N. and R. Dingledine, "Tor's extensions to the 337 SOCKS protocol", February 2014, 338 . 341 [TOR-PATH] 342 Mathewson, N. and R. Dingledine, "Tor Path Specification", 343 November 2014, 344 . 347 [TOR-PROTOCOL] 348 Dingledine, R. and N. Mathewson, "Tor Protocol 349 Specification", August 2014, 350 . 353 Authors' Addresses 355 Christian Grothoff 356 INRIA 357 Equipe Decentralisee 358 INRIA Rennes Bretagne Atlantique 359 263 avenue du General Leclerc 360 Campus Universitaire de Beaulieu 361 Rennes, Bretagne F-35042 362 FR 364 Email: christian@grothoff.org 365 Matthias Wachs 366 Technische Universitaet Muenchen 367 Free Secure Network Systems Group 368 Lehrstuhl fuer Netzarchitekturen und Netzdienste 369 Boltzmannstrasse 3 370 Technische Universitaet Muenchen 371 Garching bei Muenchen, Bayern D-85748 372 DE 374 Email: wachs@net.in.tum.de 376 Hellekin O. Wolf (editor) 377 GNU consensus 379 Email: hellekin@gnu.org 381 Jacob Appelbaum 382 Tor Project Inc. 384 Email: jacob@appelbaum.net 386 Leif Ryge 387 Tor Project Inc. 389 Email: leif@synthesize.us