Internet DRAFT - draft-grothoff-iesg-special-use-p2p-gns

draft-grothoff-iesg-special-use-p2p-gns







Internet Engineering Task Force                              C. Grothoff
Internet-Draft                                                     INRIA
Intended status: Informational                                  M. Wachs
Expires: December 24, 2015              Technische Universitaet Muenchen
                                                            H. Wolf, Ed.
                                                           GNU consensus
                                                            J. Appelbaum
                                                                 L. Ryge
                                                        Tor Project Inc.
                                                           June 30, 2015


            Special-Use Domain Names of the GNU Name System
               draft-grothoff-iesg-special-use-p2p-gns-00

Abstract

   This document registers a set of Special-Use Domain Names for use
   with Peer-to-Peer (P2P) systems, as per RFC6761.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 24, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Grothoff, et al.        Expires December 24, 2015               [Page 1]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology and Conventions Used in This Document . . . . . .   3
   4.  Description of Special-Use Domains in P2P Networks  . . . . .   4
     4.1.  The "GNU" Relative pTLD . . . . . . . . . . . . . . . . .   4
     4.2.  The "ZKEY" Compressed Public Key pTLD . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   The GNU Name System (GNS) uses "GNU" and "ZKEY" to realize privacy-
   enhanced, fully-decentralized and censorship-resistant naming.

   In order to avoid interoperability issues with DNS as well as to
   address security and privacy concerns, this document registers a set
   of Special-Use Domain Names for use with P2P systems (pTLDs), as per
   [RFC6761],: "GNU" and "ZKEY".

2.  Applicability

   [RFC6761] Section 3 states:

      "[I]f a domain name has special properties that affect the way
      hardware and software implementations handle the name, that apply
      universally regardless of what network the implementation may be
      connected to, then that domain name may be a candidate for having
      the IETF declare it to be a Special-Use Domain Name and specify
      what special treatment implementations should give to that name.
      On the other hand, if declaring a given name to be special would
      result in no change to any implementations, then that suggests
      that the name may not be special in any material way, and it may
      be more appropriate to use the existing DNS mechanisms [RFC1034]
      to provide the desired delegation, data, or lack-of-data, for the
      name in question.  Where the desired behaviour can be achieved via
      the existing domain name registration processes, that process
      should be used.  Reservation of a Special-Use Domain Name is not a



Grothoff, et al.        Expires December 24, 2015               [Page 2]

Internet-Draft         Special-Use GNU Namesystem              June 2015


      mechanism for circumventing normal domain name registration
      processes."

   The set of Special-Use Domain Names for the GNU Name System (pTLDs)
   reserved by this document meet this requirement, as they share the
   following specificities:

   o  pTLDs are not manageable by some designated administration.
      Instead, they are managed according to various alternate
      strategies or combinations thereof, introduced in this document,
      and their respective protocol specifications: automated
      cryptographic assignment (".zkey"), or user-controled assignment
      in a private scope (".gnu").

   o  The pTLDs do not depend on the DNS context for their resolution:
      GNS resolution MAY involve the DNS server infrastructure, as it
      returns DNS-compatible results; however, a specific P2P protocol
      is used for regular name resolution, covered by its respective
      protocol specification.

   o  GNS name resolution is typically integrated with existing software
      libraries and APIs to extend regular DNS operation and enable more
      secure name resolution.  GNS implementations MUST intercept
      queries for the respective pTLDs to ensure GNS names cannot leak
      into the DNS from properly configured systems.  Nevertheless, in
      case GNS names do leak into the DNS, the default hierarchical DNS
      response to any request to any pTLD MUST be NXDOMAIN.

   o  Finally, in order to facilitate the GNU Name System's vision of a
      censorship-resistant, fully-decentralized name system, and provide
      security and privacy features matching user expectations, this
      document specifies desirable changes in existing DNS software and
      DNS operations.

3.  Terminology and Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The word "peer" is used in the meaning of a individual system on the
   network.

   The abbreviation "pTLD" is used in this document to mean a pseudo
   Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
   reserved to the GNU Name System in this document.  A pTLD is
   mentioned in capitals, and within double quotes to mark the
   difference with a regular DNS gTLD.



Grothoff, et al.        Expires December 24, 2015               [Page 3]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   In this document, ".tld" (lowercase, with quotes) means: any domain
   or hostname within the scope of a given pTLD, while .tld (lowercase,
   without quotes) refers to an adjective form.  For example, a
   collection of ".gnu" peers in "GNU", but an .gnu URL.  [TO REMOVE: in
   the IANA Considerations section, we use the simple .tld format to
   request TLD reservation for consistency with previous RFCs].

   The word "NXDOMAIN" refers to an alternate expression for the "Name
   Error" RCODE as described in section 4.1.1 of [RFC1035].  When
   referring to "NXDOMAIN" and negative caching [RFC2308] response, this
   document means an authoritative (AA=1) name error (RCODE=3) response
   exclusively.

4.  Description of Special-Use Domains in P2P Networks

