idnits 2.17.1 draft-grothoff-iesg-special-use-p2p-gns-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 3215 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 Names of the GNU Name System 14 draft-grothoff-iesg-special-use-p2p-gns-00 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 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. Description of Special-Use Domains in P2P Networks . . . . . 4 59 4.1. The "GNU" Relative pTLD . . . . . . . . . . . . . . . . . 4 60 4.2. The "ZKEY" Compressed Public Key pTLD . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 8.2. Informative References . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 The GNU Name System (GNS) uses "GNU" and "ZKEY" to realize privacy- 72 enhanced, fully-decentralized and censorship-resistant naming. 74 In order to avoid interoperability issues with DNS as well as to 75 address security and privacy concerns, this document registers a set 76 of Special-Use Domain Names for use with P2P systems (pTLDs), as per 77 [RFC6761],: "GNU" and "ZKEY". 79 2. Applicability 81 [RFC6761] Section 3 states: 83 "[I]f a domain name has special properties that affect the way 84 hardware and software implementations handle the name, that apply 85 universally regardless of what network the implementation may be 86 connected to, then that domain name may be a candidate for having 87 the IETF declare it to be a Special-Use Domain Name and specify 88 what special treatment implementations should give to that name. 89 On the other hand, if declaring a given name to be special would 90 result in no change to any implementations, then that suggests 91 that the name may not be special in any material way, and it may 92 be more appropriate to use the existing DNS mechanisms [RFC1034] 93 to provide the desired delegation, data, or lack-of-data, for the 94 name in question. Where the desired behaviour can be achieved via 95 the existing domain name registration processes, that process 96 should be used. Reservation of a Special-Use Domain Name is not a 97 mechanism for circumventing normal domain name registration 98 processes." 100 The set of Special-Use Domain Names for the GNU Name System (pTLDs) 101 reserved by this document meet this requirement, as they share the 102 following specificities: 104 o pTLDs are not manageable by some designated administration. 105 Instead, they are managed according to various alternate 106 strategies or combinations thereof, introduced in this document, 107 and their respective protocol specifications: automated 108 cryptographic assignment (".zkey"), or user-controled assignment 109 in a private scope (".gnu"). 111 o The pTLDs do not depend on the DNS context for their resolution: 112 GNS resolution MAY involve the DNS server infrastructure, as it 113 returns DNS-compatible results; however, a specific P2P protocol 114 is used for regular name resolution, covered by its respective 115 protocol specification. 117 o GNS name resolution is typically integrated with existing software 118 libraries and APIs to extend regular DNS operation and enable more 119 secure name resolution. GNS implementations MUST intercept 120 queries for the respective pTLDs to ensure GNS names cannot leak 121 into the DNS from properly configured systems. Nevertheless, in 122 case GNS names do leak into the DNS, the default hierarchical DNS 123 response to any request to any pTLD MUST be NXDOMAIN. 125 o Finally, in order to facilitate the GNU Name System's vision of a 126 censorship-resistant, fully-decentralized name system, and provide 127 security and privacy features matching user expectations, this 128 document specifies desirable changes in existing DNS software and 129 DNS operations. 131 3. Terminology and Conventions Used in This Document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 The word "peer" is used in the meaning of a individual system on the 138 network. 140 The abbreviation "pTLD" is used in this document to mean a pseudo 141 Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] 142 reserved to the GNU Name System in this document. A pTLD is 143 mentioned in capitals, and within double quotes to mark the 144 difference with a regular DNS gTLD. 146 In this document, ".tld" (lowercase, with quotes) means: any domain 147 or hostname within the scope of a given pTLD, while .tld (lowercase, 148 without quotes) refers to an adjective form. For example, a 149 collection of ".gnu" peers in "GNU", but an .gnu URL. [TO REMOVE: in 150 the IANA Considerations section, we use the simple .tld format to 151 request TLD reservation for consistency with previous RFCs]. 153 The word "NXDOMAIN" refers to an alternate expression for the "Name 154 Error" RCODE as described in section 4.1.1 of [RFC1035]. When 155 referring to "NXDOMAIN" and negative caching [RFC2308] response, this 156 document means an authoritative (AA=1) name error (RCODE=3) response 157 exclusively. 159 4. Description of Special-Use Domains in P2P Networks 161 4.1. The "GNU" Relative pTLD 163 "GNU" is used to specify that a domain name should be resolved using 164 GNS. The GNS resolution process is documented in [Wachs2014]. 166 The "GNU" domain is special in the following ways: 168 1. Users can use these names as they would other domain names, 169 entering them anywhere that they would otherwise enter a 170 conventional DNS domain name. 172 Since there is no central authority responsible for assigning 173 .gnu names, and that specific domain is local to the local peer, 174 users need to be aware of that specificity. 176 Legacy applications MAY expect the DNS-to-GNS proxy to return DNS 177 compatible results for the resolution of .gnu domains. 179 2. Legacy application software does not need to recognize .gnu 180 domains as special, and may continue to use these names as they 181 would other domain names. 183 GNS-aware applications MAY also use GNS resolvers directly to 184 resolve .gnu domains (in particular, if they want access to GNS- 185 specific record types). 187 3. Name resolution APIs and libraries SHOULD either respond to 188 requests for .gnu names by resolving them via the GNS protocol, 189 or respond with NXDOMAIN. 191 4. Caching DNS servers SHOULD recognize .gnu names as special and 192 SHOULD NOT attempt to look up NS records for them, or otherwise 193 query authoritative DNS servers in an attempt to resolve .gnu 194 names. Instead, caching DNS servers SHOULD generate immediate 195 negative responses for all such queries. 197 5. Authoritative DNS servers are not expected to treat .gnu domain 198 requests specially. In practice, they MUST answer with NXDOMAIN, 199 as "GNU" is not available via global DNS resolution, and not 200 doing so can put users' privacy at risk (see item 6). 202 6. DNS server operators SHOULD be aware that .gnu names are reserved 203 for use with GNS, and MUST NOT override their resolution (e.g., 204 to redirect users to another service or error information). 206 7. DNS registries/registrars MUST NOT grant any request to register 207 .gnu names. This helps avoid conflicts [SAC45]. These names are 208 defined by the GNS protocol specification, and they fall outside 209 the set of names available for allocation by registries/ 210 registrars. 212 4.2. The "ZKEY" Compressed Public Key pTLD 214 The "ZKEY" pTLD is used to signify that resolution of the given name 215 MUST be performed using a record signed by an authority that is in 216 possession of a particular public key. Names in "ZKEY" MUST end with 217 a domain which is the compressed point representation from [EdDSA] on 218 [Curve25519] of the public key of the authority, encoded using 219 Crockford's variant of base32hex [RFC4648] (with additionally 'U' 220 being considered equal to 'V') for easier optical character 221 recognition. A GNS resolver uses the key to locate a record signed 222 by the respective authority. 224 "ZKEY" provides a (reverse) mapping from globally unique hashes to 225 public key, therefore .zkey names are non-memorable, and are expected 226 to be hidden from the user [Wachs2014]. 228 The "ZKEY" domain is special in the following ways: 230 1. Users can use these names as they would other domain names, 231 entering them anywhere that they would otherwise enter a 232 conventional DNS domain name. 234 Since there is no central authority necessary or possible for 235 assigning .zkey names, and those names match cryptographic keys, 236 users need to be aware that they do not belong to regular DNS, 237 but are still global in their scope. 239 Legacy applications MAY expect the DNS-to-GNS proxy to return 240 DNS-compatible results for the resolution of .zkey domains. 242 2. Application software does not need to recognize .zkey domains as 243 special, and may continue to use these names as they would other 244 domain names. 246 GNS-aware applications MAY also use GNS resolvers directly to 247 resolve .zkey domains 249 3. Name resolution APIs and libraries SHOULD either respond to 250 requests for .zkey names by resolving them via the GNS protocol, 251 or respond with NXDOMAIN. 253 4. Caching DNS servers SHOULD recognize .zkey names as special and 254 SHOULD NOT attempt to look up NS records for them, or otherwise 255 query authoritative DNS servers in an attempt to resolve .zkey 256 names. Instead, caching DNS servers SHOULD generate immediate 257 negative responses for all such queries. 259 5. Authoritative DNS Servers are not expected to treat .zkey domain 260 requests specially. In practice, they MUST answer with NXDOMAIN, 261 as "ZKEY" is not available via global DNS resolution, and not 262 doing so MAY put users' privacy at risk (see item 6). 264 6. DNS server operators SHOULD be aware that .zkey names are 265 reserved for use with GNS, and MUST NOT override their resolution 266 (e.g., to redirect users to another service or error 267 information). 269 7. DNS registries/registrars MUST NOT grant any request to register 270 .zkey names. This helps avoid conflicts [SAC45]. These names 271 are defined as described above, and they fall outside the set of 272 names available for allocation by registries/registrars. 274 5. Security Considerations 276 Specific software performs the resolution of names in the GNU Name 277 System; this resolution process happens outside of the scope of DNS. 278 Leakage of requests to such domains to the global operational DNS can 279 cause interception of traffic that might be misused to monitor, 280 censor, or abuse the user's trust, and lead to privacy issues with 281 potentially tragic consequences for the user. 283 This document reserves these Top-Level Domain names to minimize the 284 possibility of confusion, conflict, and especially privacy risks for 285 users. 287 In the introduction of this document, there's a requirement that DNS 288 operators do not override resolution of the GNS names. This is a 289 regulatory measure and cannot prevent such malicious abuse in 290 practice. Its purpose is to limit any information leak that would 291 result from incorrectly configured systems, and to avoid that 292 resolvers make unnecessary contact to the DNS Root Zone for such 293 domains. Verisign, Inc., as well as several Internet service 294 providers (ISPs) have notoriously abused their position to override 295 NXDOMAIN responses to their customers in the past 296 [SSAC-NXDOMAIN-Abuse]. For example, if a DNS operator would decide 297 to override NXDOMAIN and send advertising to leaked .zkey sites, the 298 information leak to the DNS would extend to the advertising server, 299 with unpredictable consequences. Thus, implementors should be aware 300 that any positive response coming from DNS must be considered with 301 extra care, as it suggests a leak to DNS has been made, contrary to 302 user's privacy expectations. 304 The reality of X.509 Certificate Authorities (CAs) creating 305 misleading certificates for these pTLDs due to ignorance stresses the 306 need to document their special use. X.509 Certificate Authorities 307 MAY create certificates for "ZKEY" given CSRs signed with the 308 respective private keys corresponding to the respective names. 309 Certificate Authorities MUST NOT create certificates for "GNU" Top- 310 Level domains. Nevertheless, clients SHOULD accept certificates for 311 "GNU" Top-Level domains as they may be created legitimately by local 312 proxies on the fly. 314 Finally, legacy applications that do not explicitly support the pTLDs 315 significantly increase the risk of pTLD queries escaping to DNS, as 316 they are entirely dependent on the correct configuration on the 317 operating system. 319 6. IANA Considerations 321 The Internet Assigned Numbers Authority (IANA) reserved the following 322 entries in the Special-Use Domain Names registry [RFC6761]: 324 .gnu 326 .zkey 328 [TO REMOVE: the assignement URL is https://www.iana.org/assignments/ 329 special-use-domain-names/ ] 331 7. Acknowledgements 333 The authors thank the I2P and Namecoin developers for their 334 constructive feedback, as well as Mark Nottingham for his proof- 335 reading and valuable feedback. The authors also thank the members of 336 DNSOP WG for their critiques and suggestions. 338 8. References 340 8.1. Normative References 342 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 343 STD 13, RFC 1034, November 1987. 345 [RFC1035] Mockapetris, P., "Domain names - implementation and 346 specification", STD 13, RFC 1035, November 1987. 348 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 349 Requirement Levels", BCP 14, RFC 2119, March 1997. 351 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 352 NCACHE)", RFC 2308, March 1998. 354 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 355 RFC 6761, February 2013. 357 8.2. Informative References 359 [Curve25519] 360 Bernstein, D., "Curve25519: new Diffie-Hellman speed 361 record", February 2006, 362 . 364 [EdDSA] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and Y. 365 Yang, "High-speed, high-security signatures", September 366 2011, . 368 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 369 Encodings", RFC 4648, October 2006. 371 [SAC45] ICANN Security and Stability Advisory Committee, "Invalid 372 Top Level Domain Queries at the Root Level of the Domain 373 Name System", November 2010, 374 . 377 [SSAC-NXDOMAIN-Abuse] 378 ICANN Security and Stability Advisory Committee, 379 "Redirection in the COM and NET Domains", July 2004, 380 . 383 [Wachs2014] 384 Wachs, M., Schanzenbach, M., and C. Grothoff, "A 385 Censorship-Resistant, Privacy-Enhancing and Fully 386 Decentralized Name System", October 2014, 387 . 389 Authors' Addresses 391 Christian Grothoff 392 INRIA 393 Equipe Decentralisee 394 INRIA Rennes Bretagne Atlantique 395 263 avenue du General Leclerc 396 Campus Universitaire de Beaulieu 397 Rennes, Bretagne F-35042 398 FR 400 Email: christian@grothoff.org 401 Matthias Wachs 402 Technische Universitaet Muenchen 403 Free Secure Network Systems Group 404 Lehrstuhl fuer Netzarchitekturen und Netzdienste 405 Boltzmannstrasse 3 406 Technische Universitaet Muenchen 407 Garching bei Muenchen, Bayern D-85748 408 DE 410 Email: wachs@net.in.tum.de 412 Hellekin O. Wolf (editor) 413 GNU consensus 415 Email: hellekin@gnu.org 417 Jacob Appelbaum 418 Tor Project Inc. 420 Email: jacob@appelbaum.net 422 Leif Ryge 423 Tor Project Inc. 425 Email: leif@synthesize.us