path: root/draft-schanzen-gns.txt

Independent Stream                                       M. Schanzenbach
Internet-Draft                                              C. Grothhoff
Intended status: Informational                                    B. Fix
Expires: 24 January 2020                                     GNUnet e.V.
                                                            23 July 2019


                   The GNU Name System Specification
                         draft-schanzen-gns-00

Abstract

   This document contains the GNU Name System (GNS) technical
   specification.

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 https://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 24 January 2020.

Copyright Notice

   Copyright (c) 2019 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 (https://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 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.






Schanzenbach, et al.     Expires 24 January 2020                [Page 1]

Internet-Draft             The GNU Name System                 July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Resource records  . . . . . . . . . . . . . . . . . . . . . .   2
     3.1.  Wire format . . . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  PKEY  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  GNS2DNS . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  LEHO  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.5.  BOX . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Publishing records  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Key derivations . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Resource records block  . . . . . . . . . . . . . . . . .   7
     4.3.  Block data encryption and decryption  . . . . . . . . . .   9
   5.  Internationalization and Character Encoding . . . . . . . . .  11
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Record Resolution . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Namespace Revocation  . . . . . . . . . . . . . . . . . . . .  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   10. Test Vectors  . . . . . . . . . . . . . . . . . . . . . . . .  12
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   This document contains the GNU Name System (GNS) technical
   specification for secure, censorship-resistant and decentralised name
   resolution.

   This document defines the normative wire format of resource records,
   resolution processes, cryptographic routines and security
   considerations for use by implementors.


2.  Zones

   A zone in GNS is defined by a public/private ECC key pair (d,zk),
   where B is the generator of a group or subgroup, d is the private key
   and zk the corresponding public key GNS uses the Ed25519 EC
   parameters as defined in [RFC8032].  GNS combines the EC parameters
   of Ed25519 with the ECDSA scheme defined in [RFC6979] in order to
   achieve zone privacy.  The public key "zk" is used to uniquely
   identify and refer to the zone and is thus called "zone key".
   Records published in the zone are signed using a private key derived
   from "d" as described in Section 4.

3.  Resource records




Schanzenbach, et al.     Expires 24 January 2020                [Page 2]

Internet-Draft             The GNU Name System                 July 2019


3.1.  Wire format

   A GNS resource record holds the data of a specific record in a zone.
   The resource record format is defined as follows:

        0     8     16    24    32    40    48    56
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                   EXPIRATION                  |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |       DATA SIZE       |          TYPE         |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |           FLAGS       |        DATA           /
        +-----+-----+-----+-----+                       /
        /                                               /
        /                       +-----+-----+-----+-----+
        /                       |      PADDING          /
        +-----+-----+-----+-----+                       /
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 1

   where:

   EXPIRATION  Denotes the absolute expiration date of the record.  In
      microseconds since midnight (0 hour), January 1, 1970 in network
      byte order.

   DATA SIZE  The size of the DATA field in bytes and in network byte
      order including padding.  The padding MUST ensure that the size of
      the resource record is a power of two.  The only excption is the
      PKEY record type, which is never padded.

   TYPE  The resource record type.  This type can be one of the GNS
      resource records as defined in Section 3 or a DNS record type as
      defined in [RFC1035] or any of the complementary standardized DNS
      resource record types.  This value must be stored in network byte
      order.  Note that values below 2^16 are reserved for allocation
      via IANA ([RFC6895]).

   FLAGS  Resource record flags.

   DATA  The resource record data payload.  The contents are defined by
      the respective type of the resource record.

   PADDING  The padding MUST contain the 0 value in all octets.  Not
      applicable for PKEY records.




Schanzenbach, et al.     Expires 24 January 2020                [Page 3]

Internet-Draft             The GNU Name System                 July 2019


   Flags indicate metadata surrounding the resource record.  A flag
   value of 0 indicates that all flags are unset.  The following
   illustrates the flag distribution in the 32-bit flag value of a
   resource record:

        ... 5       4         3        2        1        0
        ------+--------+--------+--------+--------+--------+
        / ... | SHADOW | EXPREL |   /    | PRIVATE|    /   |
        ------+--------+--------+--------+--------+--------+

                                  Figure 2

   where:

   SHADOW  If this flag is set, this record should not be used unless
      all (other) records with an absolute expiration time have expired.

   EXPREL  The expiration time value of the record is a relative time
      and not an absolute time.  This flag should never be encountered
      by a resolver for records resolved from the DHT.

   PRIVATE  This is a private record of this peer and it should thus not
      be handed out to other peers.  This flag should never be
      encountered by a resolver for records resolved from the DHT.

3.2.  PKEY

   In GNS, a delegation of a label to a zone is represented througha
   PKEY record.  A PKEY resource record contains the public key of the
   zone to delegate to.  A PKEY record MUST be the only record under a
   label.  No other labels are allows.  The a PKEY DATA entry has the
   following format:

         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                   PUBLIC KEY                  |
         |                                               |
         |                                               |
         |                                               |
         +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 3









Schanzenbach, et al.     Expires 24 January 2020                [Page 4]

Internet-Draft             The GNU Name System                 July 2019


3.3.  GNS2DNS

   It is possible to delegate a label back into DNS through a GNS2DNS
   record.  The resource record contains a DNS name for the resolver to
   continue with in DNS followed by a DNS server.  Both names are in the
   format defined in [RFC1034] for DNS names.  If a resolver encounters
   a GNS2DNS record it is expected that it first resolves the IP(s) of
   the DNS servers using DNS.  Then, the encountered DNS name is
   resolved by querying the name server(s).  The a GNS2DNS DATA entry
   has the following format:

         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                    DNS NAME                   |
         /                                               /
         /                                               /
         |                                               |
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                 DNS SERVER NAME               |
         /                                               /
         /                                               /
         |                                               |
         +-----------------------------------------------+

                                  Figure 4

3.4.  LEHO

   As names in GNS are not globally unique, established practices such
   as virtual hosting do not apply directly.  In order to support such
   use cases, GNS support a legacy hostname record which can be used by
   applications (e.g.  HTTP clients) in order to provide the necessary
   information.  The resource record contains a string which is not
   0-terminated representing the legacy hostname to use.  It is expected
   to be found together in a single resource record with an IPv4 or IPv6
   address.  A LEHO DATA entry has the following format:

         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                 LEGACY HOSTNAME               |
         /                                               /
         /                                               /
         |                                               |
         +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 5





Schanzenbach, et al.     Expires 24 January 2020                [Page 5]

Internet-Draft             The GNU Name System                 July 2019


3.5.  BOX

   Record type used to box up SRV and TLSA records.  For example, a TLSA
   record for "_https._tcp.foo.gnu" will be stored under "foo.gnu" as a
   BOX record with service 443 (https) and protocol 6 (tcp) and
   record_type "TLSA".  When a BOX record is received, a GNS resolver
   must unbox it if the name contained "_SERVICE._PROTO", otherwise it
   is left untouched.  This is done to ensure that TLSA (and SRV)
   records do not require a separate network request, thus making TLSA
   records inseparable from the corresponding A/AAAA/VPN/etc. records.
   A BOX DATA entry has the following format:

         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |   PROTO   |    SVC    |       TYPE            |
         +-----------+-----------------------------------+
         |                   RECORD                      |
         /                                               /
         /                                               /
         |                                               |
         +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 6

   PROTO  the protocol number, e.g. 6 for tcp.  In network byte order.

   SVC  the service of the boxed record, i.e. the port number.  In
      network byte order.

   TYPE  Record type of the boxed record.  In network byte order.

   RECORD  The boxed record in a format as defined in Section 3.1.

4.  Publishing records

   GNS resource records are published in a distributed hash table (DHT).
   Resource records are grouped by their respective labels and published
   together in a single block in the DHT.  A resource records block is
   published under a key which is derived from the zone key "zk" and the
   respective label of the contained records.  Given a label, the DHT
   key "q" is derived as follows:

4.1.  Key derivations








Schanzenbach, et al.     Expires 24 January 2020                [Page 6]

Internet-Draft             The GNU Name System                 July 2019


           PRK_h := HKDF-Extract ("key-derivation", zk)
           h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
           d_h := h*d mod p
           zk_h := h*zk mod p
           q := SHA512 (zk_h)

   We use a hash-based key derivation function (HKDF) as defined in
   [RFC5869].  We use HMAC-SHA512 for the extraction phase and HMAC-
   SHA256 for the expansion phase.

   PRK_h  is key material retrieved using an HKDF using the string "key-
      derivation" as salt and the public zone key "x*P" as initial
      keying material.

   h  is the HKDF expansion result.  The expansion info is a
      concatenation of the label and string "gns".

   d  is the private zone key as defined in [RFC8032].

   P  is the base point of the curve Ed25519 as defined in [RFC8032].

   label  under wich the resource records are published.

   d_h  is a private key derived from the zone private key "d" using the
      keying material "h" (512 bit) and "p" is a prime as defined in
      [RFC8032].

   zk_h  is a public key derived from the zone key "zk" using the keying
      material "h" (512 bit) and "p" is the group order as defined in
      [RFC8032].

   q  Is the DHT key under which the resource records block is
      published.  It is the SHA512 hash over the public key "zk_h"
      corresponding to the derived private key "d_h".

4.2.  Resource records block

   GNS records are grouped by their labels and published as a single
   block in the DHT.  The contained resource records are encrypted using
   a symmetric encryption scheme.  A GNS resource records block has the
   following format:










Schanzenbach, et al.     Expires 24 January 2020                [Page 7]

Internet-Draft             The GNU Name System                 July 2019


             0     8     16    24    32    40    48    56
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                   SIGNATURE                   |
             |                                               |
             |                                               |
             |                                               |
             |                                               |
             |                                               |
             |                                               |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                  PUBLIC KEY                   |
             |                                               |
             |                                               |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |         SIZE          |       PURPOSE         |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                   EXPIRATION                  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                    BDATA                      /
             /                                               /
             /                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 7

   where:

   SIGNATURE  A 512-bit ECDSA deterministic signature compliant with
      [RFC6979].  The signature is computed over the data following the
      PUBLIC KEY field.  The signature is created using the derived
      private key "d_h" (see Section 4).

   PUBLIC KEY  The 256-bit ECC public key "zk_h" to be used to verify
      SIGNATURE.  The wire format of this value is defined in [RFC8032],
      Section 5.1.5.

   SIZE  A 32-bit value containing the length of the signed data
      following the PUBLIC KEY field in network byte order.  This value
      always includes the length of the fields SIZE (4), PURPOSE (4) and
      EXPIRATION (8) in addition to the length of the BDATA.

   PURPOSE  A 32-bit signature purpose flag.  This field MUST be 15 (in
      network byte order).

   EXPIRATION  The resource records block expiration time.  This is the
      expiration time of the resource record contained within this block



Schanzenbach, et al.     Expires 24 January 2020                [Page 8]

Internet-Draft             The GNU Name System                 July 2019


      with the smallest expiration time.  If a records block includes
      shadow records, then the *maximum* expiration time of all shadow
      records with matching type and the expiration times of the non-
      shadow records is considered.  This is a 64-bit absolute date in
      microseconds since midnight (0 hour), January 1, 1970 in network
      byte order.

   BDATA  The encrypted resource records with a total size of SIZE - 16.

   We note that even though we use a Ed25519 private key, the public key
   is derived using ECDSA as defined in [RFC8032].  Similarly, the ECDSA
   signature consists of a pair of integers, r and s:

           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                       r                       |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                       s                       |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+

4.3.  Block data encryption and decryption

   A symmetric encryption scheme is used to en-/decrypt the "BDATA"
   field in a GNS record block.  The keys are derived from the record
   label and the zone key "zk".  The validity of "d" can be checked by
   computing "h" from "x_h" and label and verifying that "zk_h = h*zk".
   This step is mandatory to prevent spoofed records to be verified and
   decrypted correctly.  The keying material "K" and initialization
   vector "IV" for the symmetric encryption/decryption are derived as
   follows:

           PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk)
           PRK_iv := HKDF-Extract ("gns-aes-ctx-iv", zk)
           K := HKDF-Expand (PRK_k, label, 512 / 8);
           IV := HKDF-Expand (PRK_iv, label, 256 / 8)

   We use a hash-based key derivation function (HKDF) as defined in
   [RFC5869].  We use HMAC-SHA512 for the extraction phase and HMAC-
   SHA256 for the expansion phase.  The output keying material is 64
   octets (512 bit) for the symmetric keys and 32 octets (256 bit) for
   the initialization vector.  We divide the resulting keying material
   "K" into a 256-bit AES key "Kaes" and a 256-bit TWOFISH key "Ktwo":



