path: root/draft-schanzen-gns.xml

<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-00" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3">
 <!-- xml2rfc v2v3 conversion 2.26.0 -->
 <front>
  <title abbrev="The GNU Name System">
   The GNU Name System Specification
  </title>
  <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-00"/>
  <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach">
   <organization>GNUnet e.V.</organization>
   <address>
    <postal>
     <street>Boltzmannstrasse 3</street>
     <city>Garching</city>
     <code>85748</code>
     <country>DE</country>
    </postal>
    <email>schanzen@gnunet.org</email>
   </address>
  </author>
  <author fullname="Christian Grothoff" initials="C." surname="Grothoff">
   <organization>Berner Fachhochschule</organization>
   <address>
    <postal>
     <street>Hoeheweg 80</street>
     <city>Biel/Bienne</city>
     <code>2501</code>
     <country>CH</country>
    </postal>
    <email>schanzen@gnunet.org</email>
   </address>
  </author>
  <author fullname="Bernd Fix" initials="B." surname="Fix">
   <organization>GNUnet e.V.</organization>
   <address>
    <postal>
     <street>Boltzmannstrasse 3</street>
     <city>Garching</city>
     <code>85748</code>
     <country>DE</country>
    </postal>
    <email>fix@gnunet.org</email>
   </address>
  </author>

  <date day="23" month="July" year="2019"/>
  <!-- Meta-data Declarations -->
  <area>General</area>
  <workgroup>Independent Stream</workgroup>
  <keyword>name systems</keyword>
  <abstract>
   <t>This document contains the GNU Name System (GNS) technical specification.</t>
  </abstract>
 </front>
 <middle>
   <section anchor="introduction" numbered="true" toc="default">
     <name>Introduction</name>
     <t>
       The Domain Name System (DNS) is a unique distributed database and a vital
       service for most Internet applications. While DNS is distributed, it
       relies on centralized, trusted registrars to provide globally unique
       names. As the awareness of the central role DNS plays on the Internet
       rises, various institutions are using their power (including legal means)
       to engage in attacks on the DNS, thus threatening the global availability
       and integrity of information on the Internet.
     </t>
     <t>
       DNS was not designed with security as a goal. This makes it very
       vulnerable, especially to attackers that have the technical capabilities
       of an entire nation state at their disposal.
       This specification describes a censorship-resistant, privacy-preserving
       and decentralized name system: The GNU Name System (GNS). It is designed
       to provide a secure alternative to DNS, especially when censorship or
       manipulation is encountered. GNS can bind names to any kind of
       cryptographically secured token, enabling it to double in some respects as
       even as an alternative to some of today’s Public Key Infrastructures, in
       particular X.509 for the Web.
     </t>
     <t>
       This document contains the GNU Name System (GNS) technical specification
       of the GNU Name System (GNS), a fully decentralized and censorship-resistant
       name system. GNS provides a privacy-enhancing alternative to the Domain
       Name System (DNS). The design of GNS incorporates the capability to
       integrate and coexist with DNS. GNS is based on the principle of a petname
       system and builds on ideas from the Simple Distributed Security
       Infrastructure (SDSI), addressing a central issue with the decentralized
       mapping of secure identifiers to memorable names: namely the impossibility
       of providing a global, secure and memorable mapping without a trusted
       authority. GNS uses the transitivity in the SDSI design to replace the
       trusted root with secure delegation of authority thus making petnames
       useful to other users while operating under a very strong adversary model.
     </t>
     <t>
       This document defines the normative wire format of resource records, resolution processes,
       cryptographic routines and security considerations for use by implementors.
     </t>
     <t>

     </t>
   </section>
   <section anchor="zones" numbered="true" toc="default">
     <name>Zones</name>
     <t>
       A zone in GNS is defined by a public/private ECDSA key pair (d,zk),
       where d is the private key and zk the corresponding public key.
       GNS employs the curve parameters of the twisted edwards representation
       of Curve25519 <xref target="RFC7748" /> (a.k.a. edwards25519)
       with the ECDSA scheme (<xref target="RFC6979" />).
       The deterministic property of ECDSA (as opposed to EdDSA) is required
       in order to achieve zone privacy.
       In the following, we use the following naming convention for our
       cryptographic primitives:
     </t>
     <dl>
       <dt>d</dt>
       <dd>
         is a 256-bit ECDSA private key.
         In GNS, records are signed using a key derived from "d" as described in
         <xref target="publish" />.
       </dd>
       <dt>p</dt>
       <dd>
         is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e.
         2^255 - 19.
       </dd>
       <dt>B</dt>
       <dd>
         is the group generator (X(P),Y(P)) of edwards25519 as defined in
         <xref target="RFC7748" />.
       </dd>
       <dt>L</dt>
       <dd>
         is the prime-order subgroup of edwards25519 in <xref target="RFC7748" />.
       </dd>
       <dt>zk</dt>
       <dd>
         is the ECDSA public key corresponding to d. It is defined in
         <xref target="RFC6979" /> as the curve point d*B where B is the group
         generator of the elliptic curve.
         The public key is used to uniquely identify a GNS zone and is referred to
         as the "zone key".
       </dd>
     </dl>
   </section>
   <section anchor="rrecords" numbered="true" toc="default">
     <name>Resource records</name>
     <t>
       A GNS implementor MUST provide a mechanism to create and manage resource
       records for local zones. A local zone is established by creating a zone
       key pair. Records may be added to each zone, hence a (local) persistency
       mechanism for resource records and zones must be provided.
       This local zone database is used by the GNS resolver implementation
       and to publish record information.
     </t>
     <t>
       A GNS resource record holds the data of a specific record in a zone.
       The resource record format is defined as follows:
     </t>
     <figure anchor="figure_gnsrecord">
       <artwork name="" type="" align="left" alt=""><![CDATA[
         0     8     16    24    32    40    48    56
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |                   EXPIRATION                  |
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |       DATA SIZE       |          TYPE         |
         +-----+-----+-----+-----+-----+-----+-----+-----+
         |           FLAGS       |        DATA           /
         +-----+-----+-----+-----+                       /
         /                                               /
         /                                               /
         ]]></artwork>
       <!--        <postamble>which is a very simple example.</postamble>-->
     </figure>
     <t>where:</t>
     <dl>
       <dt>EXPIRATION</dt>
       <dd>
         denotes the absolute 64-bit expiration date of the record.
         In microseconds since midnight (0 hour), January 1, 1970 in network
         byte order.
       </dd>
       <dt>DATA SIZE</dt>
       <dd>
         denotes the 32-bit size of the DATA field in bytes and in network byte
         order.
       </dd>
       <dt>TYPE</dt>
       <dd>
         is the 32-bit resource record type. This type can be one of the GNS resource
         records as defined in <xref target="rrecords" /> or a DNS record
         type as defined in <xref target="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 (<xref target="RFC6895" />).
       </dd>
       <dt>FLAGS</dt>
       <dd>
         is a 32-bit resource record flags field (see below).
       </dd>
       <dt>DATA</dt>
       <dd>
         the variable-length resource record data payload. The contents are defined
         by the
         respective type of the resource record.
       </dd>
     </dl>
     <t>
       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:</t>
     <figure anchor="figure_flag">
       <artwork name="" type="" align="left" alt=""><![CDATA[
         ... 5       4         3        2        1        0
         ------+--------+--------+--------+--------+--------+
         / ... | SHADOW | EXPREL |   /    | PRIVATE|    /   |
         ------+--------+--------+--------+--------+--------+
         ]]></artwork>
       <!--        <postamble>which is a very simple example.</postamble>-->
     </figure>
     <t>
       where:
     </t>
     <dl>
       <dt>SHADOW</dt>
       <dd>
         If this flag is set, this record should be ignored by resolvers unless all (other)
         records of the same record type have expired.  Used to allow zone publishers to
         facilitate good performance when records change by allowing them to put future
         values of records into the DHT. This way, future values can propagate and may be
         cached before the transition becomes active.
       </dd>
       <dt>EXPREL</dt>
       <dd>
         The expiration time value of the record is a relative time (still in microseconds)
         and not an absolute time. This flag should never be encountered by a resolver
         for records obtained from the DHT, but might be present when a resolver looks up
         private records of a zone hosted locally.
       </dd>
       <dt>PRIVATE</dt>
       <dd>
         This is a private record of this peer and it should thus not be
         published in the DHT.  Thus, this flag should never be encountered by
         a resolver for records obtained from the DHT.
         Private records should still be considered just like
         regular records when resolving labels in local zones.
       </dd>
     </dl>
     <section anchor="gnsrecords_pkey" numbered="true" toc="default">
       <name>PKEY</name>
       <t>In GNS, a delegation of a label to a zone is represented through a 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
         records are allowed. A PKEY DATA entry has the following format:</t>
       <figure anchor="figure_pkeyrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                   PUBLIC KEY                  |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
     </section>
     <section anchor="gnsrecords_gns2dns" numbered="true" toc="default">
       <name>GNS2DNS</name>
       <t>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
         <xref target="RFC1034" /> for DNS names.
         If a resolver encounters a GNS2DNS record it is expected that it first
         resolves the IP(s) of the DNS server(s).  GNS2DNS records MAY contain
         numeric IPv4 or IPv6 addresses, allowing the resolver to skip this step.
         The DNS server names may themselves be names in GNS or DNS.  If the
         DNS server name ends in ".+", the rest of the name is to be interpreted
         relative to the zone of the GNS2DNS record.
         Then, the DNS name from the GNS2DNS record is appended
         to the remainder of the name to be resolved, and
         resolved by querying the name server(s).
         Multiple
         GNS2DNS records may be stored under the same label, in which case the
         resolve MUST try all of them.  However, if multiple GNS2DNS records
         are present, the DNS name MUST be identical for all of them.
         A GNS2DNS DATA entry has the following format:</t>
       <figure anchor="figure_gns2dnsrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    DNS NAME                   |
           /                                               /
           /                                               /
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                 DNS SERVER NAME               |
           /                                               /
           /                                               /
           |                                               |
           +-----------------------------------------------+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
     </section>

     <section anchor="gnsrecords_leho" numbered="true" toc="default">
       <name>LEHO</name>
       <t>Legacy hostname records can be used by applications that are expected
         to supply a DNS name on the application layer. The most common use case
         is HTTP virtual hosting, which as-is would not work with GNS names as
         those may not be globally unique.

         A LEHO resource record contains an UTF-8 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:</t>
       <figure anchor="figure_lehorecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                 LEGACY HOSTNAME               |
           /                                               /
           /                                               /
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         NOTE: If an application uses a LEHO value in an HTTP request header
         (e.g. "Host:" header) it must be converted to a punycode representation
         <xref target="RFC3492" />.
       </t>
     </section>
     <section anchor="gnsrecords_nick" numbered="true" toc="default">
       <name>NICK</name>
       <t>Nickname records can be used by zone administrators to publish an
         indication on what label this zone prefers to be referred to.
         This is a suggestion to other zones what label to use when creating a
         PKEY <xref target="gnsrecords_pkey" /> record containing this zone's
         public zone key.
         A NICK resource record contains an UTF-8 string
         (which is not 0-terminated) representing the preferred label.
         This string may NOT inlcude a ".".
         A NICK DATA entry has the following format:
       </t>
       <figure anchor="figure_nickrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  NICKNAME                     |
           /                                               /
           /                                               /
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
     </section>

     <section anchor="gnsrecords_box" numbered="true" toc="default">
       <name>BOX</name>
       <t>
         In GNS, every "." in a name delegates to another zone, and
         GNS lookups are expected to return all of the required useful
         information in one record set.  This is incompatible with the
         special labels used by DNS for SRV and TLSA records.  Thus, GNS
         defines the BOX record format to box up SRV and TLSA records and
         include them in the record set of the label they are associated
         with.  For example, a
         TLSA record for "_https._tcp.foo.gnu" will be stored in the record set of
         "foo.gnu" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6
         (tcp) and record_type "TLSA".  When a BOX record is received, a GNS resolver
         must unbox it if the name to be resolved continues with "_SERVICE._PROTO",
         otherwise it is to be left untouched.  This way, TLSA (and SRV)
         records do not require a separate network request, and TLSA
         records become inseparable from the corresponding address records.
         A BOX DATA entry has the following format:</t>
       <figure anchor="figure_boxrecord">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |   PROTO   |    SVC    |       TYPE            |
           +-----------+-----------------------------------+
           |                 RECORD DATA                   |
           /                                               /
           /                                               /
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <dl>
         <dt>PROTO</dt>
         <dd>
           the 16-bit protocol number, e.g. 6 for tcp. In network byte order.
         </dd>
         <dt>SVC</dt>
         <dd>
           the 16-bit service value of the boxed record, i.e. the port number.
           In network byte order.
         </dd>
         <dt>TYPE</dt>
         <dd>
           is the 32-bit record type of the boxed record. In network byte order.
         </dd>
         <dt>RECORD DATA</dt>
         <dd>
           is a variable length field containing the "DATA" format of TYPE as
           defined for the respective TYPE in DNS.
         </dd>
       </dl>
     </section>
   </section>

   <section anchor="publish" numbered="true" toc="default">
     <name>Publishing records</name>
     <t>
       GNS resource records are published in a distributed hash table (DHT).
       Resource records are grouped by their respective labels, encrypted and
       published together in a single block in the DHT.
       A resource records block is published under a key "q" which is derived
       from the zone key "zk" and the respective label of the contained records.
     </t>
     <section anchor="blinding" numbered="true" toc="default">
       <name>Key derivations</name>
       <t>
         Given a label, the DHT key "q" is derived as follows:
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         PRK_h := HKDF-Extract ("key-derivation", zk)
         h := HKDF-Expand (PRK_h, label | "gns", 512 / 8)
         d_h := h*d mod L
         zk_h := h*zk mod L
         q := SHA512 (zk_h)
         ]]></artwork>
       <t>
         We use a hash-based key derivation function (HKDF) as defined in
         <xref target="RFC5869" />. We use HMAC-SHA512 for the extraction
         phase and HMAC-SHA256 for the expansion phase.
       </t>
       <dl>
         <dt>PRK_h</dt>
         <dd>
           is key material retrieved using an HKDF using the string
           "key-derivation" as salt and the public zone key "zk" as initial
           keying material.
         </dd>
         <dt>h</dt>
         <dd>
           is the 512-bit HKDF expansion result. The expansion info input is a
           concatenation of the label and string "gns".
         </dd>
         <dt>d</dt>
         <dd>
           is the 256-bit private zone key as defined in <xref target="zones" />.
         </dd>
         <dt>label</dt>
         <dd>
           is a UTF-8 string under which the resource records are published.
         </dd>
         <dt>d_h</dt>
         <dd>
           is a 256-bit private key derived from the "d" using the
           keying material "h".
         </dd>
         <dt>zk_h</dt>
         <dd>
           is a 256-bit public key derived from the zone key "zk" using the
           keying material "h".
         </dd>
         <dt>L</dt>
         <dd>
           is the prime-order subgroup as defined in <xref target="zones" />.
         </dd>
         <dt>q</dt>
         <dd>
           Is the 512-bit 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".
         </dd>
       </dl>
       <t>
         We point out that the multiplication of "zk" with "h" is a point multiplication,
         while the multiplication of "d" with "h" is a scalar multiplication.
       </t>
     </section>
     <section anchor="wire" numbered="true" toc="default">
       <name>Resource records block</name>
       <t>
         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 implementation must publish resource record blocks in accordance
         to the properties and recommendations of the underlying DHT. This may
         include a periodic refresh publication.
         A GNS resource records block has the following format:
       </t>
       <figure anchor="figure_record_block">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                   SIGNATURE                   |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  PUBLIC KEY                   |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |         SIZE          |       PURPOSE         |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                   EXPIRATION                  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    BDATA                      /
           /                                               /
           /                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
       </figure>
       <t>where:</t>
       <dl>
         <dt>SIGNATURE</dt>
         <dd>
           A 512-bit ECDSA deterministic signature compliant with
           <xref target="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
           <xref target="publish" />).
         </dd>
         <dt>PUBLIC KEY</dt>
         <dd>
           is the 256-bit public key "zk_h" to be used to verify SIGNATURE. The
           wire format of this value is defined in <xref target="RFC8032" />,
           Section 5.1.5.
         </dd>
         <dt>SIZE</dt>
         <dd>
           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.  While a 32-bit value is used,
           implementations MAY refuse to publish blocks beyond a certain
           size significantly below 4 GB. However, a minimum block size of
           62 kilobytes MUST be supported.
           <!-- See GNUNET_CONSTANTS_MAX_BLOCK_SIZE -->
         </dd>
         <dt>PURPOSE</dt>
         <dd>
           A 32-bit signature purpose flag. This field MUST be 15 (in network
           byte order).
         </dd>
         <dt>EXPIRATION</dt>
         <dd>
           Specifies when the resource records block expires and the encrypted block
           SHOULD be removed from the DHT and caches as it is likely stale.
           However, applications MAY continue to use non-expired individual
           records until they expire.  The value MUST be set to 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.
         </dd>
         <dt>BDATA</dt>
         <dd>
           The encrypted resource records with a total size of SIZE - 16.
         </dd>
       </dl>
     </section>
     <section numbered="true" toc="default">
       <name>Block data encryption and decryption</name>
       <t>
         A symmetric encryption scheme is used to encrypt the resource records
         set RDATA into the BDATA field of a GNS record block.
         The wire format of the RDATA looks as follows:
       </t>
       <figure anchor="figure_rdata">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |     RR COUNT          |        EXPIRA-        /
           +-----+-----+-----+-----+-----+-----+-----+-----+
           /         -TION         |       DATA SIZE       |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |         TYPE          |          FLAGS        |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                      DATA                     /
           /                                               /
           /                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                   EXPIRATION                  |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |       DATA SIZE       |          TYPE         |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |           FLAGS       |        DATA           /
           +-----+-----+-----+-----+                       /
           /                       +-----------------------/
           /                       |                       /
           +-----------------------+                       /
           /                     PADDING                   /
           /                                               /
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>where:</t>
       <dl>
         <dt>RR COUNT</dt>
         <dd>
           A 32-bit value containing the number of variable-length resource
           records which are
           following after this field in network byte order.
         </dd>
         <dt>EXPIRATION, DATA SIZE, TYPE, FLAGS and DATA</dt>
         <dd>
           These fields were defined
           in the resource record format in <xref target="rrecords" />.
           There MUST be a total of RR COUNT of these resource records
           present.
         </dd>
         <dt>PADDING</dt>
         <dd>
           The padding MUST contain the value 0 in all octets.
           The padding MUST ensure that the size of the RDATA WITHOUT the RR
           COUNT field is a power of two.
           As a special exception, record sets with (only) a PKEY record type
           are never padded. Note that a record set with a PKEY record MUST NOT
           contain other records.
         </dd>

       </dl>
       <t>
         To obtain a given resource records block, the client must first compute
         "zk_h" from "zk"
         and label (as defined in <xref target="blinding" />)
         and then use "zk_h" to compute "q" which is the query for the DHT.
         Upon receiving a block from the DHT, the receiver first checks
         that the PUBLIC KEY field matches "zk_h".  Then, the client MUST verify
         the signature. These steps are mandatory to prevent record spoofing and
         MUST be performed before decryption.
       </t>
       <t>
         The symmetric keys and initialization vectors are derived from the
         record label and the zone key "zk". For decryption of the resource
         records block payload, the key material "K" and initialization vector
         "IV" for the symmetric cipher are derived as follows:
       </t>
       <!-- OLD VERSION
       PRK_kiv := HKDF-Extract (zk, label)
       K := HKDF-Expand (PRK_kiv, "gns-aes-ctx-key", 512 / 8);
       IV := HKDF-Expand (PRK_kiv, "gns-aes-ctx-iv", 256 / 8)
       -->
       <artwork name="" type="" align="left" alt=""><![CDATA[
         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)
         ]]></artwork>
       <t>
         HKDF is a hash-based key derivation function as defined in
         <xref target="RFC5869" />. Specifically, HMAC-SHA512 is used 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 vectors.
         We divide the resulting keying material "K" into a 256-bit AES
         <xref target="RFC3826" /> key
         and a 256-bit TWOFISH <xref target="TWOFISH" /> key:
       </t>
       <figure anchor="figure_hkdf_keys">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    AES KEY                    |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  TWOFISH KEY                  |
           |                                               |
           |                                               |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>
       <t>
         Similarly, we divide "IV" into a 128-bit initialization vector
         and a 128-bit initialization vector:
       </t>
       <figure anchor="figure_hkdf_ivs">
         <artwork name="" type="" align="left" alt=""><![CDATA[
           0     8     16    24    32    40    48    56
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                    AES IV                     |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |                  TWOFISH IV                   |
           |                                               |
           +-----+-----+-----+-----+-----+-----+-----+-----+
           ]]></artwork>
         <!--        <postamble>which is a very simple example.</postamble>-->
       </figure>

       <t>
         The keys and IVs are used for a CFB128-AES-256 and
         CFB128-TWOFISH-256 chained symmetric cipher. Both ciphers are used in
         Cipher FeedBack (CFB) mode <xref target="RFC3826" />.
       </t>
       <artwork name="" type="" align="left" alt=""><![CDATA[
         RDATA := AES(AES KEY, AES IV, TWOFISH(TWOFISH KEY, TWOFISH IV, BDATA))
         BDATA := TWOFISH(TWOFISH KEY, TWOFISH IV, AES(AES KEY, AES IV, RDATA))
         ]]></artwork>
     </section>
   </section>
   <section anchor="encoding" numbered="true" toc="default">
     <name>Internationalization and Character Encoding</name>
     <t>
       All labels in GNS are encoded in UTF-8 <xref target="RFC3629" />.
       This does not include any DNS names found in DNS records, such as CNAME
       records, which are internationalized through the IDNA specifications
       <xref target="RFC5890" />.
     </t>
   </section>
   <section anchor="resolution" numbered="true" toc="default">
     <name>Record Resolution</name>
     <t>
       TODO
     </t>
     <section anchor="entry_zone" numbered="true" toc="default">
       <name>Entry Zone</name>
       <t>
         There are three sources from which the entry zone can be determined:
       </t>
         <ul>
           <li>Local zone store</li>
           <li>External prefix to zone key mappings</li>
           <li>Zone key TLD</li>
         </ul>
     </section>
     <section anchor="recursion" numbered="true" toc="default">
       <name>Recursive Resolution</name>
     </section>

   </section>
   <section anchor="revocation" numbered="true" toc="default">
     <name>Namespace Revocation</name>
     <t>
       TODO
     </t>
   </section>
   <section anchor="security" numbered="true" toc="default">
     <name>Security Considerations</name>
     <t>
       TODO
     </t>
   </section>
   <section anchor="iana" numbered="true" toc="default">
     <name>IANA Considerations</name>
     <t>
       This will be fun
     </t>
   </section>
   <!-- iana -->
   <section>
     <name>Test Vectors</name>
     <t>
       The following represents a test vector for a record of type MX with
       a priority of 10 and the mail hostname mail.example.com.
     </t>
     <artwork name="" type="" align="left" alt=""><![CDATA[
       label := "mail"

       d :=
       71199f7b287cc77a
       0d21b5e40a77cb1d
       f89333903b284fe8
       1878bf47f3b39da0

       zk (public zone key) :=
       dff911496d025d7e
       0885c03d19153e99
       4f213f23ea719eca
       17fc32dc410e082e

       h :=
       2af3275a9cf90e54
       f2dbf7930be76fb9
       5e7c80b1416f8ca6
       dc50ce8e1fb759b9
       fedcdcf546c17e9b
       4c4f23632855c053
       6668e9f684f4dc33
       6d656b27392b0fee

       d_h :=
       01fb61f482c17633
       77611c4c2509e0f3
       81b0e7e4405c10bd
       0017c802f7d32e18

       q (query key) :=
       6fce4deddc5ad681
       f4e29a3310767e3b
       8b38bc1b276ce2ba
       9bf1b49df1e120a3
       20ecc9dffb68416f
       11729ad878ad3bdf
       d0b4db2626b620d7
       8e0604e4393c66a3

       AES_KEY :=
       afefd21a087a150d
       6757741a4eda02a5
       65df7ca86ba44b21
       3f8106c0071eaf01

       AES_IV :=
       a808b929bc9fad7a
       686bbe3432bed77a

       TWOFISH_KEY :=
       c9d0089df01d0bf4
       e4c8db4b2ccc7328
       3425e8a811ae59d2
       99e2747285d2a479

       TWOFISH_IV :=
       071be189a9d236f9
       b4a3654bb8c281d4

       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


       BLOCK :=
       055cb070e05fe6de SIGNATURE
       ad694a50e5b4dedd
       b9fdcbdbae004f65
       afc99ba9c5a3bb54
       07e731a34680ee33
       ae0de7bfeda7d2b7
       8c6b854a008b1b54
       10df4f39f5ba9f46____________
       8cb514a56c0eaae0 zk_h
       56745158a63ee4dd
       76853cb9545e326e
       76d7fa920f818291____________
       000000540000000f SIZE (=84) | PURPOSE (=15)
       0005941209dde25b EXPIRATION
       d99d08fa123da096 BDATA
       66c2fb9bf020a85d
       e80818d0a84059a8
       5eee901a66459e5e
       3d1a10b29a5b8354
       1b58636781166b9a
       642920eee8e7a65a
       001fd19a6406a721
       713f0a0d
       ]]></artwork>

   </section>
 </middle>
 <back>
   <references>
     <name>Normative References</name>
     <reference anchor="RFC3492" target="https://www.rfc-editor.org/info/rfc3492"><front><title>Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)</title><author initials="A." surname="Costello" fullname="A. Costello"><organization/></author><date year="2003" month="March"/><abstract><t>Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).  It uniquely and reversibly transforms a Unicode string into an ASCII string.  ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm called Bootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.  Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3492"/><seriesInfo name="DOI" value="10.17487/RFC3492"/></reference>
     <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748"><front><title>Elliptic Curves for Security</title><author initials="A." surname="Langley" fullname="A. Langley"><organization/></author><author initials="M." surname="Hamburg" fullname="M. Hamburg"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2016" month="January"/><abstract><t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS).  These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t></abstract></front><seriesInfo name="RFC" value="7748"/><seriesInfo name="DOI" value="10.17487/RFC7748"/></reference>
     <reference anchor="RFC3826" target="https://www.rfc-editor.org/info/rfc3826"><front><title>The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model</title><author initials="U." surname="Blumenthal" fullname="U. Blumenthal"><organization/></author><author initials="F." surname="Maino" fullname="F. Maino"><organization/></author><author initials="K." surname="McCloghrie" fullname="K. McCloghrie"><organization/></author><date year="2004" month="June"/><abstract><t>This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model (USM), which is a Security Subsystem for version 3 of the Simple Network Management Protocol for use in the SNMP Architecture.  The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used in Cipher FeedBack Mode (CFB), with a key size of 128 bits.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="3826"/><seriesInfo name="DOI" value="10.17487/RFC3826"/></reference>
     <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890"><front><title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5890"/><seriesInfo name="DOI" value="10.17487/RFC5890"/></reference>
     <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869">
       <front>
         <title>
           HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
         </title>
         <author initials="H." surname="Krawczyk" fullname="H. Krawczyk">
           <organization/>
         </author>
         <author initials="P." surname="Eronen" fullname="P. Eronen">
           <organization/>
         </author>
         <date year="2010" month="May"/>
         <abstract>
           <t>
             This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.
           </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="5869"/>
       <seriesInfo name="DOI" value="10.17487/RFC5869"/>
     </reference>
     <reference anchor="RFC3629" target="https://www.rfc-editor.org/info/rfc3629"><front><title>UTF-8, a transformation format of ISO 10646</title><author initials="F." surname="Yergeau" fullname="F. Yergeau"><organization/></author><date year="2003" month="November"/><abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract></front><seriesInfo name="STD" value="63"/><seriesInfo name="RFC" value="3629"/><seriesInfo name="DOI" value="10.17487/RFC3629"/>
     </reference>
     <reference anchor="RFC8032" target="https://www.rfc-editor.org/info/rfc8032">
       <front>
         <title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
         <author initials="S." surname="Josefsson" fullname="S. Josefsson">
           <organization/>
         </author>
         <author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
           <organization/>
         </author>
         <date year="2017" month="January"/>
         <abstract>
           <t>
             This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.
           </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="8032"/>
       <seriesInfo name="DOI" value="10.17487/RFC8032"/>
     </reference>
     <reference anchor="RFC6895" target="https://www.rfc-editor.org/info/rfc6895"><front><title>Domain Name System (DNS) IANA Considerations</title><author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3rd"><organization/></author><date year="2013" month="April"/><abstract><t>This document specifies Internet Assigned Numbers Authority (IANA) parameter assignment considerations for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes.  It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930, and 3597.</t></abstract></front><seriesInfo name="BCP" value="42"/><seriesInfo name="RFC" value="6895"/><seriesInfo name="DOI" value="10.17487/RFC6895"/></reference>
     <reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"><front><title>Domain names - concepts and facilities</title><author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris"><organization/></author><date year="1987" month="November"/><abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract></front><seriesInfo name="STD" value="13"/><seriesInfo name="RFC" value="1034"/><seriesInfo name="DOI" value="10.17487/RFC1034"/></reference>
     <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
       <front>
         <title>Domain names - implementation and specification</title>
         <author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
           <organization/>
         </author>
         <date year="1987" month="November"/>
         <abstract>
           <t>
             This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.
           </t>
         </abstract>
       </front>
       <seriesInfo name="STD" value="13"/>
       <seriesInfo name="RFC" value="1035"/>
       <seriesInfo name="DOI" value="10.17487/RFC1035"/>
     </reference>
     <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979">
       <front>
         <title>
           Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
         </title>
         <author initials="T." surname="Pornin" fullname="T. Pornin">
           <organization/>
         </author>
         <date year="2013" month="August"/>
         <abstract>
           <t>
             This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
           </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="6979"/>
       <seriesInfo name="DOI" value="10.17487/RFC6979"/>
     </reference>
     <reference anchor="TWOFISH">
       <front>
         <title>
           The Twofish Encryptions Algorithm: A 128-Bit Block Cipher, 1st Edition
         </title>
         <author initials="B." surname="Schneier" fullname="B. Schneier">
           <organization/>
         </author>
         <date year="1999" month="March"/>
       </front>
     </reference>

     <!--    <reference anchor="ISO20022">
       <front>
         <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
         <author>
           <organization>International Organization for Standardization</organization>
           <address>
             <uri>http://www.iso.ch</uri>
           </address>
         </author>
         <date month="May" year="2013"/>
       </front>
     </reference>-->
   </references>
   <!-- Change Log
   v00 2017-07-23  MS   Initial version
   -->
 </back>
</rfc>