idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-names-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 (December 05, 2013) is 3793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 426, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Grothoff 3 Internet-Draft M. Wachs 4 Intended status: Informational TU Munich 5 Expires: June 8, 2014 H. Wolf, Ed. 6 GNU consensus 7 J. Appelbaum 8 Tor Project Inc. 9 December 05, 2013 11 Special-Use Domain Names of Peer-to-Peer Systems 12 draft-grothoff-iesg-special-use-p2p-names-01 14 Abstract 16 This document describes common Special-Use Domain Names pseudo Top- 17 Level Domain names designed to help harden name resolution security, 18 provide censorship resistance, and protect the users' privacy on the 19 Internet. 21 This is an IESG Approval document requesting the reservation of six 22 Top-Level Domains for special use, in conformance with the 23 registration procedure defined in RFC 6761, section 4. 25 The six domains relate to peer-to-peer systems that, given their 26 decentralized design, do not require a central authority to register 27 names. They are: ".gnu", ".zkey", ".onion", ".exit", ".i2p", and 28 ".bit". 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 8, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology and Conventions Used in This Document . . . . . . 3 65 3. Description of Special-Use Domains in P2P Networks . . . . . 4 66 3.1. The ".gnu" Relative pTLD . . . . . . . . . . . . . . . . 4 67 3.2. The ".zkey" Compressed Public Key pTLD . . . . . . . . . 4 68 3.3. Geographically Anonymous pTLDs . . . . . . . . . . . . . 4 69 3.3.1. The ".onion" Hidden Service pTLD . . . . . . . . . . 4 70 3.3.2. The ".exit" Client Source Routing pTLD . . . . . . . 5 71 3.3.3. The ".noconnect" Client Interruption pTLD . . . . . . 6 72 3.4. The ".i2p" Addressbook pTLD . . . . . . . . . . . . . . . 6 73 3.5. The ".bit" Timeline System pTLD . . . . . . . . . . . . . 6 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 5.1. Domain Name Reservation Considerations . . . . . . . . . 7 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 7.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 Today, the Domain Name System (DNS) is a key service for the 86 Internet. DNS is primarily used to map human-memorable names to IP 87 addresses, which are used for routing but generally not meaningful 88 for humans. However, the hierarchical nature of DNS makes it 89 unsuitable for various Peer-to-Peer (P2P) Name Systems. As 90 compatibility with applications using domain names is desired, these 91 overlay networks often define exclusive alternative pseudo Top-Level 92 Domains (pTLDs) to avoid conflict between the P2P namespace and the 93 DNS hierarchy. 95 The purpose of this document is to inform the Internet community 96 about current practice of such pseudo-TLDs within peer-to-peer 97 systems, and to normalize their usage according to the rules of RFC 98 6761. Given their decentralized design, such P2P systems do not 99 require a central authority to register names nor do they belong to 100 the DNS resolution tree. 102 RFC 6761 defines a mechanism for reserving domain names for special 103 use. This document is an IESG Approval document requesting the 104 reservation of six pTLDs for special use: ".gnu", ".zkey", ".onion", 105 ".exit", ".i2p", and ".bit". 107 The GNU Name System (GNS) (".gnu", ".zkey"), the Tor network 108 (".onion", ".exit"), the Invisible Internet Project (".i2p"), and the 109 .Bit Project (".bit") use these pseudo-Top-Level Domains (pTLDs) to 110 realize fully-decentralized and censorship-resistant secure 111 alternatives for DNS or, in the case of the ".exit" pTLD, to control 112 overlay routing and to securely specify path selection choices 113 [TOR-PATH]. 115 To facilitate integration with legacy applications, the overlay's 116 namespaces can be accessed from applications to resolve these special 117 TLDs, for example via specialized SOCKS proxies [RFC1928], 118 specialized DNS servers, or transparent name resolution and ephemeral 119 address mapping. 121 2. Terminology and Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119. 127 The word "peer" is used in the meaning of a individual system on the 128 network. Thus, "local peer" means the localhost. 130 The acronym "pTLD" is used as a shortcut to mean a pseudo Top-Level 131 Domain, i.e., a name or label for a network not present in 132 operational DNS, and not registered with IANA for use within the 133 scope of operational DNS. Specifically, it refers to one of the 134 Special-Use Domain Names already in use on the Internet and described 135 in this document. 137 In this document, ".tld" (with quotes) means: any domain or hostname 138 within the scope of a given pTLD, while .tld (without quotes), or 139 dot-tld, both refer to an adjective form. For example, a collection 140 of ".gnu" peers, but an .onion URL. The pTLD itself is mentioned 141 with dot, and within double quotes, and usually followed by the word 142 pTLD. 144 The Tor-related names such as 'circuit', 'exit', 'node', 'relay', 145 'stream', and related Tor terms are described in [Dingledine2004] and 146 the Tor protocol specification [TOR-PROTOCOL]. 148 3. Description of Special-Use Domains in P2P Networks 150 3.1. The ".gnu" Relative pTLD 152 The ".gnu" pTLD is used to specify that a domain name should be 153 resolved using GNS instead of DNS. The GNS resolution process is 154 documented in [Schanzenbach2012]. As GNS users need to install a GNS 155 resolver on their individual system and as GNS resolution does not 156 depend on DNS, there are no considerations for DNS with respect to 157 the internals of the GNS resolution process itself. Note that ".gnu" 158 names SHOULD follow the naming conventions of DNS. 160 ".gnu" names are personal, relative, and transitive: each user of the 161 GNS controls their own zone that is authoritative for all ".gnu" 162 domains; zones can be delegated between authorities, so that any user 163 can share names, and chain labels to resolve names out of the 164 requesting user's zone of control, including across several zones. 166 For example, if Alice wants to access the Web service of Bob's friend 167 Dave, she might be able to lookup: "www.dave.bob.gnu", whereas Bob 168 will simply ask for "www.dave.gnu" to obtain the same result. 170 3.2. The ".zkey" Compressed Public Key pTLD 172 The ".zkey" pTLD is used to signify that resolution of the given name 173 MUST be performed using a record signed by an authority that is in 174 possession of a particular public key. Names in ".zkey" MUST end 175 with a domain which is the compressed point representation from 176 [EdDSA] on [Curve25519] of the public key of the authority, encoded 177 using base32hex [RFC4648]. A GNS resolver uses the key to locate a 178 record signed by the respective authority. 180 The ".zkey" pTLD provides a (reverse) mapping from globally unique 181 hashes to public key, therefore names in ".zkey" are non-memorable, 182 and are expected to be hidden from the user [Schanzenbach2012]. 184 3.3. Geographically Anonymous pTLDs 186 The Tor anonymization network makes use of several special pTLD 187 labels, three of which have seen widespread usage to date 188 [TOR-ADDRESS]. 190 3.3.1. The ".onion" Hidden Service pTLD 191 The widely deployed ".onion" pTLD designates an anonymous Tor Hidden 192 Service reachable via the Tor network [Dingledine2004]. These .onion 193 URLs are self-authenticating addresses for use with any TCP service. 194 Such addresses are typically resolved, reached and authenticated 195 through transparent proxying or through a local SOCKS proxy running 196 on TCP port 9050, TCP port 9150 or another user selected TCP port. 197 The purpose of the Tor Hidden Services system is to provide 198 geographic anonymity for the .onion host and for all clients visiting 199 the hidden service as well as other purposes such as NAT traversal, 200 strong authentication, anonymity and censorship resistance. 202 Addresses in ".onion" are opaque, non-mnemonic, alpha-semi-numeric 203 hashes corresponding to an 80-bit truncated SHA1 hash over a given 204 Tor hidden service's public key. This hash can be made up of any 205 letter of the alphabet and decimal digits beginning with 2 and ending 206 with 7, thus representing a number in base32 [RFC4648]. Tor 207 generates this "Onion key" automatically when the hidden service is 208 configured. Tor clients use it following the Tor Rendezvous 209 specifications [TOR-RENDEZVOUS]. 211 3.3.2. The ".exit" Client Source Routing pTLD 213 The dot-exit suffix is used as an in-band source routing control 214 channel, usually for selection of a specific Tor relay during path 215 creation as the last node in the Tor circuit. 217 It may be used to access a DNS host via specific Torservers, in the 218 form "hostname.nickname-or-fingerprint.exit", where the "hostname" is 219 a valid hostname, and the "nickname-or-fingerprint" is either the 220 nickname of a Tor relay in the Tor network consensus, or the hex- 221 encoded SHA1 digest of the given node's public key (fingerprint). 223 For example, "gnu.org.noisetor.exit" will route the client to 224 "gnu.org" via the Tor node nicknamed "noisetor". Using the 225 fingerprint instead of the nickname ensures that the path selection 226 uses a specific Tor exit node, and is harder to remember: e.g., 227 "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". 229 When Tor sees an address in this format, it uses the specified 230 "nickname-or-fingerprint" as the exit node. If no "hostname" 231 component is given, Tor defaults to the published IPv4 address of the 232 Tor exit node [TOR-EXTSOCKS]. 234 3.3.3. The ".noconnect" Client Interruption pTLD 236 The dot-noconnect suffix is used in Tor for testing purposes: when 237 Tor sees an address in this format, it immediately closes the 238 connection without attaching it to any circuits. It is useful for 239 controllers that want to test whether a given application is indeed 240 using the same instance of Tor that they're controlling. 242 This is a deprecated pTLD and thus we do not include the ".noconnect" 243 pTLD in the list of Special-Use Domain Names that should be reserved. 245 3.4. The ".i2p" Addressbook pTLD 247 The ".i2p" pTLD provides accessibility to anonymous services 248 ("eepsites") within the I2P network. I2P is a scalable, self- 249 organizing, resilient packet switched anonymous network layer, upon 250 which any number of different anonymity or security-conscious 251 applications can operate. 253 The local I2P proxy resolves such names either by looking up a local 254 table called the addressbook, or by decoding Base32-encoded [RFC4648] 255 public keys and establishing a tunnel to the respective authority, 256 similar to contacting .onion hidden services. 258 I2P uses 52 characters (256 bits) of the SHA-256 hash of the public 259 key to identify eepsites [I2P-NAMING]. These identifiers can be used 260 to address a peer as, e.g.: 261 "ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p". 263 Apart from the ".b32.i2p" domain that is reserved for SHA-256 hashes, 264 other hostnames within the ".i2p." pTLD are non-hierarchical and can 265 be assigned locally: example.i2p and other.example.i2p do not 266 necessarily belong to the same authority. 268 As the system is decentralized, example.i2p may also resolve 269 differently for different peers, depending on the state of their 270 respective addressbooks. 272 3.5. The ".bit" Timeline System pTLD 274 The ".bit" pTLD provides a name space where names are registered via 275 transactions in the Namecoin currency [Namecoin]. Like Bitcoins, 276 Namecoins are created using a proof-of-work calculation, which is 277 also used to establish a decentralized, multi-party consensus on the 278 valid transaction history, and thus the set of registered names and 279 their values [SquareZooko]. 281 The Namecoin used in a transaction to register a name in ".bit" is 282 lost. This is not a fundamental problem as more coins can be 283 generated via mining (proof-of-work calculations). The registration 284 cost is set to decrease over time, to prevent early adopters from 285 registering too many names. 287 The owner of a name can update the associated value by issuing an 288 update, which is a transaction that uses a special coin which is 289 generated as change during the registration operation. If a name is 290 not updated for a long time, the registration expires. 292 4. Security Considerations 294 Specific software performs the resolution of the six requested 295 Special-Use Domain Names presented in this document; this resolution 296 process happens outside of the scope of DNS. Leakage of requests to 297 such domains to the global operational DNS can cause interception of 298 traffic that might be misused to monitor, censor, or abuse the user's 299 trust, and lead to privacy issues with potentially dramatic 300 consequences for the user. 302 Operation of said TLDs into the global DNS scope could as well 303 produce conflicts [SAC45] due to later real use and the possible 304 acquisition of intellectual property rights in such names. 306 The reservation of several Top-Level Domain names for these purposes 307 will minimize such confusion and conflict, and safety risks for 308 users. 310 5. IANA Considerations 312 The P2P Name Systems domains listed below, and any domains falling 313 within those domains are Special-Use Domain Names [RFC6761]: 315 gnu. 317 zkey. 319 onion. 321 exit. 323 i2p. 325 bit. 327 5.1. Domain Name Reservation Considerations 328 The six domains listed above, and any names falling within those 329 domains (e.g., "example.gnu.", "j6im4v42ur6dpic3.onion.", etc.) are 330 special according to RFC 6761, section 5 [RFC6761], in the following 331 ways: 333 1. Users MAY use these names as they would other domain names, 334 entering them anywhere that they would otherwise enter a 335 conventional DNS domain name, or a dotted decimal IPv4 address, 336 or a literal IPv6 address. 338 Since there is no central authority responsible for assigning 339 dot-gnu and dot-i2p names, and that specific domain is local to 340 the local peer, users SHOULD be aware of that specificity. 342 Since there is no central authority responsible for assigning 343 dot-b32-dot-i2p, dot-onion, and dot-zkey names, and those names 344 match cryptographic keys, users SHOULD be aware that they don't 345 belong to regular DNS, but are still global in their scope. 347 In any case, resolution of the six proposed pTLDs is similar to 348 the normal DNS resolution, and thus SHOULD NOT affect normal 349 usage of most Internet applications. 351 2. Application Software MAY pass requests to any of the six proposed 352 pTLDs for normal DNS resolution if A/AAAA records are desired. 353 If available, the local DNS resolver MUST intercept such requests 354 within the respective operating system hooks and behave like DNS. 355 However, P2P-aware application MAY choose to talk directly to the 356 respective P2P resolver, and in the case of GNS and ".bit", use 357 this to access additional record types that are not defined in 358 DNS. 360 As mentioned in points 4. and 5. below, regular DNS resolution is 361 expected to respond with NXDOMAIN for five of the six proposed 362 pTLDs. Therefore, if it can differentiate between DNS and P2P 363 name resolution, application software MAY expect such a response, 364 and MAY choose to treat other responses from the DNS as errors. 366 3. For legacy applications and legacy name resolution APIs expecting 367 DNS resolution, no changes are required. 369 The ".onion" and ".i2p" pTLDs are typically accessed via HTTP or 370 SOCKS proxies and do not define additional record types. 372 However, Name Resolution APIs and Libraries MAY choose to support 373 additional record types over time for the GNS and ".bit" names. 375 They MAY choose to directly resolve those domains via appropriate 376 APIs or mechanisms such as GNS-specific resolution protocol, or 377 blockchain-based resolution for dot-bit names. 379 4. If any request to one of the considered pTLDs, with the exception 380 of ".bit" names, is sent to the global operational DNS, the only 381 valid answer from DNS is NXDOMAIN. Therefore, a caching DNS 382 server MUST respond with NXDOMAIN in that case, and MAY choose to 383 cache that response. 385 But given that ".bit" users have no special privacy requirements, 386 and those names are globally unique, caching DNS servers MAY 387 choose to treat them as regular DNS names, and cache the 388 responses obtained from the Namecoin block chain as if they were 389 resolved from the regular DNS tree. 391 5. Authoritative DNS Servers are not expected to treat these TLDs 392 specially. In practice, they MUST answer with NXDOMAIN, as none 393 of the considered pTLDs are normally available via global DNS 394 resolution, and not doing so MAY put users' privacy at risk, 395 e.g., as suggested in the next point. 397 6. DNS Server Operators MAY choose to resolve ".bit" names using the 398 Namecoin block chain, and if they do so SHOULD treat such domains 399 like they would regular DNS names. 401 DNS Server Operators SHOULD treat requests to the other five 402 considered pTLDs as typos, for correct installations MUST NOT 403 allow such P2P requests to escape to DNS. DNS operators SHOULD 404 NOT choose to redirect such bogus requests to a site, not even to 405 explain to the user that their P2P resolver is missing or mis- 406 configured as this MAY violate privacy expectations of the user. 408 7. DNS Registries/Registrars 410 In order to avoid conflicts with the P2P namespaces [SAC45], IANA 411 should reserve all six considered pTLDs, and thereby ensure that 412 those labels cannot be registered within the DNS tree, nor their 413 management delegated to any particular organization. 415 6. Acknowledgements 416 The authors thank the I2P developers for their constructive feedback, 417 and Leif Ryge for his proof-reading and valuable feedback. 419 7. References 421 7.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 427 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 428 May 2008. 430 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 431 RFC 6761, February 2013. 433 7.2. Informative References 435 [Curve25519] 436 Bernstein, D., "Curve25519: new Diffie-Hellman speed 437 record", February 2006, 438 . 440 [Dingledine2004] 441 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 442 second-generation onion router", 2004, . 445 [EdDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and Y. 446 Yang, "High-speed, high-security signatures", September 447 2011, . 449 [I2P-NAMING] 450 Random, J., "Naming in I2P and Addressbook", 2003, 451 . 453 [Namecoin] 454 The .bit Project, "Namecoin DNS - DotBIT Project", 2013, 455 . 457 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 458 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 459 1996. 461 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 462 Encodings", RFC 4648, October 2006. 464 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 465 Top Level Domain Queries at the Root Level of the Domain 466 Name System", November 2010, . 469 [Schanzenbach2012] 470 Schanzenbach, M., "Design and Implementation of a 471 Censorship Resistant and Fully Decentralized Name System", 472 September 2012. 474 [SquareZooko] 475 Swartz, A., "Squaring the Triangle: Secure, Decentralized, 476 Human-Readable Names", 2011, 477 . 479 [TOR-ADDRESS] 480 Mathewson, N. and R. Dingledine, "Special Hostnames in 481 Tor", September 2011, . 484 [TOR-EXTSOCKS] 485 Mathewson, N. and R. Dingledine, "Tor's extensions to the 486 SOCKS protocol", September 2011, . 490 [TOR-PATH] 491 Mathewson, N. and R. Dingledine, "Tor Path Specification", 492 April 2013, . 495 [TOR-PROTOCOL] 496 Dingledine, R. and N. Mathewson, "Tor Protocol 497 Specification", November 2013, . 501 [TOR-RENDEZVOUS] 502 Mathewson, N. and R. Dingledine, "Tor Rendezvous 503 Specification", September 2013, . 507 Authors' Addresses 509 Christian Grothoff 510 TU Munich 511 Free Secure Network Systems Group 512 Lehrstuhl fuer Netzarchitekturen und Netzdienste 513 Boltzmannstrasse 3 514 Technische Universitaet Muenchen 515 Garching bei Muenchen, Bayern D-85748 516 DE 518 Email: christian@grothoff.org 520 Matthias Wachs 521 TU Munich 522 Free Secure Network Systems Group 523 Lehrstuhl fuer Netzarchitekturen und Netzdienste 524 Boltzmannstrasse 3 525 Technische Universitaet Muenchen 526 Garching bei Muenchen, Bayern D-85748 527 DE 529 Email: wachs@net.in.tum.de 531 Hellekin O. Wolf (editor) 532 GNU consensus 534 Email: hellekin@gnu.org 536 Jacob Appelbaum 537 Tor Project Inc. 539 Email: jacob@appelbaum.net