Internet Engineering Task Force C. Grothoff Internet-Draft INRIA Intended status: Informational M. Wachs Expires: December 24, 2015 Technische Universitaet Muenchen H. Wolf, Ed. GNU consensus J. Appelbaum L. Ryge Tor Project Inc. June 30, 2015 The .exit Special-Use Domain Name of Tor draft-grothoff-iesg-special-use-p2p-exit-00 Abstract This document registers a Special-Use Domain Name for use with the Tor Project, as per RFC6761. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 24, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Grothoff, et al. Expires December 24, 2015 [Page 1] Internet-Draft Special-Use-p2p-Exit June 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology and Conventions Used in This Document . . . . . . 3 4. The "EXIT" Client Source Routing pTLD . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Domain Name System (DNS) is primarily used to map human-memorable names to IP addresses, which are used for routing but generally not meaningful for humans. The Tor project supports the use of names to specify where the user wishes to exit the P2P overlay. As compatibility with applications using domain names is desired, this mechanism requires an exclusive alternative Top-Level Domains to avoid conflict between the Tor namespace and the DNS hierarchy. In order to avoid interoperability issues with DNS as well as to address security and privacy concerns, this document registers the "EXIT" Special-Use Domain Names for use within the Tor network, as per [RFC6761]. The Tor network uses this pTLD to control overlay routing and to securely specify path selection choices [TOR-PATH]. 2. Applicability [RFC6761] Section 3 states: "[I]f a domain name has special properties that affect the way hardware and software implementations handle the name, that apply universally regardless of what network the implementation may be connected to, then that domain name may be a candidate for having the IETF declare it to be a Special-Use Domain Name and specify Grothoff, et al. Expires December 24, 2015 [Page 2] Internet-Draft Special-Use-p2p-Exit June 2015 what special treatment implementations should give to that name. On the other hand, if declaring a given name to be special would result in no change to any implementations, then that suggests that the name may not be special in any material way, and it may be more appropriate to use the existing DNS mechanisms [RFC1034] to provide the desired delegation, data, or lack-of-data, for the name in question. Where the desired behaviour can be achieved via the existing domain name registration processes, that process should be used. Reservation of a Special-Use Domain Name is not a mechanism for circumventing normal domain name registration processes." The set "EXIT" pTLD reserved by this document meets this requirement, as it has the following specificities: o "EXIT" resolution does not depend on the DNS context: The name specifies a Tor exit node, and thus the response is not even really DNS-compatible; Tor uses its own P2P protocols for resolving the destination specified in an .exit name. o When Tor is properly implemented, the implementation MUST intercept queries for the "EXIT" to ensure that these Tor-specific names cannot leak into the DNS. o Finally, in order for Tor to properly interoperate with DNS and to provide security and privacy features matching user expectations, this document specifies desirable changes in existing DNS software and DNS operations. 3. Terminology and Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The word "peer" is used in the meaning of a individual system on the network. The abbreviation "pTLD" is used in this document to mean a pseudo Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] reserved to P2P Systems in this document. A pTLD is mentioned in capitals, and within double quotes to mark the difference with a regular DNS gTLD. In this document, ".tld" (lowercase, with quotes) means: any domain or hostname within the scope of a given pTLD, while .tld (lowercase, without quotes) refers to an adjective form. Grothoff, et al. Expires December 24, 2015 [Page 3] Internet-Draft Special-Use-p2p-Exit June 2015 The word "NXDOMAIN" refers to an alternate expression for the "Name Error" RCODE as described in section 4.1.1 of [RFC1035]. When referring to "NXDOMAIN" and negative caching [RFC2308] response, this document means an authoritative (AA=1) name error (RCODE=3) response exclusively. The Tor-related names such as 'circuit', 'exit', 'node', 'relay', 'stream', and related Tor terms are described in [Dingledine2004] and the Tor protocol specification [TOR-PROTOCOL]. 4. The "EXIT" Client Source Routing pTLD The .exit suffix is used as an in-band source routing control channel, usually for selection of a specific Tor relay during path creation as the last node in the Tor circuit. It may be used to access a DNS host via specific Torservers, in the form "hostname.nickname-or-fingerprint.exit", where the "hostname" is a valid hostname, and the "nickname-or-fingerprint" is either the nickname of a Tor relay in the Tor network consensus, or the hex- encoded SHA1 digest of the given node's public key (fingerprint). For example, "gnu.org.noisetor.exit" will route the client to "gnu.org" via the Tor node nicknamed "noisetor". Using the fingerprint instead of the nickname ensures that the path selection uses a specific Tor exit node, and is harder to remember: e.g., "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". When Tor sees an address in this format, it uses the specified "nickname-or-fingerprint" as the exit node. If no "hostname" component is given, Tor defaults to the published IPv4 address of the Tor exit node [TOR-EXTSOCKS]. Because "hostname" is allegedly valid, the total length of a .exit construct may exceed the maximum length allowed for domain names. Moreover, the resolution of "hostname" happens at the exit node. Trying to resolve such invalid domain names, including chaining .exit names will likely return a DNS lookup failure at the first exit node. The "EXIT" domain is special in the following ways: 1. Users can use these names as they would other domain names, entering them anywhere that they would otherwise enter a conventional DNS domain name. Since .exit names correspond to a Tor-specific routing construct to reach target hosts via chosen Tor exit nodes, users need to be Grothoff, et al. Expires December 24, 2015 [Page 4] Internet-Draft Special-Use-p2p-Exit June 2015 aware that they do not belong to regular DNS and that the actual target precedes the second-level domain name. 2. Application software MAY recognize that .exit domains are special and when they do SHOULD NOT pass requests for these domains to DNS resolvers and libraries. As mentioned in items 4 and 5 below, regular DNS resolution is expected to respond with NXDOMAIN. Therefore, if it can differentiate between DNS and P2P name resolution, application software: * MUST expect NXDOMAIN as the only valid DNS response, and * SHOULD treat other answers from DNS as errors. Tor-aware applications MAY also use Tor resolvers directly. 3. Name resolution APIs and libraries SHOULD either respond to requests for .exit names by resolving them via the Tor protocol, or respond with NXDOMAIN. 4. Caching DNS servers SHOULD recognize .exit names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve .exit names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. 5. Authoritative DNS servers are not expected to treat .exit domain requests specially. In practice, they MUST answer with NXDOMAIN, as "EXIT" is not available via global DNS resolution, and not doing so MAY put users' privacy at risk (see item 6). 6. DNS server operators SHOULD be aware that .exit names are reserved for use with Tor, and MUST NOT override their resolution (e.g., to redirect users to another service or error information). Grothoff, et al. Expires December 24, 2015 [Page 5] Internet-Draft Special-Use-p2p-Exit June 2015 7. DNS registries/registrars MUST NOT grant any request to register .exit names. This helps avoid conflicts [SAC45]. These names are defined by the Tor address specification, and they fall outside the set of names available for allocation by registries/ registrars. 5. Security Considerations Specific software performs the resolution of the six Special-Use Domain Names presented in this document; this resolution process happens outside of the scope of DNS. Leakage of requests to such domains to the global operational DNS can cause interception of traffic that might be misused to monitor, censor, or abuse the user's trust, and lead to privacy issues with potentially tragic consequences for the user. This document reserves these Top-Level Domain names to minimize the possibility of confusion, conflict, and especially privacy risks for users. In the introduction of this document, there's a requirement that DNS operators do not override resolution of the "EXIT" Names. This is a regulatory measure and cannot prevent such malicious abuse in practice. Its purpose is to limit any information leak that would result from incorrectly configured systems, and to avoid that resolvers make unnecessary contact to the DNS Root Zone for such domains. Verisign, Inc., as well as several Internet service providers (ISPs) have notoriously abused their position to override NXDOMAIN responses to their customers in the past [SSAC-NXDOMAIN-Abuse]. For example, if a DNS operator would decide to override NXDOMAIN and send advertising to leaked .onion sites, the information leak to the DNS would extend to the advertising server, with unpredictable consequences. Thus, implementors should be aware that any positive response coming from DNS must be considered with extra care, as it suggests a leak to DNS has been made, contrary to user's privacy expectations. The reality of X.509 Certificate Authorities (CAs) creating misleading certificates for these pTLDs due to ignorance stresses the need to document their special use. Certificate Authorities MUST NOT create certificates for "EXIT" Top-level domains. Nevertheless, clients SHOULD accept certificates for these Top-Level domains as they may be created legitimately by local proxies on the fly. Finally, legacy applications that do not explicitly support the pTLD significantly increase the risk of pTLD queries escaping to DNS, as Grothoff, et al. Expires December 24, 2015 [Page 6] Internet-Draft Special-Use-p2p-Exit June 2015 they are entirely dependent on the correct configuration on the operating system. 6. IANA Considerations The Internet Assigned Numbers Authority (IANA) reserved the following entries in the Special-Use Domain Names registry [RFC6761]: .exit [TO REMOVE: the assignement URL is https://www.iana.org/assignments/ special-use-domain-names/ ] 7. Acknowledgements The authors thank the I2P and Namecoin developers for their constructive feedback, as well as Mark Nottingham for his proof- reading and valuable feedback. The authors also thank the members of DNSOP WG for their critiques and suggestions. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. 8.2. Informative References [Dingledine2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", 2004, . Grothoff, et al. Expires December 24, 2015 [Page 7] Internet-Draft Special-Use-p2p-Exit June 2015 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid Top Level Domain Queries at the Root Level of the Domain Name System", November 2010, . [SSAC-NXDOMAIN-Abuse] ICANN Security and Stability Advisory Committee, "Redirection in the COM and NET Domains", July 2004, . [TOR-EXTSOCKS] Mathewson, N. and R. Dingledine, "Tor's extensions to the SOCKS protocol", February 2014, . [TOR-PATH] Mathewson, N. and R. Dingledine, "Tor Path Specification", November 2014, . [TOR-PROTOCOL] Dingledine, R. and N. Mathewson, "Tor Protocol Specification", August 2014, . Authors' Addresses Christian Grothoff INRIA Equipe Decentralisee INRIA Rennes Bretagne Atlantique 263 avenue du General Leclerc Campus Universitaire de Beaulieu Rennes, Bretagne F-35042 FR Email: christian@grothoff.org Grothoff, et al. Expires December 24, 2015 [Page 8] Internet-Draft Special-Use-p2p-Exit June 2015 Matthias Wachs Technische Universitaet Muenchen Free Secure Network Systems Group Lehrstuhl fuer Netzarchitekturen und Netzdienste Boltzmannstrasse 3 Technische Universitaet Muenchen Garching bei Muenchen, Bayern D-85748 DE Email: wachs@net.in.tum.de Hellekin O. Wolf (editor) GNU consensus Email: hellekin@gnu.org Jacob Appelbaum Tor Project Inc. Email: jacob@appelbaum.net Leif Ryge Tor Project Inc. Email: leif@synthesize.us Grothoff, et al. Expires December 24, 2015 [Page 9]