idnits 2.17.1 draft-ietf-dnsop-onion-tld-00.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 (June 19, 2015) is 3206 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 The Tor Project, Inc 4 Intended status: Standards Track A. Muffett 5 Expires: December 21, 2015 Facebook 6 June 19, 2015 8 The .onion Special-Use Domain Name 9 draft-ietf-dnsop-onion-tld-00 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 December 21, 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 Domain Name . . . . . . . . . . . . 2 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 56 5.2. Informative References . . . . . . . . . . . . . . . . . 5 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 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 64 addresses can be used as other domain names would be (e.g., in URLs 65 [RFC3986]), 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 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 Top-Level Domain Names, .onion addresses can have an arbitrary 76 number of subdomain components. This information is not meaningful 77 to the Tor protocol, but can be used in application protocols like 78 HTTP [RFC7230]. 80 See [tor-address] and [tor-rendezvous] for the details of the 81 creation and use of .onion names. 83 1.1. Notational Conventions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. The ".onion" Special-Use Domain Name 91 These properties have the following effects upon parties using or 92 processing .onion names (as per [RFC6761]): 94 1. Users: human users are expected to recognize .onion names as 95 having different security properties, and also being only 96 available through software that is aware of onion addresses. 98 2. Application Software: Applications (including proxies) that 99 implement the Tor protocol MUST recognize .onion names as special 100 by either accessing them directly, or using a proxy (e.g., SOCKS 101 [RFC1928]) to do so. Applications that do not implement the Tor 102 protocol SHOULD generate an error upon the use of .onion, and 103 SHOULD NOT perform a DNS lookup. 105 3. Name Resolution APIs and Libraries: Resolvers MUST either either 106 respond to requests for .onion names by resolving them according 107 to [tor-rendezvous] or by responding with NXDOMAIN. 109 4. Caching DNS Servers: Caching servers SHOULD NOT attempt to look 110 up records for .onion names. They MUST generate NXDOMAIN for all 111 such queries. 113 5. Authoritative DNS Servers: Authoritative servers MUST respond to 114 queries for .onion with NXDOMAIN. 116 6. DNS Server Operators: Operators MUST NOT configure an 117 authoritative DNS server to answer queries for .onion. If they 118 do so, client software is likely to ignore any results (see 119 above). 121 7. DNS Registries/Registrars: Registrars MUST NOT register .onion 122 names; all such requests MUST be denied. 124 3. IANA Considerations 126 This document registers "onion" in the registry of Special-Use Domain 127 Names [RFC6761]. See Section 2 for the registration template. 129 4. Security Considerations 131 .onion names are often used to provide access to end to end 132 encrypted, secure, anonymized services; that is, the identity and 133 location of the server is obscured from the client. The location of 134 the client is obscured from the server. The identity of the client 135 may or may not be disclosed through an optional cryptographic 136 authentication process. 138 These properties can be compromised if, for example: 140 o The server "leaks" its identity in another way (e.g., in an 141 application-level message), or 143 o The access protocol is implemented or deployed incorrectly, or 145 o The access protocol itself is found to have a flaw. 147 .onion names are self-authenticating, in that they are derived from 148 the cryptographic keys used by the server in a client verifiable 149 manner during connection establishment. As a result, the 150 cryptographic label component of a .onion name is not intended to be 151 human-meaningful. 153 The Tor network is designed to not be subject to any central 154 controlling authorities with regards to routing and service 155 publication, so .onion names cannot be registered, assigned, 156 transferred or revoked. "Ownership" of a .onion name is derived 157 solely from control of a public/private key pair which corresponds to 158 the algorithmic derivation of the name. 160 Users must take special precautions to ensure that the .onion name 161 they are communicating with is correct, as attackers may be able to 162 find keys which produce service names that are visually or 163 semantically similar to the desired service. 165 Also, users need to understand the difference between a .onion name 166 used and accessed directly via Tor-capable software, versus .onion 167 subdomains of other top-level domain names and providers (e.g., the 168 difference between example.onion and example.onion.tld). 170 The cryptographic label for a .onion name is constructed by applying 171 a function to the public key of the server, the output of which is 172 rendered as a string and concatenated with the string ".onion". 173 Dependent upon the specifics of the function used, an attacker may be 174 able to find a key that produces a collision with the same .onion 175 name with substantially less work than a cryptographic attack on the 176 full strength key. If this is possible the attacker may be able to 177 impersonate the service on the network. 179 If client software attempts to resolve a .onion name, it can leak the 180 identity of the service that the user is attempting to access to DNS 181 resolvers, authoritative DNS servers, and observers on the 182 intervening network. This can be mitigated by following the 183 recommendations in Section 2. 185 5. References 186 5.1. Normative References 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 192 RFC 6761, February 2013. 194 5.2. Informative References 196 [Dingledine2004] 197 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 198 second-generation onion router", 2004, . 201 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 202 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 203 1996. 205 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 206 Resource Identifier (URI): Generic Syntax", STD 66, RFC 207 3986, January 2005. 209 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 210 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 211 2014. 213 [tor-address] 214 Mathewson, N. and R. Dingledine, "Special Hostnames in 215 Tor", September 2001, 216 . 219 [tor-rendezvous] 220 Mathewson, N. and R. Dingledine, "Tor Rendezvous 221 Specification", April 2014, 222 . 225 Appendix A. Acknowledgements 227 Thanks to Roger Dingledine, Linus Nordberg, and Seth David Schoen for 228 their input and review. 230 This specification builds upon previous work by Christian Grothoff, 231 Matthias Wachs, Hellekin O. Wolf, Jacob Appelbaum, and Leif Ryge to 232 register .onion in conjunction with other, similar Special-Use Top- 233 Level Domain Names. 235 Authors' Addresses 237 Jacob Appelbaum 238 The Tor Project, Inc 240 Email: jacob@appelbaum.net 242 Alec Muffett 243 Facebook 245 Email: alecm@fb.com