1 Internet Engineering Task Force (IETF) J. Appelbaum
2 Request for Comments: 7686 The Tor Project, Inc.
3 Category: Standards Track A. Muffett
4 ISSN: 2070-1721 Facebook
5 October 2015
6
7
8 The ".onion" Special-Use Domain Name
9
10 Abstract
11
12 This document registers the ".onion" Special-Use Domain Name.
13
14 Status of This Memo
15
16 This is an Internet Standards Track document.
17
18 This document is a product of the Internet Engineering Task Force
19 (IETF). It represents the consensus of the IETF community. It has
20 received public review and has been approved for publication by the
21 Internet Engineering Steering Group (IESG). Further information on
22 Internet Standards is available in Section 2 of RFC 5741.
23
24 Information about the current status of this document, any errata,
25 and how to provide feedback on it may be obtained at
26 http://www.rfc-editor.org/info/rfc7686.
27
28 Copyright Notice
29
30 Copyright (c) 2015 IETF Trust and the persons identified as the
31 document authors. All rights reserved.
32
33 This document is subject to BCP 78 and the IETF Trust's Legal
34 Provisions Relating to IETF Documents
35 (http://trustee.ietf.org/license-info) in effect on the date of
36 publication of this document. Please review these documents
37 carefully, as they describe your rights and restrictions with respect
38 to this document. Code Components extracted from this document must
39 include Simplified BSD License text as described in Section 4.e of
40 the Trust Legal Provisions and are provided without warranty as
41 described in the Simplified BSD License.
42
43
44
45
46
47
48
49
50
51
52 Appelbaum & Muffett Standards Track [Page 1]
53 RFC 7686 .onion October 2015
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
60 2. The ".onion" Special-Use Domain Name . . . . . . . . . . . . 3
61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
64 5.1. Normative References . . . . . . . . . . . . . . . . . . 5
65 5.2. Informative References . . . . . . . . . . . . . . . . . 6
66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
68
69 1. Introduction
70
71 The Tor network [Dingledine2004] has the ability to host network
72 services using the ".onion" Special-Use Top-Level Domain Name. Such
73 names can be used as other domain names would be (e.g., in URLs
74 [RFC3986]), but instead of using the DNS infrastructure, .onion names
75 functionally correspond to the identity of a given service, thereby
76 combining location and authentication.
77
78 .onion names are used to provide access to end to end encrypted,
79 secure, anonymized services; that is, the identity and location of
80 the server is obscured from the client. The location of the client
81 is obscured from the server. The identity of the client may or may
82 not be disclosed through an optional cryptographic authentication
83 process.
84
85 .onion names are self-authenticating, in that they are derived from
86 the cryptographic keys used by the server in a client-verifiable
87 manner during connection establishment. As a result, the
88 cryptographic label component of a .onion name is not intended to be
89 human-meaningful.
90
91 The Tor network is designed to not be subject to any central
92 controlling authorities with regards to routing and service
93 publication, so .onion names cannot be registered, assigned,
94 transferred or revoked. "Ownership" of a .onion name is derived
95 solely from control of a public/private key pair that corresponds to
96 the algorithmic derivation of the name.
97
98 In this way, .onion names are "special" in the sense defined by
99 Section 3 of [RFC6761]; they require hardware and software
100 implementations to change their handling in order to achieve the
101 desired properties of the name (see Section 4). These differences
102 are listed in Section 2.
103
104
105
106
107 Appelbaum & Muffett Standards Track [Page 2]
108 RFC 7686 .onion October 2015
109
110
111 Like Top-Level Domain Names, .onion names can have an arbitrary
112 number of subdomain components. This information is not meaningful
113 to the Tor protocol, but can be used in application protocols like
114 HTTP [RFC7230].
115
116 Note that .onion names are required to conform with DNS name syntax
117 (as defined in Section 3.5 of [RFC1034] and Section 2.1 of
118 [RFC1123]), as they will still be exposed to DNS implementations.
119
120 See [tor-address] and [tor-rendezvous] for the details of the
121 creation and use of .onion names.
122
123 1.1. Notational Conventions
124
125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
127 document are to be interpreted as described in [RFC2119].
128
129 2. The ".onion" Special-Use Domain Name
130
131 These properties have the following effects upon parties using or
132 processing .onion names (as per [RFC6761]):
133
134 1. Users: Human users are expected to recognize .onion names as
135 having different security properties (see Section 1) and also as
136 being only available through software that is aware of .onion
137 names.
138
139 2. Application Software: Applications (including proxies) that
140 implement the Tor protocol MUST recognize .onion names as special
141 by either accessing them directly or using a proxy (e.g., SOCKS
142 [RFC1928]) to do so. Applications that do not implement the Tor
143 protocol SHOULD generate an error upon the use of .onion and
144 SHOULD NOT perform a DNS lookup.
145
146 3. Name Resolution APIs and Libraries: Resolvers MUST either respond
147 to requests for .onion names by resolving them according to
148 [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].
149
150 4. Caching DNS Servers: Caching servers, where not explicitly
151 adapted to interoperate with Tor, SHOULD NOT attempt to look up
152 records for .onion names. They MUST generate NXDOMAIN for all
153 such queries.
154
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
155 5. Authoritative DNS Servers: Authoritative servers MUST respond to
156 queries for .onion with NXDOMAIN.
157
158
159
160
161
162 Appelbaum & Muffett Standards Track [Page 3]
163 RFC 7686 .onion October 2015
164
165
166 6. DNS Server Operators: Operators MUST NOT configure an
167 authoritative DNS server to answer queries for .onion. If they
168 do so, client software is likely to ignore any results (see
169 above).
170
171 7. DNS Registries/Registrars: Registrars MUST NOT register .onion
172 names; all such requests MUST be denied.
173
174 Note that the restriction upon the registration of .onion names does
175 not prohibit IANA from inserting a record into the root zone database
176 to reserve the name.
177
178 Likewise, it does not prevent non-DNS service providers (such as
179 trust providers) from supporting .onion names in their applications.
180
181 3. IANA Considerations
182
183 This document registers ".onion" in the registry of Special-Use
184 Domain Names [RFC6761]. See Section 2 for the registration template.
185
186 4. Security Considerations
187
188 The security properties of .onion names can be compromised if, for
189 example:
190
191 o The server "leaks" its identity in another way (e.g., in an
192 application-level message), or
193
194 o The access protocol is implemented or deployed incorrectly, or
195
196 o The access protocol itself is found to have a flaw.
197
198 Users must take special precautions to ensure that the .onion name
199 they are communicating with is the intended one, as attackers may be
200 able to find keys that produce service names that are visually or
201 semantically similar to the desired service. This risk is magnified
202 because .onion names are typically not human-meaningful. It can be
203 mitigated by generating human-meaningful .onion names (at
204 considerable computing expense) or through users using bookmarks and
205 other trusted stores when following links.
206
207 Also, users need to understand the difference between a .onion name
208 used and accessed directly via Tor-capable software, versus .onion
209 subdomains of other top-level domain names and providers (e.g., the
210 difference between example.onion and example.onion.tld).
211
212
213
214
215
216
217 Appelbaum & Muffett Standards Track [Page 4]
218 RFC 7686 .onion October 2015
219
220
221 The cryptographic label for a .onion name is constructed by applying
222 a function to the public key of the server, the output of which is
223 rendered as a string and concatenated with the string .onion.
224 Dependent upon the specifics of the function used, an attacker may be
225 able to find a key that produces a collision with the same .onion
226 name with substantially less work than a cryptographic attack on the
227 full strength key. If this is possible the attacker may be able to
228 impersonate the service on the network.
229
230 A legacy client may inadvertently attempt to resolve a .onion name
231 through the DNS. This causes a disclosure that the client is
232 attempting to use Tor to reach a specific service. Malicious
233 resolvers could be engineered to capture and record such leaks, which
234 might have very adverse consequences for the well-being of the user.
235 This issue is mitigated if the client's software is updated to not
236 leak such queries or updated to support [tor-rendezvous], or if the
237 client's DNS software is updated to drop any request to the .onion
238 special-use domain name.
239
240 5. References
241
242 5.1. Normative References
243
244 [Dingledine2004]
245 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
246 Second-Generation Onion Router", August 2004,
247 <https://svn.torproject.org/svn/projects/design-paper/
248 tor-design.html>.
249
250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
251 Requirement Levels", BCP 14, RFC 2119,
252 DOI 10.17487/RFC2119, March 1997,
253 <http://www.rfc-editor.org/info/rfc2119>.
254
255 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
256 RFC 6761, DOI 10.17487/RFC6761, February 2013,
257 <http://www.rfc-editor.org/info/rfc6761>.
258
259 [tor-address]
260 Mathewson, N. and The Tor Project, "Special Hostnames in
261 Tor", 2006, <https://spec.torproject.org/address-spec>.
262
263 [tor-rendezvous]
264 The Tor Project, "Tor Rendezvous Specification", April
265 2014, <https://spec.torproject.org/rend-spec>.
266
267
268
269
270
271
272 Appelbaum & Muffett Standards Track [Page 5]
273 RFC 7686 .onion October 2015
274
275
276 5.2. Informative References
277
278 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
279 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
280 <http://www.rfc-editor.org/info/rfc1034>.
281
282 [RFC1035] Mockapetris, P., "Domain names - implementation and
283 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
284 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
285
286 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
287 Application and Support", STD 3, RFC 1123,
288 DOI 10.17487/RFC1123, October 1989,
289 <http://www.rfc-editor.org/info/rfc1123>.
290
291 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
292 L. Jones, "SOCKS Protocol Version 5", RFC 1928,
293 DOI 10.17487/RFC1928, March 1996,
294 <http://www.rfc-editor.org/info/rfc1928>.
295
296 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
297 Resource Identifier (URI): Generic Syntax", STD 66,
298 RFC 3986, DOI 10.17487/RFC3986, January 2005,
299 <http://www.rfc-editor.org/info/rfc3986>.
300
301 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
302 Protocol (HTTP/1.1): Message Syntax and Routing",
303 RFC 7230, DOI 10.17487/RFC7230, June 2014,
304 <http://www.rfc-editor.org/info/rfc7230>.
305
306 Acknowledgements
307
308 Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for
309 their input and review.
310
311 This specification builds upon previous work by Christian Grothoff,
312 Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to
313 register .onion in conjunction with other, similar Special-Use Top-
314 Level Domain Names.
315
316
317
318
319
320
321
322
323
324
325
326
327 Appelbaum & Muffett Standards Track [Page 6]
328 RFC 7686 .onion October 2015
329
330
331 Authors' Addresses
332
333 Jacob Appelbaum
334 The Tor Project, Inc. & Technische Universiteit Eindhoven
335
336 Email: jacob@appelbaum.net
337
338
339 Alec Muffett
340 Facebook
341
342 Email: alecm@fb.com
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Appelbaum & Muffett Standards Track [Page 7]
383
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
6. 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).
5. Authoritative DNS Servers: Authoritative servers MUST respond non-authoritatively to
queries for names in .onion with NXDOMAIN.
6. DNS Server Operators: Operators MUST NOT configure an
authoritative DNS server to answer queries forauthoritatively to queries for names in .onion. If they
do so, client software is likely to ignore any results (see
above).