Schanzenbach, et al.     Expires 24 January 2020                [Page 9]

Internet-Draft             The GNU Name System                 July 2019


             0     8     16    24    32    40    48    56
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                    AES KEY (Kaes)             |
             |                                               |
             |                                               |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                  TWOFISH KEY (Ktwo)           |
             |                                               |
             |                                               |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 8

   Similarly, we divide "IV" into a 128-bit initialization vector IVaes
   and a 128-bit initialization vector IVtwo:

             0     8     16    24    32    40    48    56
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                    AES IV (IVaes)             |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                  TWOFISH IV (IVtwo)           |
             |                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+

                                  Figure 9

   The symmetric keys and IVs are used for a AES+TWOFISH combined
   cipher.  Both ciphers are used in Cipher FeedBack (CFB) mode.

           RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
           BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))

   The decrypted RDATA has the following format:















Schanzenbach, et al.     Expires 24 January 2020               [Page 10]

Internet-Draft             The GNU Name System                 July 2019


             0     8     16    24    32    40    48    56
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |     RR COUNT          |        EXPIRA-        /
             +-----+-----+-----+-----+-----+-----+-----+-----+
             /         -TION         |       DATA SIZE       |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |         TYPE          |          FLAGS        |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                      DATA                     /
             /                                               /
             /                                               |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |                   EXPIRATION                  |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |       DATA SIZE       |          TYPE         |
             +-----+-----+-----+-----+-----+-----+-----+-----+
             |           FLAGS       |        DATA           /
             +-----+-----+-----+-----+                       /
             /                                               /
             /                                               /
             /                                               /

                                 Figure 10

   where:

   RR COUNT  A 32-bit value containing the number of resource records
      which are following in network byte order.

   is followed by a set of resource records with the respective formats
   defined in Section 3.

