draft-ietf-dnsop-onion-tld-01.txt   rfc7686.txt 
dnsop J. Appelbaum Internet Engineering Task Force (IETF) J. Appelbaum
Internet-Draft The Tor Project, Inc Request for Comments: 7686 The Tor Project, Inc.
Intended status: Standards Track A. Muffett Category: Standards Track A. Muffett
Expires: March 12, 2016 Facebook ISSN: 2070-1721 Facebook
September 9, 2015 October 2015
The .onion Special-Use Domain Name The ".onion" Special-Use Domain Name
draft-ietf-dnsop-onion-tld-01
Abstract Abstract
This document registers the ".onion" Special-Use Domain Name. This document registers the ".onion" Special-Use Domain Name.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 12, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7686.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. The ".onion" Special-Use Domain Name . . . . . . . . . . . . 3 2. The ".onion" Special-Use Domain Name . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The Tor network [Dingledine2004] has the ability to host network The Tor network [Dingledine2004] has the ability to host network
services using the ".onion" Special-Use Top-Level Domain. Such names services using the ".onion" Special-Use Top-Level Domain Name. Such
can be used as other domain names would be (e.g., in URLs [RFC3986]), names can be used as other domain names would be (e.g., in URLs
but instead of using the DNS infrastructure, .onion names [RFC3986]), but instead of using the DNS infrastructure, .onion names
functionally correspond to the identity of a given service, thereby functionally correspond to the identity of a given service, thereby
combining location and authentication. combining location and authentication.
.onion names are used to provide access to end to end encrypted, .onion names are used to provide access to end to end encrypted,
secure, anonymized services; that is, the identity and location of secure, anonymized services; that is, the identity and location of
the server is obscured from the client. The location of the client 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 is obscured from the server. The identity of the client may or may
not be disclosed through an optional cryptographic authentication not be disclosed through an optional cryptographic authentication
process. process.
.onion names are self-authenticating, in that they are derived from .onion names are self-authenticating, in that they are derived from
the cryptographic keys used by the server in a client-verifiable the cryptographic keys used by the server in a client-verifiable
manner during connection establishment. As a result, the manner during connection establishment. As a result, the
cryptographic label component of a .onion name is not intended to be cryptographic label component of a .onion name is not intended to be
human-meaningful. human-meaningful.
The Tor network is designed to not be subject to any central The Tor network is designed to not be subject to any central
controlling authorities with regards to routing and service controlling authorities with regards to routing and service
publication, so .onion names cannot be registered, assigned, publication, so .onion names cannot be registered, assigned,
transferred or revoked. "Ownership" of a .onion name is derived transferred or revoked. "Ownership" of a .onion name is derived
solely from control of a public/private key pair which corresponds to solely from control of a public/private key pair that corresponds to
the algorithmic derivation of the name. the algorithmic derivation of the name.
In this way, .onion names are "special" in the sense defined by In this way, .onion names are "special" in the sense defined by
[RFC6761] Section 3; they require hardware and software Section 3 of [RFC6761]; they require hardware and software
implementations to change their handling in order to achieve the implementations to change their handling in order to achieve the
desired properties of the name (see Section 4). These differences desired properties of the name (see Section 4). These differences
are listed in Section 2. are listed in Section 2.
Like Top-Level Domain Names, .onion names can have an arbitrary Like Top-Level Domain Names, .onion names can have an arbitrary
number of subdomain components. This information is not meaningful number of subdomain components. This information is not meaningful
to the Tor protocol, but can be used in application protocols like to the Tor protocol, but can be used in application protocols like
HTTP [RFC7230]. HTTP [RFC7230].
Note that .onion names are required conform to DNS name syntax (as Note that .onion names are required to conform with DNS name syntax
defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]), as (as defined in Section 3.5 of [RFC1034] and Section 2.1 of
they will still be exposed to DNS implementations. [RFC1123]), as they will still be exposed to DNS implementations.
See [tor-address] and [tor-rendezvous] for the details of the See [tor-address] and [tor-rendezvous] for the details of the
creation and use of .onion names. creation and use of .onion names.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. The ".onion" Special-Use Domain Name 2. The ".onion" Special-Use Domain Name
These properties have the following effects upon parties using or These properties have the following effects upon parties using or
processing .onion names (as per [RFC6761]): processing .onion names (as per [RFC6761]):
1. Users: Human users are expected to recognize .onion names as 1. Users: Human users are expected to recognize .onion names as
having different security properties (see Section 1), and also as having different security properties (see Section 1) and also as
being only available through software that is aware of onion being only available through software that is aware of .onion
names. names.
2. Application Software: Applications (including proxies) that 2. Application Software: Applications (including proxies) that
implement the Tor protocol MUST recognize .onion names as special implement the Tor protocol MUST recognize .onion names as special
by either accessing them directly, or using a proxy (e.g., SOCKS by either accessing them directly or using a proxy (e.g., SOCKS
[RFC1928]) to do so. Applications that do not implement the Tor [RFC1928]) to do so. Applications that do not implement the Tor
protocol SHOULD generate an error upon the use of .onion, and protocol SHOULD generate an error upon the use of .onion and
SHOULD NOT perform a DNS lookup. SHOULD NOT perform a DNS lookup.
3. Name Resolution APIs and Libraries: Resolvers MUST either respond 3. Name Resolution APIs and Libraries: Resolvers MUST either respond
to requests for .onion names by resolving them according to to requests for .onion names by resolving them according to
[tor-rendezvous] or by responding with NXDOMAIN. [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].
4. Caching DNS Servers: Caching servers, where not explicitly 4. Caching DNS Servers: Caching servers, where not explicitly
adapted to interoperate with Tor, SHOULD NOT attempt to look up adapted to interoperate with Tor, SHOULD NOT attempt to look up
records for .onion names. They MUST generate NXDOMAIN for all records for .onion names. They MUST generate NXDOMAIN for all
such queries. such queries.
5. Authoritative DNS Servers: Authoritative servers MUST respond to 5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN. queries for .onion with NXDOMAIN.
6. DNS Server Operators: Operators MUST NOT configure an 6. DNS Server Operators: Operators MUST NOT configure an
skipping to change at page 4, line 22 skipping to change at page 4, line 22
Note that the restriction upon the registration of .onion names does Note that the restriction upon the registration of .onion names does
not prohibit IANA from inserting a record into the root zone database not prohibit IANA from inserting a record into the root zone database
to reserve the name. to reserve the name.
Likewise, it does not prevent non-DNS service providers (such as Likewise, it does not prevent non-DNS service providers (such as
trust providers) from supporting .onion names in their applications. trust providers) from supporting .onion names in their applications.
3. IANA Considerations 3. IANA Considerations
This document registers "onion" in the registry of Special-Use Domain This document registers ".onion" in the registry of Special-Use
Names [RFC6761]. See Section 2 for the registration template. Domain Names [RFC6761]. See Section 2 for the registration template.
4. Security Considerations 4. Security Considerations
The security properties of .onion names can be compromised if, for The security properties of .onion names can be compromised if, for
example: example:
o The server "leaks" its identity in another way (e.g., in an o The server "leaks" its identity in another way (e.g., in an
application-level message), or application-level message), or
o The access protocol is implemented or deployed incorrectly, or o The access protocol is implemented or deployed incorrectly, or
o The access protocol itself is found to have a flaw. o The access protocol itself is found to have a flaw.
Users must take special precautions to ensure that the .onion name Users must take special precautions to ensure that the .onion name
they are communicating with is the intended one, as attackers may be they are communicating with is the intended one, as attackers may be
able to find keys which produce service names that are visually or able to find keys that produce service names that are visually or
semantically similar to the desired service. This risk is magnified semantically similar to the desired service. This risk is magnified
because .onion names are typically not human-meaningful. It can be because .onion names are typically not human-meaningful. It can be
mitigated by generating human meaningful .onion names (at mitigated by generating human-meaningful .onion names (at
considerable computing expense), or through users using bookmarks and considerable computing expense) or through users using bookmarks and
other trusted stores when following links. other trusted stores when following links.
Also, users need to understand the difference between a .onion name Also, users need to understand the difference between a .onion name
used and accessed directly via Tor-capable software, versus .onion used and accessed directly via Tor-capable software, versus .onion
subdomains of other top-level domain names and providers (e.g., the subdomains of other top-level domain names and providers (e.g., the
difference between example.onion and example.onion.tld). difference between example.onion and example.onion.tld).
The cryptographic label for a .onion name is constructed by applying 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 a function to the public key of the server, the output of which is
rendered as a string and concatenated with the string ".onion". rendered as a string and concatenated with the string .onion.
Dependent upon the specifics of the function used, an attacker may be 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 able to find a key that produces a collision with the same .onion
name with substantially less work than a cryptographic attack on the name with substantially less work than a cryptographic attack on the
full strength key. If this is possible the attacker may be able to full strength key. If this is possible the attacker may be able to
impersonate the service on the network. impersonate the service on the network.
A legacy client may inadvertently attempt to resolve a ".onion" name A legacy client may inadvertently attempt to resolve a .onion name
through the DNS. This causes a disclosure that the client is through the DNS. This causes a disclosure that the client is
attempting to use Tor to reach a specific service. Malicious attempting to use Tor to reach a specific service. Malicious
resolvers could be engineered to capture and record such leaks, which resolvers could be engineered to capture and record such leaks, which
might have very adverse consequences for the well-being of the Tor might have very adverse consequences for the well-being of the user.
user. This issue is mitigated if the client's Tor software is This issue is mitigated if the client's software is updated to not
updated to not leak such queries, or if the client's DNS software is leak such queries or updated to support [tor-rendezvous], or if the
updated to drop any request to the ".onion" TLD. client's DNS software is updated to drop any request to the .onion
special-use domain name.
5. References 5. References
5.1. Normative References 5.1. Normative References
[Dingledine2004] [Dingledine2004]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
second-generation onion router", 2004, Second-Generation Onion Router", August 2004,
<https://spec.torproject.org/tor-spec>. <https://svn.torproject.org/svn/projects/design-paper/
tor-design.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013, RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>. <http://www.rfc-editor.org/info/rfc6761>.
[tor-address] [tor-address]
Mathewson, N. and R. Dingledine, "Special Hostnames in Mathewson, N. and The Tor Project, "Special Hostnames in
Tor", September 2001, <https://spec.torproject.org/ Tor", 2006, <https://spec.torproject.org/address-spec>.
address-spec>.
[tor-rendezvous] [tor-rendezvous]
Mathewson, N. and R. Dingledine, "Tor Rendezvous The Tor Project, "Tor Rendezvous Specification", April
Specification", April 2014, <https://spec.torproject.org/ 2014, <https://spec.torproject.org/rend-spec>.
rend-spec>.
5.2. Informative References 5.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, DOI 10.17487/ Application and Support", STD 3, RFC 1123,
RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>. <http://www.rfc-editor.org/info/rfc1123>.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI L. Jones, "SOCKS Protocol Version 5", RFC 1928,
10.17487/RFC1928, March 1996, DOI 10.17487/RFC1928, March 1996,
<http://www.rfc-editor.org/info/rfc1928>. <http://www.rfc-editor.org/info/rfc1928>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
Appendix A. Acknowledgements Acknowledgements
Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for
their input and review. their input and review.
This specification builds upon previous work by Christian Grothoff, This specification builds upon previous work by Christian Grothoff,
Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to
register .onion in conjunction with other, similar Special-Use Top- register .onion in conjunction with other, similar Special-Use Top-
Level Domain Names. Level Domain Names.
Authors' Addresses Authors' Addresses
Jacob Appelbaum Jacob Appelbaum
The Tor Project, Inc The Tor Project, Inc. & Technische Universiteit Eindhoven
Email: jacob@appelbaum.net Email: jacob@appelbaum.net
Alec Muffett Alec Muffett
Facebook Facebook
Email: alecm@fb.com Email: alecm@fb.com
 End of changes. 32 change blocks. 
67 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/