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