5.  Internationalization and Character Encoding

   All labels in GNS are encoded in UTF-8 [RFC3629].  This does not
   include any DNS names found in DNS records, such as CNAME records,
   which are internationalized through the IDNA specifications
   [RFC5890].

6.  Security Considerations

   TODO

7.  Record Resolution

   TODO





Schanzenbach, et al.     Expires 24 January 2020               [Page 11]

Internet-Draft             The GNU Name System                 July 2019


8.  Namespace Revocation

   TODO

9.  IANA Considerations

   This will be fun

10.  Test Vectors

   The following represents a test vector for a record of type MX with a
   priority of 10 and the mail hostname mail.example.com.

         label := "mail"

         d :=
         7ac77c287b9f1971
         1dcb770ae4b5210d
         e84f283b903393f8
         a09db3f347bf7818

         zk (public zone key) :=
         7e5d026d4911f9df
         993e15193dc08508
         ca9e71ea233f214f
         2e080e41dc32fc17

         h :=
         540ef99c5a27f32a
         b96fe70b93f7dbf2
         a68c6f41b1807c5e
         b959b71f8ece50dc
         9b7ec146f5dcdcfe
         53c0552863234f4c
         33dcf484f6e96866
         ee0f2b39276b656d

         d_h :=
         3376c182f461fb01
         f3e009254c1c6177
         bd105c40e4e7b081
         182ed3f702c81700

         zk_h (derived zone key) :=
         e0aa0e6ca514b58c
         dde43ea658517456
         6e325e54b93c8576
         9182810f92fad776



