The .onion Special-Use Domain Name
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 addresses 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.
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 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 .
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, and also being only available through software
that is aware of onion addresses.
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 either respond to
requests for .onion names by resolving them according to or by
responding with NXDOMAIN.
Caching DNS Servers: Caching servers 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.
This document registers “onion” in the registry of Special-Use Domain Names . See for the registration template.
.onion names are often 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.
These properties 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.
.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 semantically similar to
the desired service.
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.
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 .
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
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. Authors who follow these guidelines
should incorporate this phrase near the beginning of their 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
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Special-Use Domain Names
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.
SOCKS Protocol Version 5
Bell-Northern Research Ltd
P.O. Box 3511
Stn. C
Ottawa
Ontario
K1Y 4H7
CA
+1 613 763 9145
mleech@bnr.ca
International Business Machines
NEC Systems Laboratory
Unify Corporation
Independent Consultant
Hewlett-Packard Company
Uniform Resource Identifier (URI): Generic Syntax
World Wide Web Consortium
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge
MA
02139
USA
+1-617-253-5702
+1-617-258-5999
timbl@w3.org
http://www.w3.org/People/Berners-Lee/
Day Software
5251 California Ave., Suite 110
Irvine
CA
92617
USA
+1-949-679-2960
+1-949-679-2972
fielding@gbiv.com
http://roy.gbiv.com/
Adobe Systems Incorporated
345 Park Ave
San Jose
CA
95110
USA
+1-408-536-3024
LMM@acm.org
http://larry.masinter.net/
Applications
uniform resource identifier
URI
URL
URN
WWW
resource
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.
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
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.
Tor: the second-generation onion router
Special Hostnames in Tor
Tor Rendezvous Specification
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.