<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "reference.RFC.2119.xml">
<!ENTITY RFC4033 PUBLIC "" "reference.RFC.4033.xml">
<!ENTITY RFC4034 PUBLIC "" "reference.RFC.4034.xml">
<!ENTITY RFC4035 PUBLIC "" "reference.RFC.4035.xml">
<!ENTITY RFC5933 PUBLIC "" "reference.RFC.5933.xml">
<!ENTITY RFC6605 PUBLIC "" "reference.RFC.6605.xml">
<!ENTITY RFC7748 PUBLIC "" "reference.RFC.7748.xml">
<!ENTITY RFC8032 PUBLIC "" "reference.RFC.8032.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" number="8080" ipr="trust200902" submissionType="IETF" consensus="yes">

  <front>
    <title abbrev="EdDSA for DNSSEC"> Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC</title>

    <author fullname="Ondrej Sury" initials="O.S."
            surname="Sury">
      <organization>CZ.NIC</organization>
      <address>
        <postal>
          <street>Milesovska 1136/5</street>
          <city>Praha</city>
          <code>130 00</code>
          <country>Czech Republic</country>
        </postal>
        <email>ondrej.sury@nic.cz</email>
      </address>
    </author>

    <author fullname="Robert Edmonds" initials="R.E."
            surname="Edmonds">
      <organization>Fastly</organization>
      <address>
        <postal>
          <street></street>
          <city>Atlanta</city>
          <region>Georgia</region>
          <code></code>
          <country>United States of America</country>
        </postal>
        <email>edmonds@mycre.ws</email>
      </address>
    </author>

    <date month="February" year="2017" />

    <area>Security</area>

    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>dnssec</keyword>
    <keyword>eddsa</keyword>
    <keyword>ed25519</keyword>
    <keyword>ed448</keyword>
    <abstract>
      <t>
        This document describes how to specify Edwards-curve Digital Security Algorithm (EdDSA) keys and
        signatures in DNS Security (DNSSEC).  It uses EdDSA with the
        choice of two curves: Ed25519 and Ed448.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

      <t>
        DNSSEC, which is broadly defined in <xref target="RFC4033"/>,
        <xref target="RFC4034"/>, and <xref target="RFC4035"/>, uses
        cryptographic keys and digital signatures to provide
        authentication of DNS data.  Currently, the most popular
        signature algorithm in use is RSA.  GOST <xref
        target="RFC5933"/> and NIST-specified elliptic curve
        cryptography <xref target="RFC6605"/> are also standardized.
      </t>
      
      <t>
        <xref target="RFC8032"/> describes the elliptic
        curve signature system Edwards-curve Digital Signature Algorithm (EdDSA) and recommends two curves,
        Ed25519 and Ed448.
      </t>

      <t>
        This document defines the use of DNSSEC's DS, DNSKEY, and
        RRSIG resource records (RRs) with a new signing algorithm,
        EdDSA, using a choice of two curves: Ed25519 and Ed448.
      </t>
      
    </section>

    <section title="Requirements Language">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described
        in <xref target="RFC2119"/>.
      </t>
    </section>

    <section title="DNSKEY Resource Records">
      <t>
        An Ed25519 public key consists of a 32-octet value, which
        is encoded into the Public Key field of a DNSKEY resource
        record as a simple bit string.  The generation of a public key
        is defined in Section 5.1.5 of <xref
        target="RFC8032"/>.
      </t>

      <t>
        An Ed448 public key consists of a 57-octet value, which is
        encoded into the Public Key field of a DNSKEY resource record
        as a simple bit string.  The generation of a public key is
        defined in Section 5.2.5 of <xref
        target="RFC8032"/>.
      </t>
    </section>

    <section title="RRSIG Resource Records">
      
      <t>
        An Ed25519 signature consists of a 64-octet value, which is
        encoded into the Signature field of an RRSIG resource record
        as a simple bit string.  The Ed25519 signature algorithm and verification of the Ed25519
        signature are described in Sections 5.1.6 and 5.1.7 of <xref
        target="RFC8032"/>, respectively.
      </t>

      <t>
        An Ed448 signature consists of a 114-octet value, which is
        encoded into the Signature field of an RRSIG resource record
        as a simple bit string.  The Ed448 signature algorithm and verification of the Ed448
        signature are described in Sections 5.2.6 and 5.2.7 of <xref
        target="RFC8032"/>, respectively.
      </t>

    </section>

    <section title="Algorithm Number for DS, DNSKEY, and RRSIG Resource Records">
      <t>
        The algorithm number associated with the use of Ed25519 in
        DS, DNSKEY, and RRSIG resource records is 15.  The algorithm
        number associated with the use of Ed448 in DS, DNSKEY, and
        RRSIG resource records is 16.  This registration is fully
        defined in the IANA Considerations section.
      </t>
    </section>

    <section title="Examples">
      <section title="Ed25519 Examples">
        <figure align="center">
 
          <artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )
         ]]></artwork>
        </figure>
        <figure align="center">

          <artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )
         ]]></artwork>
        </figure>
      </section>
      <section title="Ed448 Examples">
        <figure align="center">

          <artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )
         ]]></artwork>
        </figure>
        <figure align="center">
  
          <artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )
         ]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document updates the IANA registry "Domain Name System
      Security (DNSSEC) Algorithm Numbers".  The following entries have
      been added to the registry:</t>

      <texttable>
        <ttcol></ttcol>     <ttcol></ttcol>      <ttcol></ttcol>
        <c>Number</c>       <c>15</c>          <c>16</c>
        <c>Description</c>  <c>Ed25519</c>       <c>Ed448</c>
        <c>Mnemonic</c>     <c>ED25519</c>       <c>ED448</c>
        <c>Zone Signing</c> <c>Y</c>             <c>Y</c>
        <c>Trans. Sec.</c>  <c>*</c>             <c>*</c>
        <c>Reference</c>    <c>RFC 8080</c> <c>RFC 8080</c>

        <postamble>* There has been no determination of
        standardization of the use of this algorithm with Transaction
        Security.</postamble>
      </texttable>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>
        The security considerations of <xref target="RFC8032"/>
        and <xref target="RFC7748"/> are inherited in the usage of
        Ed25519 and Ed448 in DNSSEC.
      </t>
      <t>
        Ed25519 is intended to operate at around the 128-bit security
        level and Ed448 at around the 224-bit security level.  A
        sufficiently large quantum computer would be able to break
        both.  Reasonable projections of the abilities of classical
        computers conclude that Ed25519 is perfectly safe.  Ed448 is
        provided for those applications with relaxed performance
        requirements and where there is a desire to hedge against
        analytical attacks on elliptic curves.
      </t>
      <t>
        These assessments could, of course, change in the future if
        new attacks that work better than the ones known today are
        found.
      </t>
      <t>
	A private key used for a DNSSEC zone MUST NOT be used for any
	other purpose than for that zone.  Otherwise, cross-protocol or
	cross-application attacks are possible.
      </t>
    </section>
  </middle>


  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC4033;
      &RFC4034;
      &RFC4035;
      &RFC7748;
      &RFC8032;
    </references>

    <references title="Informative References">
      &RFC5933;
      &RFC6605;
     
    </references>

  <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
      <t>
        Some of the material in this document is copied liberally from 
        <xref target="RFC6605"/>.
      </t>
      <t>
        The authors of this document wish to thank Jan Vcelak, Pieter
        Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman, and
        others for a review of this document.
      </t>
    </section>

  </back>
</rfc>
