https://www.ietf.org/id/draft-appelbaum-dnsop-onion-tld-00.txt dnsop J. Appelbaum Internet-Draft Tor Project Inc. Intended status: Standards Track A. Muffett Expires: September 6, 2015 Facebook March 5, 2015 The .onion Special-Use Domain Name draft-appelbaum-dnsop-onion-tld-00 Abstract This document registers the ".onion" Special-Use Domain Name. 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 September 6, 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 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 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 2. The ".onion" Special-Use TLD . . . . . . . . . . . . . . . . 2 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The Tor network [Dingledine2004] has the ability to host network services using the ".onion" Top-Level Domain. Such addresses can be used as other domain names would be (e.g., in URLs [RFC3986]), but instead of using the DNS infrastructure, .onion names are hashes that correspond to the identity of a given service, thereby combining location and authentication. In this way, .onion names are "special" in the sense defined by [RFC6761] Section 3; they require hardware and software implementations to change their handling, in order to achieve the desired properties of the name (see Section 4). These differences are listed in Section 2. Like other TLDs, .onion addresses can have an arbitrary number of subdomain components. This information is not meaningful to the Tor protocol, but can be used in application protocols like HTTP [RFC7230]. See [tor-address] and [tor-rendezvous] for the details of the creation and use of .onion names. 1.1. Notational Conventions 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]. 2. The ".onion" Special-Use TLD These properties have the following effects upon parties using or processing .onion names (as per [RFC6761]): 1. Users: human users are expected to recognize .onion names as having different security properties, and also being only available through software that is aware of onion addresses. 2. Application Software: Applications that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS [RFC1928]) to do so. Applications that do not implement the Tor protocol SHOULD generate an error upon the use of .onion, and SHOULD NOT perform a DNS lookup. 3. Name Resolution APIs and Libraries: Resolvers that implement the Tor protocol MUST either respond to requests for .onion names by resolving them (see [tor-rendezvous]) or by responding with NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN. 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look up records for .onion names. They SHOULD generate NXDOMAIN for all such queries. 5. Authoritative DNS Servers: Authoritative servers SHOULD respond to queries for .onion with NXDOMAIN. 6. DNS Server Operators: Operators SHOULD NOT configure an authoritative DNS server to answer queries for .onion. If they do so, client software is likely to ignore any results (see above). 7. DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied. 3. IANA Considerations This document registers the "onion" TLD in the registry of Special- Use Domain Names [RFC6761]. See Section 2 for the registration template. 4. Security Considerations .onion names are often used provide access to end to end encrypted, secure, anonymized services; that is, the identity and location of the server is obscured from the client. The location of the client is obscured from the server. The identity of the client may or may not be disclosed through an optional cryptographic authentication process. These properties can be compromised if, for example: o The server "leaks" its identity in another way (e.g., in an application-level message), or o The access protocol is implemented or deployed incorrectly, or o The access protocol itself is found to have a flaw. .onion names are self-authenticating, in that they are derived from the cryptographic keys used by the server in a client verifiable manner during connection establishment. As a result, the cryptographic label component of a .onion name is not intended to be human-meaningful. The Tor network is designed to not be subject to any central controlling authorities with regards to routing and service publication, so .onion names cannot be registered, assigned, transferred or revoked. "Ownership" of a .onion name is derived solely from control of a public/private key pair which corresponds to the algorithmic derivation of the name. Users must take special precautions to ensure that the .onion name they are communicating with is correct, as attackers may be able to find keys which produce service names that are visually or apparently semantically similar to the desired service. Also, users need be aware of the difference between a .onion name used and accessed directly via Tor-capable software, versus .onion subdomains of other TLDs and providers (e.g., the difference between example.onion and example.onion.tld). The cryptographic label for an .onion name is constructed by hashing the public key of the service with SHA1, truncating the output of the hash to 80 bits in length and the resulting hash output is concatenated with the string ".onion". As the number of output bits in generating the .onion name is less than the full size of the corresponding public key, an attacker may also be able to find a key that produces a collision with the same .onion name with substantially less work than a cryptographic attack on the full strength key. If this is possible the attacker may be able to impersonate the service on the network. If client software attempts to resolve a .onion name, it can leak the identity of the service that the user is attempting to access to DNS resolvers, authoritative DNS servers, and observers on the intervening network. This can be mitigated by following the recommendations in Section 2. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013. 5.2. Informative References [Dingledine2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the second-generation onion router", 2004, <https://www.onion- router.net/Publications/tor-design.pdf>. [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014. [tor-address] Mathewson, N. and R. Dingledine, "Special Hostnames in Tor", September 2001, <https://gitweb.torproject.org/torspec.git/plain/address- spec.txt>. [tor-rendezvous] Mathewson, N. and R. Dingledine, "Tor Rendezvous Specification", April 2014, <https://gitweb.torproject.org/torspec.git/plain/rend- spec.txt>. Authors' Addresses Jacob Appelbaum Tor Project Inc. Alec Muffett Facebook ...