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="Grothhoff">
   <organization>Berner Fachhochschule</organization>
   <address>
    <postal>
     <street>Höheweg 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>schanzen@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>
    This document contains the GNU Name System (GNS) technical specification
    for secure, censorship-resistant and decentralised name resolution.
   </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 ECC key pair (d,zk),
    where d is the private key and
    zk the corresponding public key.
    GNS uses the Ed25519 EC parameters as defined in <xref target="RFC8032" />.
    GNS combines the EC parameters of Ed25519 with the ECDSA scheme
    defined in <xref target="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 <xref target="publish" />.
   </t>
  </section>
  <section anchor="rrecords" numbered="true" toc="default">
    <name>Resource records</name>
   <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 expiration date of the record.
     In microseconds since midnight (0 hour), January 1, 1970 in network
     byte order.
    </dd>
    <dt>DATA SIZE</dt>
    <dd>
      The size of the DATA field in bytes and in network byte order.
    </dd>
    <dt>TYPE</dt>
    <dd>
     The 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>
     Resource record flags.
   </dd>
   <dt>DATA</dt>
   <dd>
     The 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 a string (which is not 0-terminated) representing
  the legacy hostname to use (FIXME: in UTF-8 or PUNY?).
  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>
</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                      |
      /                                               /
      /                                               /
      |                                               |
      +-----+-----+-----+-----+-----+-----+-----+-----+
      ]]></artwork>
    <!--        <postamble>which is a very simple example.</postamble>-->
  </figure>
      <dl>
        <dt>PROTO</dt>
        <dd>
          the protocol number, e.g. 6 for tcp. In network byte order.
        </dd>
        <dt>SVC</dt>
        <dd>
          the service of the boxed record, i.e. the port number. In network
          byte order.
        </dd>
        <dt>TYPE</dt>
        <dd>
          Record type of the boxed record. In network byte order.
        </dd>
        <dt>RECORD</dt>
        <dd>
          The boxed record in a format as defined in
          <xref target="rrecords" />.
        </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 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:
    </t>
    <section anchor="blinding" numbered="true" toc="default">
      <name>Key derivations</name>
      <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 p
        zk_h := h*zk mod p
        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 "x*P" as initial keying
          material.
        </dd>
        <dt>h</dt>
        <dd>
          is the HKDF expansion result. The expansion info is a concatenation of
          the label and string "gns".
        </dd>
        <dt>d</dt>
        <dd>
          is the private zone key as defined in <xref target="RFC8032" />.
        </dd>
        <dt>P</dt>
        <dd>
          is the base point of the curve Ed25519 as defined in
          <xref target="RFC8032" />.
        </dd>
        <dt>label</dt>
        <dd>
          under wich the resource records are published.
        </dd>
        <dt>d_h</dt>
        <dd>
          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
          <xref target="RFC8032" />.
        </dd>
        <dt>zk_h</dt>
        <dd>
          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
          <xref target="RFC8032" />.
        </dd>
        <dt>q</dt>
        <dd>
          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".
        </dd>
      </dl>
    </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 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>
          The 256-bit ECC 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.
        </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>
          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.
        </dd>
        <dt>BDATA</dt>
        <dd>
          The encrypted resource records with a total size of SIZE - 16.
        </dd>
      </dl>
      <t>
        We note that even though we use a Ed25519 private key, the public key
        is derived using ECDSA as defined in <xref target="RFC8032" />.
        Similarly, the ECDSA signature consists of a pair of integers, r and s:
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
        0     8     16    24    32    40    48    56
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                       r                       |
        |                                               |
        |                                               |
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |                       s                       |
        |                                               |
        |                                               |
        |                                               |
        +-----+-----+-----+-----+-----+-----+-----+-----+
        ]]></artwork>
    </section>
    <section numbered="true" toc="default">
      <name>Block data encryption and decryption</name>
      <t>
        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:
      </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>
        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.
        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":
      </t>
      <figure anchor="figure_hkdf_keys">
        <artwork name="" type="" align="left" alt=""><![CDATA[
          0     8     16    24    32    40    48    56
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                    AES KEY (Kaes)             |
          |                                               |
          |                                               |
          |                                               |
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                  TWOFISH KEY (Ktwo)           |
          |                                               |
          |                                               |
          |                                               |
          +-----+-----+-----+-----+-----+-----+-----+-----+
          ]]></artwork>
        <!--        <postamble>which is a very simple example.</postamble>-->
      </figure>
      <t>
        Similarly, we divide "IV" into a 128-bit initialization vector IVaes
        and a 128-bit initialization vector IVtwo:
      </t>
      <figure anchor="figure_hkdf_ivs">
        <artwork name="" type="" align="left" alt=""><![CDATA[
          0     8     16    24    32    40    48    56
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                    AES IV (IVaes)             |
          |                                               |
          +-----+-----+-----+-----+-----+-----+-----+-----+
          |                  TWOFISH IV (IVtwo)           |
          |                                               |
          +-----+-----+-----+-----+-----+-----+-----+-----+
          ]]></artwork>
        <!--        <postamble>which is a very simple example.</postamble>-->
      </figure>

      <t>
        The symmetric keys and IVs are used for a AES+TWOFISH combined
        cipher. Both ciphers are used in Cipher FeedBack (CFB) mode.
      </t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
        RDATA := AES(Kaes, IVaes, TWOFISH(Ktwo, IVtwo, BDATA))
        BDATA := TWOFISH(Ktwo, IVtwo, AES(Kaes, IVaes, RDATA))
        ]]></artwork>
      <t>
        The decrypted RDATA has the following format:
      </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 resource records which are
          following in network byte order.
        </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 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>
        is followed by a set of resource records with the respective
        formats defined in <xref target="rrecords" />.
      </t>
    </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="security" numbered="true" toc="default">
    <name>Security Considerations</name>
    <t>
      TODO
    </t>
  </section>
  <section anchor="resolution" numbered="true" toc="default">
    <name>Record Resolution</name>
    <t>
      TODO
    </t>
  </section>
  <section anchor="revocation" numbered="true" toc="default">
    <name>Namespace Revocation</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 :=
      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
      ]]></artwork>

  </section>
</middle>
<back>
  <references>
    <name>Normative References</name>
    <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="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>