idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-bit-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 : ---------------------------------------------------------------------------- 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 (June 30, 2015) is 3195 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 24, 2015 Technische Universitaet Muenchen 6 H. Wolf, Ed. 7 GNU consensus 8 J. Appelbaum 9 L. Ryge 10 Tor Project Inc. 11 June 30, 2015 13 Special-Use Domain Name for Namecoin 14 draft-grothoff-iesg-special-use-p2p-bit-00 16 Abstract 18 This document registers a Special-Use Domain Name for use with the 19 Namecoin system, 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 December 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Terminology and Conventions Used in This Document . . . . . . 3 58 4. The "BIT" Timeline System pTLD . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 8.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 The Domain Name System (DNS) is primarily used to map human-memorable 70 names to IP addresses, which are used for routing but generally not 71 meaningful for humans. 73 Namecoin offers a specific timeline-based mechanism to allocate, 74 register, manage, and resolve names, independently from the DNS root 75 and delegation tree. 77 As compatibility with applications using domain names is desired, 78 Namecoin uses an exclusive alternative Top-Level Domain to avoid 79 conflicts between the Namecoin namespace and the DNS hierarchy. 81 In order to avoid interoperability issues with DNS as well as to 82 address security and privacy concerns, this document registers the 83 Special-Use Domain Names "BIT" for use with Namecoin, as per 84 [RFC6761]. 86 Namecoin (also known as the Dot-Bit Project) uses this pTLD to 87 realize censorship-resistant naming. 89 2. Applicability 91 [RFC6761] Section 3 states: 93 "[I]f a domain name has special properties that affect the way 94 hardware and software implementations handle the name, that apply 95 universally regardless of what network the implementation may be 96 connected to, then that domain name may be a candidate for having 97 the IETF declare it to be a Special-Use Domain Name and specify 98 what special treatment implementations should give to that name. 99 On the other hand, if declaring a given name to be special would 100 result in no change to any implementations, then that suggests 101 that the name may not be special in any material way, and it may 102 be more appropriate to use the existing DNS mechanisms [RFC1034] 103 to provide the desired delegation, data, or lack-of-data, for the 104 name in question. Where the desired behaviour can be achieved via 105 the existing domain name registration processes, that process 106 should be used. Reservation of a Special-Use Domain Name is not a 107 mechanism for circumventing normal domain name registration 108 processes." 110 The Special-Use Domain Name for Namecoin reserved by this document 111 meets this requirement, as it has the following specificities: 113 o The "BIT" pTLD is not manageable by some designated 114 administration. Instead, it is managed by a P2P protocol using a 115 global public ledger. 117 o Namecoin does not depend on the DNS context for their resolution: 118 Namecoin domains MAY use the DNS servers infrastructure, as they 119 return DNS-compatible results; but it uses specific P2P protocols 120 for regular name resolution, covered by the respective protocol 121 specifications. 123 o When Namecoin is properly implemented, the implementation MUST 124 intercept queries for the pTLD to ensure Namecoin names cannot 125 leak into the DNS. 127 o The appropriate pTLD protocols can be implemented in existing 128 software libraries and APIs to extend regular DNS operation and 129 enable Namecoin name resolution. However, the default 130 hierarchical DNS response to any request to any pTLD MUST be 131 NXDOMAIN. 133 o Finally, in order for Namecoin to realize a censorship-resistant 134 name system, this document specifies changes required in existing 135 DNS software and DNS operations. 137 3. Terminology and Conventions Used in This Document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The word "peer" is used in the meaning of a individual system on the 144 network. 146 The abbreviation "pTLD" is used in this document to mean a pseudo 147 Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] 148 reserved to P2P Systems in this document. A pTLD is mentioned in 149 capitals, and within double quotes to mark the difference with a 150 regular DNS gTLD. 152 In this document, ".tld" (lowercase, with quotes) means: any domain 153 or hostname within the scope of a given pTLD, while .tld (lowercase, 154 without quotes) refers to an adjective form. For example, a 155 collection of ".bit" peers in "BIT", but an .bit URL. [TO REMOVE: in 156 the IANA Considerations section, we use the simple .tld format to 157 request TLD reservation for consistency with previous RFCs]. 159 The word "NXDOMAIN" refers to an alternate expression for the "Name 160 Error" RCODE as described in section 4.1.1 of [RFC1035]. When 161 referring to "NXDOMAIN" and negative caching [RFC2308] response, this 162 document means an authoritative (AA=1) name error (RCODE=3) response 163 exclusively. 165 4. The "BIT" Timeline System pTLD 167 Namecoin is a timeline-based system in the style of Bitcoin to create 168 a global, secure, and memorable name system. It creates a single, 169 globally accessible, append-only timeline of name registrations. 170 Timeline-based systems rely on a peer-to-peer network to manage 171 updates and store the timeline. In the Namecoin system, 172 modifications to key-value mapping are attached to transactions which 173 are committed to the timeline by "mining". Mining is a proof-of-work 174 calculation that uses brute-force methods to find (partial) hash 175 collisions with a state summary (fingerprint) representing the 176 complete global state -- including the full history -- of the 177 timeline . 179 "BIT" provides a name space where names are registered via 180 transactions in the Namecoin currency [Namecoin]. Like Bitcoins, 181 Namecoins are used to establish a decentralized, multi-party 182 consensus on the valid transaction history, and thus the set of 183 registered names and their values [SquareZooko]. 185 The Namecoin used in a transaction to register a name in "BIT" is 186 lost. This is not a fundamental problem as more coins can be 187 generated via mining (proof-of-work calculations). The registration 188 cost is set to decrease over time, to prevent early adopters from 189 registering too many names. 191 The owner of a name can update the associated value by issuing an 192 update, which is a transaction that uses a special coin. This coin 193 is generated as change during the registration operation. If a name 194 is not updated for a long time, the registration expires. 196 Performing a lookup for a name with Namecoin consists in checking the 197 timeline for correctness to ensure the validity of the blockchain, 198 and traversing it to see if it contains an entry for the desired 199 name. Namecoin supports resolution for other peer-to-peer systems 200 such as ".onion" and ".i2p" via specific resource records. 202 Like DNS registry, the Dot-Bit registry is public. But unlike DNS, 203 the public registry is maintained by network consensus on the 204 blockchain. It departs from DNS in three ways: 206 first, domain names are not delegated to an authority that can 207 assign them, but acquired by the operating party (the "domain 208 owner"), in the form of a historical claim made directly by 209 appending to the Namecoin blockchain. The domain is thus bound 210 not to a legal contract with an administrative authority, but to a 211 cryptographic coin, and the network consensus on the timeline. 213 second, the timeline contains the entire registry for all .bit 214 domains: the Namecoin blockchain itself is the complete domain 215 database. As participant peers maintain the consensus on the 216 timeline, they store a local copy of the Namecoin blockchain. 217 Therefore, to those peers, name resolution and registry traversal 218 are both local and private. Each participant theoretically has 219 the whole domain's database. In practice, some users can trust a 220 name server to access the Namecoin blockchain on their behalf. 222 third, the Namecoin system is not limited to domain names and can 223 store arbitrary data types. Each record must follow the same 224 rules (expiry time, data size limits, etc.). The Namecoin's 225 Domain Name Specification [Namecoin-DNS] defines the "d namespace" 226 for use with "BIT" and other unrelated namespaces co-exist on the 227 Namecoin blockchain. 229 The "BIT" domain is special in the following ways: 231 1. Users can use these names as they would other domain names, 232 entering them anywhere that they would otherwise enter a 233 conventional DNS domain name. 235 From the user's perspective, the resolution of .bit names is 236 similar to the normal DNS resolution, and thus should not affect 237 normal usage of most Internet applications. 239 2. Application software SHOULD NOT recognize .bit domains as special 240 and SHOULD treat them as they would other domains. 242 Applications MAY pass requests to the "BIT" pTLD to DNS resolvers 243 and libraries if A/AAAA records are desired. If available, the 244 local resolver can intercept such requests within the respective 245 operating system hooks and return DNS-compatible results. 247 Namecoin-aware applications MAY choose to talk directly to the 248 respective P2P resolver, and use this to access additional record 249 types that are not defined in DNS. 251 3. Name resolution APIs and libraries SHOULD either respond to 252 requests for .bit names by resolving them via the Namecoin 253 protocol, or respond with NXDOMAIN. 255 4. Caching DNS servers SHOULD recognize .bit names as special and 256 SHOULD NOT attempt to resolve them. Instead, caching DNS servers 257 SHOULD generate immediate negative responses for all such 258 queries. 260 Given that .bit users typically have no special privacy 261 expectations, and those names are globally unique, local caching 262 DNS servers MAY choose to treat them as regular domain names, and 263 cache the responses obtained from the Namecoin blockchain. In 264 that case however, NXDOMAIN results SHOULD NOT be cached, as new 265 .bit domains may become active at any time. 267 5. Authoritative DNS servers are not expected to treat .bit domain 268 requests specially. In practice, they MUST answer with NXDOMAIN, 269 as "BIT" is not available via global DNS resolution. 271 6. DNS server operators SHOULD be aware that .bit names are reserved 272 for use with Namecoin, and MUST NOT override their resolution 273 (e.g., to redirect users to another service or error 274 information). 276 7. DNS registries/registrars MUST NOT grant any request to register 277 .bit names. This helps avoid conflicts [SAC45]. These names are 278 defined by the Namecoin protocol specification, and they fall 279 outside the set of names available for allocation by registries/ 280 registrars. 282 5. Security Considerations 284 Specific software performs the resolution of Namecoin Special-Use 285 Domain Names presented in this document; this resolution process 286 happens outside of the scope of DNS. Leakage of requests to such 287 domains to the global operational DNS can cause interception of 288 traffic that might be misused to monitor, censor, or abuse the user's 289 trust, and lead to privacy issues with potentially tragic 290 consequences for the user. 292 This document reserves these Top-Level Domain names to minimize the 293 possibility of confusion, conflict, and especially privacy risks for 294 users. 296 In the introduction of this document, there's a requirement that DNS 297 operators do not override resolution of the Namecoin names. This is 298 a regulatory measure and cannot prevent such malicious abuse in 299 practice. Its purpose is to limit any information leak that would 300 result from incorrectly configured systems, and to avoid that 301 resolvers make unnecessary contact to the DNS Root Zone for such 302 domains. Verisign, Inc., as well as several Internet service 303 providers (ISPs) have notoriously abused their position to override 304 NXDOMAIN responses to their customers in the past 305 [SSAC-NXDOMAIN-Abuse]. For example, if a DNS operator would decide 306 to override NXDOMAIN and send advertising to leaked .onion sites, the 307 information leak to the DNS would extend to the advertising server, 308 with unpredictable consequences. Thus, implementors should be aware 309 that any positive response coming from DNS must be considered with 310 extra care, as it suggests a leak to DNS has been made, contrary to 311 user's privacy expectations. 313 The reality of X.509 Certificate Authorities (CAs) creating 314 misleading certificates for these pTLDs due to ignorance stresses the 315 need to document their special use. X.509 Certificate Authorities 316 MAY create certificates for "BIT", given CSRs signed with the 317 respective private keys corresponding to the respective names. For 318 "BIT", the Certificate Authority SHOULD limit the expiration time of 319 the certificate to match the registration. 321 Because the Namecoin system uses a timeline-based blockchain for name 322 assignment and resolution, it grants query privacy to the users who 323 maintain their own copy of the blockchain (Section 4.4), but the 324 entire zone of a .bit domains is publicly available in the Namecoin 325 blockchain, making enumeration of names within a .bit zone ("zone 326 walking") a trivial attack to conduct. This might be a concern to 327 some domain operators as it exposes their infrastructure to potential 328 adversaries. That concern may be addressed in future versions of 329 Namecoin, but the records already in the blockchain will remain there 330 unprotected. 332 Finally, legacy applications that do not explicitly support the 333 Namecoin pTLD significantly increase the risk of ".bit" queries 334 escaping to DNS, as they are entirely dependent on the correct 335 configuration on the operating system. 337 6. IANA Considerations 339 The Internet Assigned Numbers Authority (IANA) reserved the following 340 entries in the Special-Use Domain Names registry [RFC6761]: 342 .bit 344 [TO REMOVE: the assignement URL is https://www.iana.org/assignments/ 345 special-use-domain-names/ ] 347 7. Acknowledgements 349 The authors thank the I2P and Namecoin developers for their 350 constructive feedback, as well as Mark Nottingham for his proof- 351 reading and valuable feedback. The authors also thank the members of 352 DNSOP WG for their critiques and suggestions. 354 8. References 356 8.1. Normative References 358 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 359 STD 13, RFC 1034, November 1987. 361 [RFC1035] Mockapetris, P., "Domain names - implementation and 362 specification", STD 13, RFC 1035, November 1987. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 368 NCACHE)", RFC 2308, March 1998. 370 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 371 RFC 6761, February 2013. 373 8.2. Informative References 375 [Namecoin] 376 The .bit Project, "Namecoin", 2013, 377 . 379 [Namecoin-DNS] 380 The .bit Project, "Namecoin Domain Name Specification", 381 2015, . 383 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 384 Top Level Domain Queries at the Root Level of the Domain 385 Name System", November 2010, 386 . 389 [SquareZooko] 390 Swartz, A., "Squaring the Triangle: Secure, Decentralized, 391 Human-Readable Names", 2011, 392 . 394 [SSAC-NXDOMAIN-Abuse] 395 ICANN Security and Stability Advisory Committee, 396 "Redirection in the COM and NET Domains", July 2004, 397 . 400 Authors' Addresses 402 Christian Grothoff 403 INRIA 404 Equipe Decentralisee 405 INRIA Rennes Bretagne Atlantique 406 263 avenue du General Leclerc 407 Campus Universitaire de Beaulieu 408 Rennes, Bretagne F-35042 409 FR 411 Email: christian@grothoff.org 412 Matthias Wachs 413 Technische Universitaet Muenchen 414 Free Secure Network Systems Group 415 Lehrstuhl fuer Netzarchitekturen und Netzdienste 416 Boltzmannstrasse 3 417 Technische Universitaet Muenchen 418 Garching bei Muenchen, Bayern D-85748 419 DE 421 Email: wachs@net.in.tum.de 423 Hellekin O. Wolf (editor) 424 GNU consensus 426 Email: hellekin@gnu.org 428 Jacob Appelbaum 429 Tor Project Inc. 431 Email: jacob@appelbaum.net 433 Leif Ryge 434 Tor Project Inc. 436 Email: leif@synthesize.us