4.1.  The "GNU" Relative pTLD

   "GNU" is used to specify that a domain name should be resolved using
   GNS.  The GNS resolution process is documented in [Wachs2014].

   The "GNU" domain is special in the following ways:

   1.  Users can use these names as they would other domain names,
       entering them anywhere that they would otherwise enter a
       conventional DNS domain name.

       Since there is no central authority responsible for assigning
       .gnu names, and that specific domain is local to the local peer,
       users need to be aware of that specificity.

       Legacy applications MAY expect the DNS-to-GNS proxy to return DNS
       compatible results for the resolution of .gnu domains.



   2.  Legacy application software does not need to recognize .gnu
       domains as special, and may continue to use these names as they
       would other domain names.

       GNS-aware applications MAY also use GNS resolvers directly to
       resolve .gnu domains (in particular, if they want access to GNS-
       specific record types).



   3.  Name resolution APIs and libraries SHOULD either respond to
       requests for .gnu names by resolving them via the GNS protocol,
       or respond with NXDOMAIN.



Grothoff, et al.        Expires December 24, 2015               [Page 4]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   4.  Caching DNS servers SHOULD recognize .gnu names as special and
       SHOULD NOT attempt to look up NS records for them, or otherwise
       query authoritative DNS servers in an attempt to resolve .gnu
       names.  Instead, caching DNS servers SHOULD generate immediate
       negative responses for all such queries.



   5.  Authoritative DNS servers are not expected to treat .gnu domain
       requests specially.  In practice, they MUST answer with NXDOMAIN,
       as "GNU" is not available via global DNS resolution, and not
       doing so can put users' privacy at risk (see item 6).



   6.  DNS server operators SHOULD be aware that .gnu names are reserved
       for use with GNS, and MUST NOT override their resolution (e.g.,
       to redirect users to another service or error information).



   7.  DNS registries/registrars MUST NOT grant any request to register
       .gnu names.  This helps avoid conflicts [SAC45].  These names are
       defined by the GNS protocol specification, and they fall outside
       the set of names available for allocation by registries/
       registrars.



4.2.  The "ZKEY" Compressed Public Key pTLD

   The "ZKEY" pTLD is used to signify that resolution of the given name
   MUST be performed using a record signed by an authority that is in
   possession of a particular public key.  Names in "ZKEY" MUST end with
   a domain which is the compressed point representation from [EdDSA] on
   [Curve25519] of the public key of the authority, encoded using
   Crockford's variant of base32hex [RFC4648] (with additionally 'U'
   being considered equal to 'V') for easier optical character
   recognition.  A GNS resolver uses the key to locate a record signed
   by the respective authority.

   "ZKEY" provides a (reverse) mapping from globally unique hashes to
   public key, therefore .zkey names are non-memorable, and are expected
   to be hidden from the user [Wachs2014].

   The "ZKEY" domain is special in the following ways:





Grothoff, et al.        Expires December 24, 2015               [Page 5]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   1.  Users can use these names as they would other domain names,
       entering them anywhere that they would otherwise enter a
       conventional DNS domain name.

       Since there is no central authority necessary or possible for
       assigning .zkey names, and those names match cryptographic keys,
       users need to be aware that they do not belong to regular DNS,
       but are still global in their scope.

       Legacy applications MAY expect the DNS-to-GNS proxy to return
       DNS-compatible results for the resolution of .zkey domains.



   2.  Application software does not need to recognize .zkey domains as
       special, and may continue to use these names as they would other
       domain names.

       GNS-aware applications MAY also use GNS resolvers directly to
       resolve .zkey domains



   3.  Name resolution APIs and libraries SHOULD either respond to
       requests for .zkey names by resolving them via the GNS protocol,
       or respond with NXDOMAIN.



   4.  Caching DNS servers SHOULD recognize .zkey names as special and
       SHOULD NOT attempt to look up NS records for them, or otherwise
       query authoritative DNS servers in an attempt to resolve .zkey
       names.  Instead, caching DNS servers SHOULD generate immediate
       negative responses for all such queries.



   5.  Authoritative DNS Servers are not expected to treat .zkey domain
       requests specially.  In practice, they MUST answer with NXDOMAIN,
       as "ZKEY" is not available via global DNS resolution, and not
       doing so MAY put users' privacy at risk (see item 6).



   6.  DNS server operators SHOULD be aware that .zkey names are
       reserved for use with GNS, and MUST NOT override their resolution
       (e.g., to redirect users to another service or error
       information).



Grothoff, et al.        Expires December 24, 2015               [Page 6]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   7.  DNS registries/registrars MUST NOT grant any request to register
       .zkey names.  This helps avoid conflicts [SAC45].  These names
       are defined as described above, and they fall outside the set of
       names available for allocation by registries/registrars.



