1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
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
383
384
385
386
387
388
389
|
<pre>Internet Engineering Task Force (IETF) J. Appelbaum
Request for Comments: 7686 The Tor Project, Inc.
Category: Standards Track A. Muffett
ISSN: 2070-1721 Facebook
October 2015
<span class="h1">The ".onion" Special-Use Domain Name</span>
Abstract
This document registers the ".onion" Special-Use Domain Name.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7686">http://www.rfc-editor.org/info/rfc7686</a>.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Appelbaum & Muffett Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Notational Conventions . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. The ".onion" Special-Use Domain Name . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-5">5</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.1">5.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5.2">5.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Tor network [<a href="#ref-Dingledine2004">Dingledine2004</a>] has the ability to host network
services using the ".onion" Special-Use Top-Level Domain Name. Such
names can be used as other domain names would be (e.g., in URLs
[<a href="./rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]), 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 that corresponds to
the algorithmic derivation of the name.
In this way, .onion names are "special" in the sense defined by
<a href="./rfc6761#section-3">Section 3 of [RFC6761]</a>; they require hardware and software
implementations to change their handling in order to achieve the
desired properties of the name (see <a href="#section-4">Section 4</a>). These differences
are listed in <a href="#section-2">Section 2</a>.
<span class="grey">Appelbaum & Muffett Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
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 [<a href="./rfc7230" title=""Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"">RFC7230</a>].
Note that .onion names are required to conform with DNS name syntax
(as defined in <a href="./rfc1034#section-3.5">Section 3.5 of [RFC1034]</a> and <a href="./rfc1123#section-2.1">Section 2.1 of
[RFC1123]</a>), as they will still be exposed to DNS implementations.
See [<a href="#ref-tor-address">tor-address</a>] and [<a href="#ref-tor-rendezvous">tor-rendezvous</a>] for the details of the
creation and use of .onion names.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Notational Conventions</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The ".onion" Special-Use Domain Name</span>
These properties have the following effects upon parties using or
processing .onion names (as per [<a href="./rfc6761" title=""Special-Use Domain Names"">RFC6761</a>]):
1. Users: Human users are expected to recognize .onion names as
having different security properties (see <a href="#section-1">Section 1</a>) and also as
being only available through software that is aware of .onion
names.
2. 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
[<a href="./rfc1928" title=""SOCKS Protocol Version 5"">RFC1928</a>]) 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 MUST either respond
to requests for .onion names by resolving them according to
[<a href="#ref-tor-rendezvous">tor-rendezvous</a>] or by responding with NXDOMAIN [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>].
4. 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.
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
<span class="grey">Appelbaum & Muffett Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
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).
7. 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.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IANA Considerations</span>
This document registers ".onion" in the registry of Special-Use
Domain Names [<a href="./rfc6761" title=""Special-Use Domain Names"">RFC6761</a>]. See <a href="#section-2">Section 2</a> for the registration template.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
The security properties of .onion names 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.
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 that 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).
<span class="grey">Appelbaum & Muffett Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
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 user.
This issue is mitigated if the client's software is updated to not
leak such queries or updated to support [<a href="#ref-tor-rendezvous">tor-rendezvous</a>], or if the
client's DNS software is updated to drop any request to the .onion
special-use domain name.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-Dingledine2004">Dingledine2004</a>]
Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", August 2004,
<<a href="https://svn.torproject.org/svn/projects/design-paper/tor-design.html">https://svn.torproject.org/svn/projects/design-paper/</a>
<a href="https://svn.torproject.org/svn/projects/design-paper/tor-design.html">tor-design.html</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC6761">RFC6761</a>] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
<a href="./rfc6761">RFC 6761</a>, DOI 10.17487/RFC6761, February 2013,
<<a href="http://www.rfc-editor.org/info/rfc6761">http://www.rfc-editor.org/info/rfc6761</a>>.
[<a id="ref-tor-address">tor-address</a>]
Mathewson, N. and The Tor Project, "Special Hostnames in
Tor", 2006, <<a href="https://spec.torproject.org/address-spec">https://spec.torproject.org/address-spec</a>>.
[<a id="ref-tor-rendezvous">tor-rendezvous</a>]
The Tor Project, "Tor Rendezvous Specification", April
2014, <<a href="https://spec.torproject.org/rend-spec">https://spec.torproject.org/rend-spec</a>>.
<span class="grey">Appelbaum & Muffett Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-RFC1034">RFC1034</a>] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, <a href="./rfc1034">RFC 1034</a>, DOI 10.17487/RFC1034, November 1987,
<<a href="http://www.rfc-editor.org/info/rfc1034">http://www.rfc-editor.org/info/rfc1034</a>>.
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, DOI 10.17487/RFC1035,
November 1987, <<a href="http://www.rfc-editor.org/info/rfc1035">http://www.rfc-editor.org/info/rfc1035</a>>.
[<a id="ref-RFC1123">RFC1123</a>] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, <a href="./rfc1123">RFC 1123</a>,
DOI 10.17487/RFC1123, October 1989,
<<a href="http://www.rfc-editor.org/info/rfc1123">http://www.rfc-editor.org/info/rfc1123</a>>.
[<a id="ref-RFC1928">RFC1928</a>] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", <a href="./rfc1928">RFC 1928</a>,
DOI 10.17487/RFC1928, March 1996,
<<a href="http://www.rfc-editor.org/info/rfc1928">http://www.rfc-editor.org/info/rfc1928</a>>.
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
<a href="./rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
<<a href="http://www.rfc-editor.org/info/rfc3986">http://www.rfc-editor.org/info/rfc3986</a>>.
[<a id="ref-RFC7230">RFC7230</a>] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
<a href="./rfc7230">RFC 7230</a>, DOI 10.17487/RFC7230, June 2014,
<<a href="http://www.rfc-editor.org/info/rfc7230">http://www.rfc-editor.org/info/rfc7230</a>>.
Acknowledgements
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.
<span class="grey">Appelbaum & Muffett Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7686">RFC 7686</a> .onion October 2015</span>
Authors' Addresses
Jacob Appelbaum
The Tor Project, Inc. & Technische Universiteit Eindhoven
Email: jacob@appelbaum.net
Alec Muffett
Facebook
Email: alecm@fb.com
Appelbaum & Muffett Standards Track [Page 7]
</pre>
|
