Internet-Draft The GNU Name System July 2019
Schanzenbach, et al. Expires 24 January 2020 [Page]
Workgroup:
Independent Stream
Internet-Draft:
draft-schanzen-gns-00
Published:
Intended Status:
Informational
Expires:
Authors:
M. Schanzenbach
GNUnet e.V.
C. Grothhoff
GNUnet e.V.
B. Fix
GNUnet e.V.

The GNU Name System Specification

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.

▲

Table of Contents

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

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.

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

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

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 

        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:

          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 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":

          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:

          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

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

      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
      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, , <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035]
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8032>.

Authors' Addresses

Martin Schanzenbach
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany
Christian Grothoff
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany
Bernd Fix
GNUnet e.V.
Boltzmannstrasse 3
85748 Garching
Germany