5.  Security Considerations

   Specific software performs the resolution of names in the GNU Name
   System; this resolution process happens outside of the scope of DNS.
   Leakage of requests to such domains to the global operational DNS can
   cause interception of traffic that might be misused to monitor,
   censor, or abuse the user's trust, and lead to privacy issues with
   potentially tragic consequences for the user.

   This document reserves these Top-Level Domain names to minimize the
   possibility of confusion, conflict, and especially privacy risks for
   users.

   In the introduction of this document, there's a requirement that DNS
   operators do not override resolution of the GNS names.  This is a
   regulatory measure and cannot prevent such malicious abuse in
   practice.  Its purpose is to limit any information leak that would
   result from incorrectly configured systems, and to avoid that
   resolvers make unnecessary contact to the DNS Root Zone for such
   domains.  Verisign, Inc., as well as several Internet service
   providers (ISPs) have notoriously abused their position to override
   NXDOMAIN responses to their customers in the past
   [SSAC-NXDOMAIN-Abuse].  For example, if a DNS operator would decide
   to override NXDOMAIN and send advertising to leaked .zkey sites, the
   information leak to the DNS would extend to the advertising server,
   with unpredictable consequences.  Thus, implementors should be aware
   that any positive response coming from DNS must be considered with
   extra care, as it suggests a leak to DNS has been made, contrary to
   user's privacy expectations.

   The reality of X.509 Certificate Authorities (CAs) creating
   misleading certificates for these pTLDs due to ignorance stresses the
   need to document their special use.  X.509 Certificate Authorities
   MAY create certificates for "ZKEY" given CSRs signed with the
   respective private keys corresponding to the respective names.
   Certificate Authorities MUST NOT create certificates for "GNU" Top-
   Level domains.  Nevertheless, clients SHOULD accept certificates for
   "GNU" Top-Level domains as they may be created legitimately by local
   proxies on the fly.





Grothoff, et al.        Expires December 24, 2015               [Page 7]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   Finally, legacy applications that do not explicitly support the pTLDs
   significantly increase the risk of pTLD queries escaping to DNS, as
   they are entirely dependent on the correct configuration on the
   operating system.

6.  IANA Considerations

   The Internet Assigned Numbers Authority (IANA) reserved the following
   entries in the Special-Use Domain Names registry [RFC6761]:

      .gnu

      .zkey

   [TO REMOVE: the assignement URL is https://www.iana.org/assignments/
   special-use-domain-names/ ]

7.  Acknowledgements

   The authors thank the I2P and Namecoin developers for their
   constructive feedback, as well as Mark Nottingham for his proof-
   reading and valuable feedback.  The authors also thank the members of
   DNSOP WG for their critiques and suggestions.

8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, March 1998.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, February 2013.

8.2.  Informative References







Grothoff, et al.        Expires December 24, 2015               [Page 8]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   [Curve25519]
              Bernstein, D., "Curve25519: new Diffie-Hellman speed
              record", February 2006,
              <http://cr.yp.to/ecdh/curve25519-20060209.pdf>.

   [EdDSA]    Bernstein, D., Duif, N., Lange, T., Schwabe, P., and Y.
              Yang, "High-speed, high-security signatures", September
              2011, <http://ed25519.cr.yp.to/ed25519-20110926.pdf>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [SAC45]    ICANN Security and Stability Advisory Committee, "Invalid
              Top Level Domain Queries at the Root Level of the Domain
              Name System", November 2010,
              <http://www.icann.org/en/groups/ssac/documents/
              sac-045-en.pdf>.

   [SSAC-NXDOMAIN-Abuse]
              ICANN Security and Stability Advisory Committee,
              "Redirection in the COM and NET Domains", July 2004,
              <http://www.icann.org/committees/security/
              ssac-report-09jul04.pdf>.

   [Wachs2014]
              Wachs, M., Schanzenbach, M., and C. Grothoff, "A
              Censorship-Resistant, Privacy-Enhancing and Fully
              Decentralized Name System", October 2014,
              <https://gnunet.org/gns-paper>.

Authors' Addresses

   Christian Grothoff
   INRIA
   Equipe Decentralisee
   INRIA Rennes Bretagne Atlantique
   263 avenue du General Leclerc
   Campus Universitaire de Beaulieu
   Rennes, Bretagne  F-35042
   FR

   Email: christian@grothoff.org









Grothoff, et al.        Expires December 24, 2015               [Page 9]

Internet-Draft         Special-Use GNU Namesystem              June 2015


   Matthias Wachs
   Technische Universitaet Muenchen
   Free Secure Network Systems Group
   Lehrstuhl fuer Netzarchitekturen und Netzdienste
   Boltzmannstrasse 3
   Technische Universitaet Muenchen
   Garching bei Muenchen, Bayern  D-85748
   DE

   Email: wachs@net.in.tum.de


   Hellekin O. Wolf (editor)
   GNU consensus

   Email: hellekin@gnu.org


   Jacob Appelbaum
   Tor Project Inc.

   Email: jacob@appelbaum.net


   Leif Ryge
   Tor Project Inc.

   Email: leif@synthesize.us























Grothoff, et al.        Expires December 24, 2015              [Page 10]