The Tor Project, Inc

jacob@appelbaum.net

Facebook

alecm@fb.com

General dnsop Internet-Draft onion tld dns This document registers the “.onion” Special-Use Domain Name.

The Tor network has the ability to host network services using the “.onion” Special-Use Top-Level Domain. Such names can be used as other domain names would be (e.g., in URLs ), but instead of using the DNS infrastructure, .onion names functionally correspond to the identity of a given service, thereby combining location and authentication. .onion names are used to 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. .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. In this way, .onion names are “special” in the sense defined by Section 3; they require hardware and software implementations to change their handling in order to achieve the desired properties of the name (see ). These differences are listed in . Like Top-Level Domain Names, .onion names 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 . Note that .onion names are required conform to DNS name syntax (as defined in Section 3.5 of and Section 2.1 of ), as they will still be exposed to DNS implementations. See and for the details of the creation and use of .onion names.

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 .

These properties have the following effects upon parties using or processing .onion names (as per ): Users: Human users are expected to recognize .onion names as having different security properties (see ), and also as being only available through software that is aware of onion names. Application Software: Applications (including proxies) that implement the Tor protocol MUST recognize .onion names as special by either accessing them directly, or using a proxy (e.g., SOCKS ) 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. Name Resolution APIs and Libraries: Resolvers MUST either respond to requests for .onion names by resolving them according to or by responding with NXDOMAIN. Caching DNS Servers: Caching servers, where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. Authoritative DNS Servers: Authoritative servers MUST respond to queries for .onion with NXDOMAIN. DNS Server Operators: Operators MUST 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). DNS Registries/Registrars: Registrars MUST NOT register .onion names; all such requests MUST be denied. Note that the restriction upon the registration of .onion names does not prohibit IANA from inserting a record into the root zone database to reserve the name. Likewise, it does not prevent non-DNS service providers (such as trust providers) from supporting .onion names in their applications.

This document registers “onion” in the registry of Special-Use Domain Names . See for the registration template.

The security properties of .onion names can be compromised if, for example: The server “leaks” its identity in another way (e.g., in an application-level message), or The access protocol is implemented or deployed incorrectly, or The access protocol itself is found to have a flaw. Users must take special precautions to ensure that the .onion name they are communicating with is the intended one, as attackers may be able to find keys which produce service names that are visually or semantically similar to the desired service. This risk is magnified because .onion names are typically not human-meaningful. It can be mitigated by generating human meaningful .onion names (at considerable computing expense), or through users using bookmarks and other trusted stores when following links. Also, users need to understand the difference between a .onion name used and accessed directly via Tor-capable software, versus .onion subdomains of other top-level domain names and providers (e.g., the difference between example.onion and example.onion.tld). The cryptographic label for a .onion name is constructed by applying a function to the public key of the server, the output of which is rendered as a string and concatenated with the string “.onion”. Dependent upon the specifics of the function used, an attacker may 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. A legacy client may inadvertently attempt to resolve a “.onion” name through the DNS. This causes a disclosure that the client is attempting to use Tor to reach a specific service. Malicious resolvers could be engineered to capture and record such leaks, which might have very adverse consequences for the well-being of the Tor user. This issue is mitigated if the client’s Tor software is updated to not leak such queries, or if the client’s DNS software is updated to drop any request to the “.onion” TLD.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. This RFC is an official specification for the Internet community. It incorporates by reference, amends, corrects, and supplements the primary protocol standards documents relating to hosts. [STANDARDS-TRACK] This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.

Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for their input and review. This specification builds upon previous work by Christian Grothoff, Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to register .onion in conjunction with other, similar Special-Use Top-Level Domain Names.