Schanzenbach, et al.     Expires 24 January 2020               [Page 12]

Internet-Draft             The GNU Name System                 July 2019


         q (query key) :=
         81d65adced4dce6f
         3b7e7610339ae2f4
         bae26c271bbc388b
         a320e1f19db4f19b
         6f4168fbdfc9ec20
         df3bad78d89a7211
         d720b62626dbb4d0
         a3663c39e404068e

         AES_KEY :=
         0d157a081ad2efaf
         a502da4e1a745767
         214ba46ba87cdf65
         01af1e07c006813f

         AES_IV :=
         7aad9fbc29b908a8
         7ad7be3234be6b68

         TWOFISH_KEY :=
         f40b1df09d08d0c9
         2873cc2c4bdbc8e4
         d259ae11a8e82534
         79a4d2857274e299

         TWOFISH_IV :=
         f936d2a989e11b07
         d481c2b84b65a3b4

         RDATA :=
         0000000100059412 RR COUNT | EXPIRA-
         09ddea0f00000014  -TION    | DATA SIZE (20)
         0000000f00000000 TYPE (15=MX) | FLAGS (0)
         000a046d61696c07 Priority (10) |4 | mail | 7
         6578616d706c6503 example | 3
         636f6d0000000000 com | \0 | Followed by
         0000000000000000 24 bytes of padding to 2^6
         0000000000000000
         00000000


         BDATA :=
         d99d08fa123da096
         66c2fb9bf020a85d
         e80818d0a84059a8
         5eee901a66459e5e
         3d1a10b29a5b8354



