idnits 2.17.1 draft-ietf-dnsop-onion-tld-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2015) is 3145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Dingledine2004' -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop J. Appelbaum 3 Internet-Draft The Tor Project, Inc 4 Intended status: Standards Track A. Muffett 5 Expires: March 12, 2016 Facebook 6 September 9, 2015 8 The .onion Special-Use Domain Name 9 draft-ietf-dnsop-onion-tld-01 11 Abstract 13 This document registers the ".onion" Special-Use Domain Name. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 12, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 51 2. The ".onion" Special-Use Domain Name . . . . . . . . . . . . 3 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 56 5.2. Informative References . . . . . . . . . . . . . . . . . 6 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 60 1. Introduction 62 The Tor network [Dingledine2004] has the ability to host network 63 services using the ".onion" Special-Use Top-Level Domain. Such names 64 can be used as other domain names would be (e.g., in URLs [RFC3986]), 65 but instead of using the DNS infrastructure, .onion names 66 functionally correspond to the identity of a given service, thereby 67 combining location and authentication. 69 .onion names are used to provide access to end to end encrypted, 70 secure, anonymized services; that is, the identity and location of 71 the server is obscured from the client. The location of the client 72 is obscured from the server. The identity of the client may or may 73 not be disclosed through an optional cryptographic authentication 74 process. 76 .onion names are self-authenticating, in that they are derived from 77 the cryptographic keys used by the server in a client-verifiable 78 manner during connection establishment. As a result, the 79 cryptographic label component of a .onion name is not intended to be 80 human-meaningful. 82 The Tor network is designed to not be subject to any central 83 controlling authorities with regards to routing and service 84 publication, so .onion names cannot be registered, assigned, 85 transferred or revoked. "Ownership" of a .onion name is derived 86 solely from control of a public/private key pair which corresponds to 87 the algorithmic derivation of the name. 89 In this way, .onion names are "special" in the sense defined by 90 [RFC6761] Section 3; they require hardware and software 91 implementations to change their handling in order to achieve the 92 desired properties of the name (see Section 4). These differences 93 are listed in Section 2. 95 Like Top-Level Domain Names, .onion names can have an arbitrary 96 number of subdomain components. This information is not meaningful 97 to the Tor protocol, but can be used in application protocols like 98 HTTP [RFC7230]. 100 Note that .onion names are required conform to DNS name syntax (as 101 defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]), as 102 they will still be exposed to DNS implementations. 104 See [tor-address] and [tor-rendezvous] for the details of the 105 creation and use of .onion names. 107 1.1. Notational Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. The ".onion" Special-Use Domain Name 115 These properties have the following effects upon parties using or 116 processing .onion names (as per [RFC6761]): 118 1. Users: Human users are expected to recognize .onion names as 119 having different security properties (see Section 1), and also as 120 being only available through software that is aware of onion 121 names. 123 2. Application Software: Applications (including proxies) that 124 implement the Tor protocol MUST recognize .onion names as special 125 by either accessing them directly, or using a proxy (e.g., SOCKS 126 [RFC1928]) to do so. Applications that do not implement the Tor 127 protocol SHOULD generate an error upon the use of .onion, and 128 SHOULD NOT perform a DNS lookup. 130 3. Name Resolution APIs and Libraries: Resolvers MUST either respond 131 to requests for .onion names by resolving them according to 132 [tor-rendezvous] or by responding with NXDOMAIN. 134 4. Caching DNS Servers: Caching servers, where not explicitly 135 adapted to interoperate with Tor, SHOULD NOT attempt to look up 136 records for .onion names. They MUST generate NXDOMAIN for all 137 such queries. 139 5. Authoritative DNS Servers: Authoritative servers MUST respond to 140 queries for .onion with NXDOMAIN. 142 6. DNS Server Operators: Operators MUST NOT configure an 143 authoritative DNS server to answer queries for .onion. If they 144 do so, client software is likely to ignore any results (see 145 above). 147 7. DNS Registries/Registrars: Registrars MUST NOT register .onion 148 names; all such requests MUST be denied. 150 Note that the restriction upon the registration of .onion names does 151 not prohibit IANA from inserting a record into the root zone database 152 to reserve the name. 154 Likewise, it does not prevent non-DNS service providers (such as 155 trust providers) from supporting .onion names in their applications. 157 3. IANA Considerations 159 This document registers "onion" in the registry of Special-Use Domain 160 Names [RFC6761]. See Section 2 for the registration template. 162 4. Security Considerations 164 The security properties of .onion names can be compromised if, for 165 example: 167 o The server "leaks" its identity in another way (e.g., in an 168 application-level message), or 170 o The access protocol is implemented or deployed incorrectly, or 172 o The access protocol itself is found to have a flaw. 174 Users must take special precautions to ensure that the .onion name 175 they are communicating with is the intended one, as attackers may be 176 able to find keys which produce service names that are visually or 177 semantically similar to the desired service. This risk is magnified 178 because .onion names are typically not human-meaningful. It can be 179 mitigated by generating human meaningful .onion names (at 180 considerable computing expense), or through users using bookmarks and 181 other trusted stores when following links. 183 Also, users need to understand the difference between a .onion name 184 used and accessed directly via Tor-capable software, versus .onion 185 subdomains of other top-level domain names and providers (e.g., the 186 difference between example.onion and example.onion.tld). 188 The cryptographic label for a .onion name is constructed by applying 189 a function to the public key of the server, the output of which is 190 rendered as a string and concatenated with the string ".onion". 191 Dependent upon the specifics of the function used, an attacker may be 192 able to find a key that produces a collision with the same .onion 193 name with substantially less work than a cryptographic attack on the 194 full strength key. If this is possible the attacker may be able to 195 impersonate the service on the network. 197 A legacy client may inadvertently attempt to resolve a ".onion" name 198 through the DNS. This causes a disclosure that the client is 199 attempting to use Tor to reach a specific service. Malicious 200 resolvers could be engineered to capture and record such leaks, which 201 might have very adverse consequences for the well-being of the Tor 202 user. This issue is mitigated if the client's Tor software is 203 updated to not leak such queries, or if the client's DNS software is 204 updated to drop any request to the ".onion" TLD. 206 5. References 208 5.1. Normative References 210 [Dingledine2004] 211 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 212 second-generation onion router", 2004, 213 . 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 217 RFC2119, March 1997, 218 . 220 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 221 RFC 6761, DOI 10.17487/RFC6761, February 2013, 222 . 224 [tor-address] 225 Mathewson, N. and R. Dingledine, "Special Hostnames in 226 Tor", September 2001, . 229 [tor-rendezvous] 230 Mathewson, N. and R. Dingledine, "Tor Rendezvous 231 Specification", April 2014, . 234 5.2. Informative References 236 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 237 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 238 . 240 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 241 Application and Support", STD 3, RFC 1123, DOI 10.17487/ 242 RFC1123, October 1989, 243 . 245 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 246 L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 247 10.17487/RFC1928, March 1996, 248 . 250 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 251 Resource Identifier (URI): Generic Syntax", STD 66, RFC 252 3986, DOI 10.17487/RFC3986, January 2005, 253 . 255 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 256 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 257 7230, DOI 10.17487/RFC7230, June 2014, 258 . 260 Appendix A. Acknowledgements 262 Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for 263 their input and review. 265 This specification builds upon previous work by Christian Grothoff, 266 Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to 267 register .onion in conjunction with other, similar Special-Use Top- 268 Level Domain Names. 270 Authors' Addresses 272 Jacob Appelbaum 273 The Tor Project, Inc 275 Email: jacob@appelbaum.net 277 Alec Muffett 278 Facebook 280 Email: alecm@fb.com