idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-names-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2015) is 3377 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 803, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 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 INRIA 4 Intended status: Informational M. Wachs 5 Expires: July 28, 2015 Technische Universitaet Muenchen 6 H. Wolf, Ed. 7 GNU consensus 8 J. Appelbaum 9 L. Ryge 10 Tor Project Inc. 11 January 24, 2015 13 Special-Use Domain Names of Peer-to-Peer Systems 14 draft-grothoff-iesg-special-use-p2p-names-04 16 Abstract 18 This document registers a set of Special-Use Domain Names for use 19 with Peer-to-Peer (P2P) systems, as per RFC6761. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 28, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology and Conventions Used in This Document . . . . . . 4 58 4. Description of Special-Use Domains in P2P Networks . . . . . 5 59 4.1. The "GNU" Relative pTLD . . . . . . . . . . . . . . . . . 5 60 4.2. The "ZKEY" Compressed Public Key pTLD . . . . . . . . . . 6 61 4.3. Geographically Anonymous pTLDs . . . . . . . . . . . . . 8 62 4.3.1. The "ONION" Hidden Service pTLD . . . . . . . . . . . 8 63 4.3.2. The "EXIT" Client Source Routing pTLD . . . . . . . . 10 64 4.3.3. The "I2P" Addressbook pTLD . . . . . . . . . . . . . 12 65 4.4. The "BIT" Timeline System pTLD . . . . . . . . . . . . . 14 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 71 8.2. Informative References . . . . . . . . . . . . . . . . . 19 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 74 1. Introduction 76 The Domain Name System (DNS) is primarily used to map human-memorable 77 names to IP addresses, which are used for routing but generally not 78 meaningful for humans. 80 Peer-to-Peer (P2P) systems use specific decentralized mechanisms to 81 allocate, register, manage, and resolve names. However, the 82 hierarchical nature of DNS makes it unsuitable for various P2P Name 83 Systems. Such P2P Name Systems operate entirely outside of DNS, 84 independently from the DNS root and delegation tree. 86 As compatibility with applications using domain names is desired, 87 these P2P overlay networks often define exclusive alternative Top- 88 Level Domains to avoid conflict between the P2P namespace and the DNS 89 hierarchy. 91 In order to avoid interoperability issues with DNS as well as to 92 address security and privacy concerns, this document registers a set 93 of Special-Use Domain Names for use with P2P systems (pTLDs), as per 94 [RFC6761],: "GNU", "ZKEY", "ONION", "EXIT", "I2P", and "BIT". 96 The GNU Name System (GNS) ("GNU", "ZKEY"), the Tor network ("ONION", 97 "EXIT"), the Invisible Internet Project ("I2P"), and the Dot-Bit 98 Project ("BIT") use these pTLDs to realize fully-decentralized and 99 censorship-resistant naming. The "EXIT" pTLD is used to control 100 overlay routing and to securely specify path selection choices 101 [TOR-PATH]. 103 2. Applicability 105 [RFC6761] Section 3 states: 107 "[I]f a domain name has special properties that affect the way 108 hardware and software implementations handle the name, that apply 109 universally regardless of what network the implementation may be 110 connected to, then that domain name may be a candidate for having 111 the IETF declare it to be a Special-Use Domain Name and specify 112 what special treatment implementations should give to that name. 113 On the other hand, if declaring a given name to be special would 114 result in no change to any implementations, then that suggests 115 that the name may not be special in any material way, and it may 116 be more appropriate to use the existing DNS mechanisms [RFC1034] 117 to provide the desired delegation, data, or lack-of-data, for the 118 name in question. Where the desired behaviour can be achieved via 119 the existing domain name registration processes, that process 120 should be used. Reservation of a Special-Use Domain Name is not a 121 mechanism for circumventing normal domain name registration 122 processes." 124 The set of Special-Use Domain Names for Peer-to-Peer Systems (pTLDs) 125 reserved by this document meet this requirement, as they share the 126 following specificities: 128 o pTLDs are not manageable by some designated administration. 129 Instead, they are managed according to various alternate 130 strategies or combinations thereof, introduced in this document, 131 and their respective protocol specifications: automated 132 cryptographic assignment (".onion", ".zkey"), user-controled 133 assignment in a private scope (".gnu", ".i2p"), or in a global 134 public ledger (".bit"), or used as a source-routing mechanism to 135 delegate DNS resolution to a remote peer (".exit"). 137 o pTLDs do not depend on the DNS context for their resolution: GNS 138 and Namecoin domains MAY use the DNS servers infrastructure, as 139 they return DNS-compatible results; and all pTLDs use specific P2P 140 protocols for regular name resolution, covered by their respective 141 protocol specifications. 143 o When a pTLD protocol has been implemented, the implementation MUST 144 intercept queries for the pTLD to ensure P2P names cannot leak 145 into the DNS. 147 o The appropriate pTLD protocols can be implemented in existing 148 software libraries and APIs to extend regular DNS operation and 149 enable P2P name resolution. However, the default hierarchical DNS 150 response to any request to any pTLD MUST be NXDOMAIN. 152 o Finally, in order for pTLDs to realize a censorship-resistant, 153 fully-decentralized name system, and provide security and privacy 154 features matching user expectations, this document specifies 155 changes required in existing DNS software and DNS operations. 157 3. Terminology and Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 The word "peer" is used in the meaning of a individual system on the 164 network. 166 The abbreviation "pTLD" is used in this document to mean a pseudo 167 Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] 168 reserved to P2P Systems in this document. A pTLD is mentioned in 169 capitals, and within double quotes to mark the difference with a 170 regular DNS gTLD. 172 In this document, ".tld" (lowercase, with quotes) means: any domain 173 or hostname within the scope of a given pTLD, while .tld (lowercase, 174 without quotes) refers to an adjective form. For example, a 175 collection of ".gnu" peers in "GNU", but an .onion URL. [TO REMOVE: 176 in the IANA Considerations section, we use the simple .tld format to 177 request TLD reservation for consistency with previous RFCs]. 179 The word "NXDOMAIN" refers to an alternate expression for the "Name 180 Error" RCODE as described in section 4.1.1 of [RFC1035]. When 181 referring to "NXDOMAIN" and negative caching [RFC2308] response, this 182 document means an authoritative (AA=1) name error (RCODE=3) response 183 exclusively. 185 The Tor-related names such as 'circuit', 'exit', 'node', 'relay', 186 'stream', and related Tor terms are described in [Dingledine2004] and 187 the Tor protocol specification [TOR-PROTOCOL]. 189 The I2P-related names such as 'Destination' are described in 190 [zzz2009]. 192 4. Description of Special-Use Domains in P2P Networks 194 4.1. The "GNU" Relative pTLD 196 "GNU" is used to specify that a domain name should be resolved using 197 GNS. The GNS resolution process is documented in [Wachs2014]. 199 The "GNU" domain is special in the following ways: 201 1. Users can use these names as they would other domain names, 202 entering them anywhere that they would otherwise enter a 203 conventional DNS domain name. 205 Since there is no central authority responsible for assigning 206 .gnu names, and that specific domain is local to the local peer, 207 users need to be aware of that specificity. 209 Legacy applications MAY expect the DNS-to-GNS proxy to return DNS 210 compatible results for the resolution of .gnu domains. 212 2. Legacy application software does not need to recognize .gnu 213 domains as special, and may continue to use these names as they 214 would other domain names. 216 GNS-aware applications MAY also use GNS resolvers directly to 217 resolve .gnu domains (in particular, if they want access to GNS- 218 specific record types). 220 3. Name resolution APIs and libraries SHOULD either respond to 221 requests for .gnu names by resolving them via the GNS protocol, 222 or respond with NXDOMAIN. 224 4. Caching DNS servers SHOULD recognize .gnu names as special and 225 SHOULD NOT attempt to look up NS records for them, or otherwise 226 query authoritative DNS servers in an attempt to resolve .gnu 227 names. Instead, caching DNS servers SHOULD generate immediate 228 negative responses for all such queries. 230 5. Authoritative DNS servers are not expected to treat .gnu domain 231 requests specially. In practice, they MUST answer with NXDOMAIN, 232 as "GNU" is not available via global DNS resolution, and not 233 doing so can put users' privacy at risk (see item 6). 235 6. DNS server operators SHOULD be aware that .gnu names are reserved 236 for use with GNS, and MUST NOT override their resolution (e.g., 237 to redirect users to another service or error information). 239 7. DNS registries/registrars MUST NOT grant any request to register 240 .gnu names. This helps avoid conflicts [SAC45]. These names are 241 defined by the GNS protocol specification, and they fall outside 242 the set of names available for allocation by registries/ 243 registrars. 245 4.2. The "ZKEY" Compressed Public Key pTLD 247 The "ZKEY" pTLD is used to signify that resolution of the given name 248 MUST be performed using a record signed by an authority that is in 249 possession of a particular public key. Names in "ZKEY" MUST end with 250 a domain which is the compressed point representation from [EdDSA] on 251 [Curve25519] of the public key of the authority, encoded using 252 Crockford's variant of base32hex [RFC4648] (with additionally 'U' 253 being considered equal to 'V') for easier optical character 254 recognition. A GNS resolver uses the key to locate a record signed 255 by the respective authority. 257 "ZKEY" provides a (reverse) mapping from globally unique hashes to 258 public key, therefore .zkey names are non-memorable, and are expected 259 to be hidden from the user [Wachs2014]. 261 The "ZKEY" domain is special in the following ways: 263 1. Users can use these names as they would other domain names, 264 entering them anywhere that they would otherwise enter a 265 conventional DNS domain name. 267 Since there is no central authority necessary or possible for 268 assigning .zkey names, and those names match cryptographic keys, 269 users need to be aware that they do not belong to regular DNS, 270 but are still global in their scope. 272 Legacy applications MAY expect the DNS-to-GNS proxy to return 273 DNS-compatible results for the resolution of .zkey domains. 275 2. Application software does not need to recognize .zkey domains as 276 special, and may continue to use these names as they would other 277 domain names. 279 GNS-aware applications MAY also use GNS resolvers directly to 280 resolve .zkey domains 282 3. Name resolution APIs and libraries SHOULD either respond to 283 requests for .zkey names by resolving them via the GNS protocol, 284 or respond with NXDOMAIN. 286 4. Caching DNS servers SHOULD recognize .zkey names as special and 287 SHOULD NOT attempt to look up NS records for them, or otherwise 288 query authoritative DNS servers in an attempt to resolve .zkey 289 names. Instead, caching DNS servers SHOULD generate immediate 290 negative responses for all such queries. 292 5. Authoritative DNS Servers are not expected to treat .zkey domain 293 requests specially. In practice, they MUST answer with NXDOMAIN, 294 as "ZKEY" is not available via global DNS resolution, and not 295 doing so MAY put users' privacy at risk (see item 6). 297 6. DNS server operators SHOULD be aware that .zkey names are 298 reserved for use with GNS, and MUST NOT override their resolution 299 (e.g., to redirect users to another service or error 300 information). 302 7. DNS registries/registrars MUST NOT grant any request to register 303 .zkey names. This helps avoid conflicts [SAC45]. These names 304 are defined as described above, and they fall outside the set of 305 names available for allocation by registries/registrars. 307 4.3. Geographically Anonymous pTLDs 309 Both the Tor "Onionspace" and the I2P network are designed to provide 310 geographic anonymity to services and all clients visiting them. They 311 provide additional properties such as NAT traversal, strong 312 authentication, anonymity, and censorship resistance. 314 The Tor anonymization network makes use of several special pTLD 315 labels, three of which have seen widespread usage to date. This 316 document introduces two of them, "ONION" and "EXIT". The interested 317 reader is invited to refer to [TOR-ADDRESS] for further information 318 on the "NOCONNECT" pTLD, whose limited testing scope does not warrant 319 the attention of the larger Internet community. 321 The I2P network uses a single pTLD, "I2P", but the specific subdomain 322 "B32.I2P" offers properties similar to Tor's "ONION" and GNS's "ZKEY" 324 The public literature often uses the term "Hidden Service" to refer 325 to both Tor's Hidden Service protocol and services, and I2P's 326 Destinations. This term suggests that such services are hidden from 327 view, whereas only their geographic location is unknown: given their 328 name and the appropriate name resolver, such services are as much 329 accessible as any other regular Web site or Internet service. 331 4.3.1. The "ONION" Hidden Service pTLD 333 The widely deployed "ONION" designates the "Onionspace", an anonymous 334 Tor Hidden Service reachable via the Tor network [Dingledine2004]. 335 These .onion hostnames are self-authenticating addresses for use with 336 any TCP service. 338 Addresses in "ONION" are opaque, non-mnemonic, alpha-semi-numeric 339 digest hashes corresponding to the unique identity key of a given Tor 340 hidden service. Therefore such .onion addresses are self- 341 authenticating. The algorithm to obtain the .onion hash from the Tor 342 hidden service's public key is out of scope of this document, and 343 described in the Tor Address specification [TOR-ADDRESS]. Tor 344 generates this "Onion key" automatically when the hidden service is 345 configured. Tor clients use it following the Tor Rendezvous 346 specifications [TOR-RENDEZVOUS]. 348 The "ONION" domain is special in the following ways: 350 1. Users can use these names as they would other domain names, 351 entering them anywhere that they would otherwise enter a 352 conventional DNS domain name. 354 Since there is no central authority necessary or possible for 355 assigning .onion names, and those names correspond to 356 cryptographic keys, users need to be aware that they do not 357 belong to regular DNS, but are still global in their scope. 359 2. Application software MAY recognize .onion domains as special, and 360 SHOULD use these names as they would other domain names. 362 Application software MAY implement mechanisms helping the user to 363 ensure their privacy expectations are met, such as warning the 364 user if they do not detect an active local Tor resolver, 365 displaying a warning on first-use of an .onion domain to explain 366 the necessity of a Tor resolver to reach such domains, etc. 368 If an application knows how to differenciate between DNS and P2P 369 name resolution, it: 371 * SHOULD NOT pass requests for .onion domains to DNS resolvers 372 or libraries, 374 * MUST expect NXDOMAIN as the only valid DNS response, and 376 * SHOULD treat other answers from DNS as errors. 378 Tor-aware applications MAY also use Tor resolvers directly. 380 3. Name resolution APIs and libraries SHOULD either respond to 381 requests for .onion names by resolving them via the Tor protocol, 382 or respond with NXDOMAIN. 384 4. Caching DNS servers SHOULD recognize .onion names as special and 385 SHOULD NOT attempt to look up NS records for them, or otherwise 386 query authoritative DNS servers in an attempt to resolve .onion 387 names. Instead, caching DNS servers SHOULD generate immediate 388 negative responses for all such queries. 390 5. Authoritative DNS servers are not expected to treat .onion domain 391 requests specially. In practice, they MUST answer with NXDOMAIN, 392 as "ONION" is not available via global DNS resolution, and not 393 doing so MAY put users' privacy at risk (see item 6). 395 6. DNS server operators SHOULD be aware that .onion names are 396 reserved for use with Tor, and MUST NOT override their resolution 397 (e.g., to redirect users to another service or error 398 information). 400 7. DNS registries/registrars MUST NOT grant any request to register 401 .onion names. This helps avoid conflicts [SAC45]. These names 402 are defined the Tor protocol specification [TOR-PROTOCOL], and 403 they fall outside the set of names available for allocation by 404 registries/registrars. 406 4.3.2. The "EXIT" Client Source Routing pTLD 408 The .exit suffix is used as an in-band source routing control 409 channel, usually for selection of a specific Tor relay during path 410 creation as the last node in the Tor circuit. 412 It may be used to access a DNS host via specific Torservers, in the 413 form "hostname.nickname-or-fingerprint.exit", where the "hostname" is 414 a valid hostname, and the "nickname-or-fingerprint" is either the 415 nickname of a Tor relay in the Tor network consensus, or the hex- 416 encoded SHA1 digest of the given node's public key (fingerprint). 418 For example, "gnu.org.noisetor.exit" will route the client to 419 "gnu.org" via the Tor node nicknamed "noisetor". Using the 420 fingerprint instead of the nickname ensures that the path selection 421 uses a specific Tor exit node, and is harder to remember: e.g., 422 "gnu.org.f97f3b153fed6604230cd497a3d1e9815b007637.exit". 424 When Tor sees an address in this format, it uses the specified 425 "nickname-or-fingerprint" as the exit node. If no "hostname" 426 component is given, Tor defaults to the published IPv4 address of the 427 Tor exit node [TOR-EXTSOCKS]. 429 Because "hostname" is allegedly valid, the total length of a .exit 430 construct may exceed the maximum length allowed for domain names. 431 Moreover, the resolution of "hostname" happens at the exit node. 432 Trying to resolve such invalid domain names, including chaining .exit 433 names will likely return a DNS lookup failure at the first exit node. 435 The "EXIT" domain is special in the following ways: 437 1. Users can use these names as they would other domain names, 438 entering them anywhere that they would otherwise enter a 439 conventional DNS domain name. 441 Since .exit names correspond to a Tor-specific routing construct 442 to reach target hosts via chosen Tor exit nodes, users need to be 443 aware that they do not belong to regular DNS and that the actual 444 target precedes the second-level domain name. 446 2. Application software MAY recognize that .exit domains are special 447 and when they do SHOULD NOT pass requests for these domains to 448 DNS resolvers and libraries. 450 As mentioned in items 4 and 5 below, regular DNS resolution is 451 expected to respond with NXDOMAIN. Therefore, if it can 452 differentiate between DNS and P2P name resolution, application 453 software: 455 * MUST expect NXDOMAIN as the only valid DNS response, and 457 * SHOULD treat other answers from DNS as errors. 459 Tor-aware applications MAY also use Tor resolvers directly. 461 3. Name resolution APIs and libraries SHOULD either respond to 462 requests for .exit names by resolving them via the Tor protocol, 463 or respond with NXDOMAIN. 465 4. Caching DNS servers SHOULD recognize .exit names as special and 466 SHOULD NOT, by default, attempt to look up NS records for them, 467 or otherwise query authoritative DNS servers in an attempt to 468 resolve .exit names. Instead, caching DNS servers SHOULD, by 469 default, generate immediate negative responses for all such 470 queries. 472 5. Authoritative DNS servers are not expected to treat .exit domain 473 requests specially. In practice, they MUST answer with NXDOMAIN, 474 as "EXIT" is not available via global DNS resolution, and not 475 doing so MAY put users' privacy at risk (see item 6). 477 6. DNS server operators SHOULD be aware that .exit names are 478 reserved for use with Tor, and MUST NOT override their resolution 479 (e.g., to redirect users to another service or error 480 information). 482 7. DNS registries/registrars MUST NOT grant any request to register 483 .exit names. This helps avoid conflicts [SAC45]. These names 484 are defined by the Tor address specification, and they fall 485 outside the set of names available for allocation by registries/ 486 registrars. 488 4.3.3. The "I2P" Addressbook pTLD 490 "I2P" provides accessibility to hidden services within the I2P 491 network [zzz2009]. I2P is a scalable, self-organizing, resilient 492 packet switched anonymous network layer, upon which any number of 493 different anonymity or security-conscious applications can operate, 494 using any protocol. 496 I2P hidden services and clients are identified by Destinations, 497 anonymous analogues of IP addresses. The "I2P" pTLD, chosen in 2003 498 [I2P-CHOICE], houses two methods for looking up Destinations: 500 A local table called the addressbook stores a map of .i2p 501 addresses to Destinations. Each user maintains their own mappings 502 that can be shared with others, allowing them to "discover" new 503 names by importing published addressbooks of peers, and they can 504 emulate traditional DNS by choosing to treat these peers as name 505 servers. The comparison however stops here, as only local 506 uniqueness is mandated. As the system is decentralized, 507 "example.i2p" may resolve differently for different peers 508 depending on the state of their respective addressbooks. 510 To address globally unique names, the I2P developers dedicated the 511 "B32.I2P" subdomain to hold Base32-encoded [RFC4648] references to 512 Destinations. Like .onion addresses, .b32.i2p addresses are self- 513 authenticating. The details of the encoding are out of scope for 514 this document, and documented in [I2P-NAMING]. The purpose of 515 .b32.i2p addresses is similar to ".zkey", that is to enable 516 (reverse) mapping for a globally unique hidden service that may 517 not have a defined entry in the local addressbook. 519 The "I2P" domain is special in the following ways: 521 1. Users can use these names as they would other domain names, 522 entering them anywhere that they would otherwise enter a 523 conventional DNS domain name. 525 Since there is no central authority responsible for assigning 526 .i2p names, and that the ultimate mapping is decided by the local 527 peer, users need to be aware of that specificity. 529 2. Application software SHOULD recognize .i2p domains as special and 530 SHOULD NOT use them as they would other domains. 532 Applications SHOULD NOT pass requests for .i2p domains to DNS 533 resolvers and libraries. 535 As mentioned in points 4 and 5 below, regular DNS resolution is 536 expected to respond with NXDOMAIN. Therefore, if it can 537 differentiate between DNS and P2P name resolution, application 538 software can expect such a response, and can choose to treat 539 other responses from resolvers and libraries as errors. 541 3. Name resolution APIs and libraries SHOULD either respond to 542 requests for .i2p names by resolving them via the I2P protocol, 543 or respond with NXDOMAIN. 545 4. Caching DNS servers SHOULD recognize .i2p names as special and 546 SHOULD NOT attempt to look up NS records for them, or otherwise 547 query authoritative DNS servers in an attempt to resolve .i2p 548 names. Instead, caching DNS servers SHOULD generate immediate 549 negative responses for all such queries. 551 5. Authoritative DNS servers are not expected to treat .i2p domain 552 requests specially. In practice, they MUST answer with NXDOMAIN, 553 as "I2P" is not available via global DNS resolution, and not 554 doing so MAY put users' privacy at risk (see item 6). 556 6. DNS server operators SHOULD be aware that .i2p names are reserved 557 for use with I2P, and MUST NOT override their resolution (e.g., 558 to redirect users to another service or error information). 560 7. DNS registries/registrars MUST NOT grant any request to register 561 .i2p names. This helps avoid conflicts [SAC45]. These names are 562 defined by the I2P protocol specification, and they fall outside 563 the set of names available for allocation by registries/ 564 registrars. 566 4.4. The "BIT" Timeline System pTLD 568 Namecoin is a timeline-based system in the style of Bitcoin to create 569 a global, secure, and memorable name system. It creates a single, 570 globally accessible, append-only timeline of name registrations. 571 Timeline-based systems rely on a peer-to-peer network to manage 572 updates and store the timeline. In the Namecoin system, 573 modifications to key-value mapping are attached to transactions which 574 are committed to the timeline by "mining". Mining is the use of 575 brute-force methods to find (partial) hash collisions with a state 576 summary (fingerprint) representing the complete global state -- 577 including the full history -- of the timeline . 579 "BIT" provides a name space where names are registered via 580 transactions in the Namecoin currency [Namecoin]. Like Bitcoins, 581 Namecoins are created using a proof-of-work calculation, which is 582 also used to establish a decentralized, multi-party consensus on the 583 valid transaction history, and thus the set of registered names and 584 their values [SquareZooko]. 586 The Namecoin used in a transaction to register a name in "BIT" is 587 lost. This is not a fundamental problem as more coins can be 588 generated via mining (proof-of-work calculations). The registration 589 cost is set to decrease over time, to prevent early adopters from 590 registering too many names. 592 The owner of a name can update the associated value by issuing an 593 update, which is a transaction that uses a special coin. This coin 594 is generated as change during the registration operation. If a name 595 is not updated for a long time, the registration expires. 597 Performing a lookup for a name with Namecoin consists in checking the 598 timeline for correctness to ensure the validity of the blockchain, 599 and traversing it to see if it contains an entry for the desired 600 name. Namecoin supports resolution for other peer-to-peer systems 601 such as ".onion" and ".i2p" via specific resource records. 603 Like DNS registry, the Dot-Bit registry is public. But unlike DNS, 604 the public registry is maintained by network consensus on the 605 blockchain. It departs from DNS in three ways: 607 first, domain names are not delegated to an authority that can 608 assign them, but acquired by the operating party (the "domain 609 owner"), in the form of a historical claim made directly by 610 appending to the Namecoin blockchain. The domain is thus bound 611 not to a legal contract with an administrative authority, but to a 612 cryptographic coin, and the network consensus on the timeline. 614 second, the timeline contains the entire registry for all .bit 615 domains: the Namecoin blockchain itself is the complete domain 616 database. As participant peers maintain the consensus on the 617 timeline, they store a local copy of the Namecoin blockchain. 618 Therefore, to those peers, name resolution and registry traversal 619 are both local and private. Each participant theoretically owns 620 the whole domain's database. In practice, some users can trust a 621 name server to access the Namecoin blockchain on their behalf. 623 third, the Namecoin system is not limited to domain names and can 624 store arbitrary data types. Each record must follow the same 625 rules (expiry time, data size limits, etc.). The Namecoin's 626 Domain Name Specification [Namecoin-DNS] defines the "d namespace" 627 for use with "BIT" and other unrelated namespaces co-exist on the 628 Namecoin blockchain. 630 The "BIT" domain is special in the following ways: 632 1. Users can use these names as they would other domain names, 633 entering them anywhere that they would otherwise enter a 634 conventional DNS domain name. 636 From the user's perspective, the resolution of .bit names is 637 similar to the normal DNS resolution, and thus should not affect 638 normal usage of most Internet applications. 640 2. Application software SHOULD NOT recognize .bit domains as special 641 and SHOULD treat them as they would other domains. 643 Applications MAY pass requests to the "BIT" pTLD to DNS resolvers 644 and libraries if A/AAAA records are desired. If available, the 645 local resolver can intercept such requests within the respective 646 operating system hooks and return DNS-compatible results. 648 Namecoin-aware applications MAY choose to talk directly to the 649 respective P2P resolver, and use this to access additional record 650 types that are not defined in DNS. 652 3. Name resolution APIs and libraries SHOULD either respond to 653 requests for .bit names by resolving them via the Namecoin 654 protocol, or respond with NXDOMAIN. 656 4. Caching DNS servers SHOULD recognize .bit names as special and 657 SHOULD NOT attempt to resolve them. Instead, caching DNS servers 658 SHOULD generate immediate negative responses for all such 659 queries. 661 Given that .bit users typically have no special privacy 662 expectations, and those names are globally unique, local caching 663 DNS servers MAY choose to treat them as regular domain names, and 664 cache the responses obtained from the Namecoin blockchain. In 665 that case however, NXDOMAIN results SHOULD NOT be cached, as new 666 .bit domains may become active at any time. 668 5. Authoritative DNS servers are not expected to treat .bit domain 669 requests specially. In practice, they MUST answer with NXDOMAIN, 670 as "BIT" is not available via global DNS resolution. 672 6. DNS server operators SHOULD be aware that .bit names are reserved 673 for use with Namecoin, and MUST NOT override their resolution 674 (e.g., to redirect users to another service or error 675 information). 677 7. DNS registries/registrars MUST NOT grant any request to register 678 .bit names. This helps avoid conflicts [SAC45]. These names are 679 defined by the Namecoin protocol specification, and they fall 680 outside the set of names available for allocation by registries/ 681 registrars. 683 5. Security Considerations 685 Specific software performs the resolution of the six Special-Use 686 Domain Names presented in this document; this resolution process 687 happens outside of the scope of DNS. Leakage of requests to such 688 domains to the global operational DNS can cause interception of 689 traffic that might be misused to monitor, censor, or abuse the user's 690 trust, and lead to privacy issues with potentially tragic 691 consequences for the user. 693 This document reserves these Top-Level Domain names to minimize the 694 possibility of confusion, conflict, and especially privacy risks for 695 users. 697 In the introduction of this document, there's a requirement that DNS 698 operators do not override resolution of the P2P Names. This is a 699 regulatory measure and cannot prevent such malicious abuse in 700 practice. Its purpose is to limit any information leak that would 701 result from incorrectly configured systems, and to avoid that 702 resolvers make unnecessary contact to the DNS Root Zone for such 703 domains. Verisign, Inc., as well as several Internet service 704 providers (ISPs) have notoriously abused their position to override 705 NXDOMAIN responses to their customers in the past. For example, if a 706 DNS operator would decide to override NXDOMAIN and send advertising 707 to leaked .onion sites, the information leak to the DNS would extend 708 to the advertising server, with unpredictable consequences. Thus, 709 implementors should be aware that any positive response coming from 710 DNS must be considered with extra care, as it suggests a leak to DNS 711 has been made, contrary to user's privacy expectations. 713 The reality of X.509 Certificate Authorities (CAs) creating 714 misleading certificates for these pTLDs due to ignorance stresses the 715 need to document their special use. X.509 Certificate Authorities 716 MAY create certificates for "ONION", "BIT", and "ZKEY" given CSRs 717 signed with the respective private keys corresponding to the 718 respective names. For "BIT", the Certificate Authority SHOULD limit 719 the expiration time of the certificate to match the registration. 720 Certificate Authorities MUST NOT create certificates for the "EXIT", 721 "GNU", and "I2P" Top-Level domains. Nevertheless, clients SHOULD 722 accept certificates for these Top-Level domains as they may be 723 created legitimately by local proxies on the fly. 725 [SAC57] reports, page 11, that the CA/Browser forum stated: "Also as 726 of the Effective Date [1 July 2012], the CA SHALL NOT issue a 727 certificate with an Expiry Date later than 1 November 2015 with a 728 subjectAlternativeName extension or Subject commonName field 729 containing a Reserved IP Address or Internal Server Name." 731 It is not clear whether e.g., .onion sites are considered "Internal 732 Server Names", however, we can expect that services doubling their 733 public Web site with an onion site would use a single SSL certificate 734 for both, as did Facebook with "facebookcorewwwi.onion". Given this 735 forum also declared the CAs would revoke such SSL certificates in 736 October 2016, that opens a three (now two) years period of 737 vulnerability for new gTLDs to suffer MiTM attacks over HTTPS. Such 738 practice by CAs to validate certificates to invalid TLDs without 739 verification may lead, e.g., to mailicious third parties without any 740 relation to an existing .onion site to register a fake certificate 741 for that site in order to facilitate attacks, especially when 742 combined with name collision risk as explained in [SAC62]. 744 Because the Namecoin system uses a timeline-based blockchain for name 745 assignment and resolution, it grants query privacy to the users who 746 maintain their own copy of the blockchain (Section 4.4), but the 747 entire zone of a .bit domains is publicly available in the Namecoin 748 blockchain, making enumeration of names within a .bit zone ("zone 749 walking") a trivial attack to conduct. This might be a concern to 750 some domain operators as it exposes their infrastructure to potential 751 adversaries. That concern may be addressed in future versions of 752 Namecoin, but the records already in the blockchain will remain there 753 unprotected. 755 Finally, legacy applications that do not explicitly support the pTLDs 756 significantly increase the risk of pTLD queries escaping to DNS, as 757 they are entirely dependent on the correct configuration on the 758 operating system. 760 6. IANA Considerations 762 The Internet Assigned Numbers Authority (IANA) reserved the following 763 entries in the Special-Use Domain Names registry [RFC6761]: 765 .gnu 767 .zkey 769 .onion 771 .exit 773 .i2p 775 .bit 777 [TO REMOVE: the assignement URL is https://www.iana.org/assignments/ 778 special-use-domain-names/ ] 780 7. Acknowledgements 782 The authors thank the I2P and Namecoin developers for their 783 constructive feedback, as well as Mark Nottingham for his proof- 784 reading and valuable feedback. The authors also thank the members of 785 DNSOP WG for their critiques and suggestions. 787 8. References 789 8.1. Normative References 791 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 792 STD 13, RFC 1034, November 1987. 794 [RFC1035] Mockapetris, P., "Domain names - implementation and 795 specification", STD 13, RFC 1035, November 1987. 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, March 1997. 800 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 801 NCACHE)", RFC 2308, March 1998. 803 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 804 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 805 May 2008. 807 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 808 RFC 6761, February 2013. 810 8.2. Informative References 812 [Curve25519] 813 Bernstein, D., "Curve25519: new Diffie-Hellman speed 814 record", February 2006, 815 . 817 [Dingledine2004] 818 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 819 second-generation onion router", 2004, . 822 [EdDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and Y. 823 Yang, "High-speed, high-security signatures", September 824 2011, . 826 [I2P-CHOICE] 827 Hacker, J. and The I2P Community, "I2P Dev Meeting 059", 828 September 2003, . 830 [I2P-NAMING] 831 Hacker, J. and The I2P Community, "Naming in I2P and 832 Addressbook", April 2014, . 835 [Namecoin] 836 The .bit Project, "Namecoin", 2013, 837 . 839 [Namecoin-DNS] 840 The .bit Project, "Namecoin Domain Name Specification", 841 2015, . 843 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 844 Encodings", RFC 4648, October 2006. 846 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 847 Top Level Domain Queries at the Root Level of the Domain 848 Name System", November 2010, . 851 [SAC57] ICANN Security and Stability Advisory Committee, "SSAC 852 Advisory on Internal Name Certificates", March 2013, 853 . 856 [SAC62] ICANN Security and Stability Advisory Committee, "SSAC 857 Advisory Concerning the Mitigation of Name Collision 858 Risk", November 2013, . 861 [SquareZooko] 862 Swartz, A., "Squaring the Triangle: Secure, Decentralized, 863 Human-Readable Names", 2011, 864 . 866 [TOR-ADDRESS] 867 Mathewson, N. and R. Dingledine, "Special Hostnames in 868 Tor", September 2011, . 871 [TOR-EXTSOCKS] 872 Mathewson, N. and R. Dingledine, "Tor's extensions to the 873 SOCKS protocol", February 2014, . 876 [TOR-PATH] 877 Mathewson, N. and R. Dingledine, "Tor Path Specification", 878 November 2014, . 881 [TOR-PROTOCOL] 882 Dingledine, R. and N. Mathewson, "Tor Protocol 883 Specification", August 2014, . 886 [TOR-RENDEZVOUS] 887 Mathewson, N. and R. Dingledine, "Tor Rendezvous 888 Specification", April 2014, . 891 [Wachs2014] 892 Wachs, M., Schanzenbach, M., and C. Grothoff, "A 893 Censorship-Resistant, Privacy-Enhancing and Fully 894 Decentralized Name System", October 2014, . 897 [zzz2009] The I2P Project and L. Schimmer, "Peer Profiling and 898 Selection in the I2P Anonymous Network", January 2009, 899 . 901 Authors' Addresses 903 Christian Grothoff 904 INRIA 905 Equipe Decentralisee 906 INRIA Rennes Bretagne Atlantique 907 263 avenue du General Leclerc 908 Campus Universitaire de Beaulieu 909 Rennes, Bretagne F-35042 910 FR 912 Email: christian@grothoff.org 914 Matthias Wachs 915 Technische Universitaet Muenchen 916 Free Secure Network Systems Group 917 Lehrstuhl fuer Netzarchitekturen und Netzdienste 918 Boltzmannstrasse 3 919 Technische Universitaet Muenchen 920 Garching bei Muenchen, Bayern D-85748 921 DE 923 Email: wachs@net.in.tum.de 924 Hellekin O. Wolf (editor) 925 GNU consensus 927 Email: hellekin@gnu.org 929 Jacob Appelbaum 930 Tor Project Inc. 932 Email: jacob@appelbaum.net 934 Leif Ryge 935 Tor Project Inc. 937 Email: leif@synthesize.us