Schanzenbach, et al.     Expires 24 January 2020               [Page 13]

Internet-Draft             The GNU Name System                 July 2019


         1b58636781166b9a
         642920eee8e7a65a
         001fd19a6406a721
         713f0a0d

         SIGNATURE :=
         dee65fe070b05c05 r
         dddeb4e5504a69ad
         654f00aedbcbfdb9
         54bba3c5a99bc9af___________
         33ee8046a331e707 s
         b7d2a7edbfe70dae
         541b8b004a856b8c
         469fbaf5394fdf10

         BLOCK :=
         dee65fe070b05c05 SIGNATURE
         dddeb4e5504a69ad
         654f00aedbcbfdb9
         54bba3c5a99bc9af
         33ee8046a331e707
         b7d2a7edbfe70dae
         541b8b004a856b8c
         469fbaf5394fdf10____________
         e0aa0e6ca514b58c zk_h
         dde43ea658517456
         6e325e54b93c8576
         9182810f92fad776____________
         540000000f000000 SIZE (=84) | PURPOSE (=15)
         5be2dd0912940500 EXPIRATION
         d99d08fa123da096 BDATA
         66c2fb9bf020a85d
         e80818d0a84059a8
         5eee901a66459e5e
         3d1a10b29a5b8354
         1b58636781166b9a
         642920eee8e7a65a
         001fd19a6406a721
         713f0a0d

11.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and




Schanzenbach, et al.     Expires 24 January 2020               [Page 14]

Internet-Draft             The GNU Name System                 July 2019


              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC6895]  Eastlake 3rd, D., "Domain Name System (DNS) IANA
              Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
              April 2013, <https://www.rfc-editor.org/info/rfc6895>.

   [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
              Algorithm (DSA) and Elliptic Curve Digital Signature
              Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
              2013, <https://www.rfc-editor.org/info/rfc6979>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

Authors' Addresses

   Martin Schanzenbach
   GNUnet e.V.
   Boltzmannstrasse 3
   85748 Garching
   Germany

   Email: schanzen@gnunet.org


   Christian Grothoff
   GNUnet e.V.
   Boltzmannstrasse 3
   85748 Garching
   Germany




Schanzenbach, et al.     Expires 24 January 2020               [Page 15]

Internet-Draft             The GNU Name System                 July 2019


   Email: schanzen@gnunet.org


   Bernd Fix
   GNUnet e.V.
   Boltzmannstrasse 3
   85748 Garching
   Germany

   Email: schanzen@gnunet.org









































Schanzenbach, et al.     Expires 24 January 2020               [Page 16]