idnits 2.17.1 draft-appelbaum-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 (April 14, 2015) is 3299 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) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop J. Appelbaum 3 Internet-Draft Tor Project Inc. 4 Intended status: Standards Track A. Muffett 5 Expires: October 16, 2015 Facebook 6 April 14, 2015 8 The .onion Special-Use Domain Name 9 draft-appelbaum-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 October 16, 2015. 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 . . . . . . . . . . . . . . . . . 2 51 2. The ".onion" Special-Use TLD . . . . . . . . . . . . . . . . 3 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 56 5.2. Informative References . . . . . . . . . . . . . . . . . 5 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" Top-Level Domain. Such addresses can be 64 used as other domain names would be (e.g., in URLs [RFC3986]), but 65 instead of using the DNS infrastructure, .onion names functionally 66 correspond to the identity of a given service, thereby combining 67 location and authentication. 69 In this way, .onion names are "special" in the sense defined by 70 [RFC6761] Section 3; they require hardware and software 71 implementations to change their handling, in order to achieve the 72 desired properties of the name (see Section 4). These differences 73 are listed in Section 2. 75 Like other TLDs, .onion addresses can have an arbitrary number of 76 subdomain components. This information is not meaningful to the Tor 77 protocol, but can be used in application protocols like HTTP 78 [RFC7230]. 80 See [tor-address] and [tor-rendezvous] for the details of the 81 creation and use of .onion names. 83 Note that this draft was preceded by 84 [I-D.grothoff-iesg-special-use-p2p-names], which registered .onion 85 alongside other, similar TLDs. Because .onion is in wide use, it has 86 become urgent to expedite its registration. This does not indicate 87 that the other registrations should be abandoned. 89 1.1. Notational Conventions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. The ".onion" Special-Use TLD 97 These properties have the following effects upon parties using or 98 processing .onion names (as per [RFC6761]): 100 1. Users: human users are expected to recognize .onion names as 101 having different security properties, and also being only 102 available through software that is aware of onion addresses. 104 2. Application Software: Applications that implement the Tor 105 protocol MUST recognize .onion names as special by either 106 accessing them directly, or using a proxy (e.g., SOCKS [RFC1928]) 107 to do so. Applications that do not implement the Tor protocol 108 SHOULD generate an error upon the use of .onion, and SHOULD NOT 109 perform a DNS lookup. 111 3. Name Resolution APIs and Libraries: Resolvers that implement the 112 Tor protocol MUST either respond to requests for .onion names by 113 resolving them (see [tor-rendezvous]) or by responding with 114 NXDOMAIN. Other resolvers SHOULD respond with NXDOMAIN. 116 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look 117 up records for .onion names. They SHOULD generate NXDOMAIN for 118 all such queries. 120 5. Authoritative DNS Servers: Authoritative servers SHOULD respond 121 to queries for .onion with NXDOMAIN. 123 6. DNS Server Operators: Operators SHOULD NOT configure an 124 authoritative DNS server to answer queries for .onion. If they 125 do so, client software is likely to ignore any results (see 126 above). 128 7. DNS Registries/Registrars: Registrars MUST NOT register .onion 129 names; all such requests MUST be denied. 131 3. IANA Considerations 133 This document registers the "onion" TLD in the registry of Special- 134 Use Domain Names [RFC6761]. See Section 2 for the registration 135 template. 137 4. Security Considerations 139 .onion names are often used provide access to end to end encrypted, 140 secure, anonymized services; that is, the identity and location of 141 the server is obscured from the client. The location of the client 142 is obscured from the server. The identity of the client may or may 143 not be disclosed through an optional cryptographic authentication 144 process. 146 These properties can be compromised if, for example: 148 o The server "leaks" its identity in another way (e.g., in an 149 application-level message), or 151 o The access protocol is implemented or deployed incorrectly, or 153 o The access protocol itself is found to have a flaw. 155 .onion names are self-authenticating, in that they are derived from 156 the cryptographic keys used by the server in a client verifiable 157 manner during connection establishment. As a result, the 158 cryptographic label component of a .onion name is not intended to be 159 human-meaningful. 161 The Tor network is designed to not be subject to any central 162 controlling authorities with regards to routing and service 163 publication, so .onion names cannot be registered, assigned, 164 transferred or revoked. "Ownership" of a .onion name is derived 165 solely from control of a public/private key pair which corresponds to 166 the algorithmic derivation of the name. 168 Users must take special precautions to ensure that the .onion name 169 they are communicating with is correct, as attackers may be able to 170 find keys which produce service names that are visually or apparently 171 semantically similar to the desired service. 173 Also, users need to understand the difference between a .onion name 174 used and accessed directly via Tor-capable software, versus .onion 175 subdomains of other TLDs and providers (e.g., the difference between 176 example.onion and example.onion.tld). 178 The cryptographic label for a .onion name is constructed by applying 179 a function to the public key of the server, the output of which is 180 rendered as a string and concatenated with the string ".onion". 181 Dependent upon the specifics of the function used, an attacker may be 182 able to find a key that produces a collision with the same .onion 183 name with substantially less work than a cryptographic attack on the 184 full strength key. If this is possible the attacker may be able to 185 impersonate the service on the network. 187 If client software attempts to resolve a .onion name, it can leak the 188 identity of the service that the user is attempting to access to DNS 189 resolvers, authoritative DNS servers, and observers on the 190 intervening network. This can be mitigated by following the 191 recommendations in Section 2. 193 5. References 195 5.1. Normative References 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997. 200 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 201 RFC 6761, February 2013. 203 5.2. Informative References 205 [Dingledine2004] 206 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 207 second-generation onion router", 2004, . 210 [I-D.grothoff-iesg-special-use-p2p-names] 211 Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and 212 L. Ryge, "Special-Use Domain Names of Peer-to-Peer 213 Systems", draft-grothoff-iesg-special-use-p2p-names-04 214 (work in progress), January 2015. 216 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 217 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 218 1996. 220 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 221 Resource Identifier (URI): Generic Syntax", STD 66, RFC 222 3986, January 2005. 224 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 225 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 226 2014. 228 [tor-address] 229 Mathewson, N. and R. Dingledine, "Special Hostnames in 230 Tor", September 2001, 231 . 234 [tor-rendezvous] 235 Mathewson, N. and R. Dingledine, "Tor Rendezvous 236 Specification", April 2014, 237 . 240 Appendix A. Acknowledgements 242 Thanks to Roger Dingledine, Linus Nordberg and Seth David Schoen for 243 their input and review. 245 This specification builds upon previous work by Christian Grothoff, 246 Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum and Leif Ryge to 247 register the .onion TLD in conjunction with other, similar TLDs. 249 Authors' Addresses 251 Jacob Appelbaum 252 Tor Project Inc. 254 Email: jacob@appelbaum.net 256 Alec Muffett 257 Facebook 259 Email: alecm@fb.com