One document matched: draft-sury-dnskey-ed25519-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC6605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6605.xml">
<!ENTITY CURVES PUBLIC '' "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-cfrg-curves.xml">
<!ENTITY EDDSA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.josefsson-eddsa-ed25519.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-sury-dnskey-ed25519-02" ipr="trust200902">
<front>
<title>Ed25519 and Ed448 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>CZ</country>
</postal>
<phone>+420 222 745 111</phone>
<email>ondrej.sury@nic.cz</email>
</address>
</author>
<date month="August" year="2015" />
<area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>dnssec</keyword>
<keyword>ed25519</keyword>
<keyword>ed448</keyword>
<abstract>
<t>This document describes how to specify Ed25519 and Ed448 keys
and signatures in DNS Security (DNSSEC). It uses the Ed25519
and Ed448 curve and the SHA-512 for signatures.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>DNSSEC, which is broadly defined in RFCs <xref
target="RFC4033">4033</xref>, <xref
target="RFC4034">4034</xref>, and <xref
target="RFC4035">4035</xref>, uses cryptographic keys and
digital signatures to provide authentication of DNS data.
Currently, the most popular signature algorithm is RSA. <xref
target="RFC6605">RFC 6605</xref> defines usage of Elliptic Curve
Digital Signature Algorithm (ECDSA) for DNSSEC with curve P-256
and SHA-256, and ECDSA with curve P-384 and SHA-384.</t>
<t>This document defines the DNSKEY and RRSIG resource records
(RRs) of two new signing algorithm:
<list>
<t>Curve Ed25519 and SHA-512.</t>
<t>Curve Ed448 and SHA-512.</t>
</list>
A description of both curves can be found in <xref
target="I-D.irtf-cfrg-curves">Elliptic Curves for
Security</xref>. A more thorough description of Ed25519 can be
found in <xref target="I-D.josefsson-eddsa-ed25519">EdDSA and
Ed25519</xref>.)
</t>
<t>Ed25519 is targeted to provide attack resistance comparable
to quality 128-bit symmetric ciphers that is equivalent
strength of RSA with 3072-bit keys. Public keys are 256 bits
(32 bytes) in length and signatures are 512 bits (64 bytes).
</t>
<t>Ed448 is targeted to provide attack resistance comparable
to quality 224-bit symmetric ciphers that is equivalent
strength of RSA with ~12448-bit keys. However only RSA with
4096-bit keys is defined for use in DNSSEC, so we are going to
use RSA-4096 in comparisons below. Ed448 public keys are 448
bits (56 bytes) in length and signatures are 896 bits
(112-bytes). The curve is meant as a more conservative
alternative to Ed25519.</t>
<t>Using the Ed25519 and Ed448 curve in DNSSEC has some
advantages and disadvantage relative to using RSA. The
Ed25519 and Ed448 keys are much shorter than RSA keys; at the
comparable size, the difference is 256 versus 3072 bits for
the Ed25519 and 448 versus 4096 bits for the Ed448. The
Ed25519 and Ed448 signatures are also much shorter than RSA
keys; at the comparable size, the difference is 512 versus
3072 bits for the Ed25519 and 896 versus 4096 bits for the
Ed448. This is relevant because DNSSEC stores and transmits
both keys and signatures.</t>
<t>Signing with Ed25519 and Ed448 is significantly faster than
with equivalently strong RSA, it is also faster than existing
ECDSA curves in DNSSEC defined in <xref target="RFC6605">RFC
6605</xref>. However, validating RSA signatures is
significantly faster than validating Ed25519 and Ed448
signatures.</t>
<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">RFC 2119</xref>.</t>
</section>
</section>
<section title="DNSKEY and RRSIG Resource Records for Ed25519 and Ed448">
<section title="Public Keys">
<t>The Ed25519 public keys consist of a 32-byte value that
represents encoding of the curve point. The generation of
public key is defined Chapter 5.5 in <xref
target="I-D.josefsson-eddsa-ed25519">I-D.josefsson-eddsa-ed25519</xref>.</t>
<t>The Ed448 public key consist of a 56-byte value that
represents encoding of the curve point.</t>
<t>In DNSSEC keys, the Ed25519 and Ed448 public key is a
simple bit string that represents uncompressed form of a curve
point.</t>
</section>
<section title="Signatures">
<t>The Ed25519 signature consists of a 64-byte value. The
Ed25519 signature algorithm is described Chapter 5.6 in <xref
target="I-D.josefsson-eddsa-ed25519">I-D.josefsson-eddsa-ed25519</xref>.</t>
<t>The Ed448 signature consists of a 112-byte value. In
DNSSEC keys, the Ed448 signatures is a simple bit string that
represents the Ed448 signature.</t>
<t>In DNSSEC keys, the Ed25519 and Ed448 signatures is a
simple bit string that represents the signature.</t>
</section>
<section title="Algorithm Numbers">
<t>The algorithm number associated with the DNSKEY and RRSIG
resource records is fully defined in the IANA Considerations
section. DNSKEY and RRSIG RRs signifying:
<list>
<t>Ed25519 and SHA-512 use the algorithm number TBD1.</t>
<t>Ed448 and SHA-512 use the algorithm number TBD2.</t>
</list>
</t>
</section>
</section>
<section title="Examples">
<section title="Ed25519 Example">
<figure align="center">
<preamble>This section need an update after the algorithm
for Ed25519 with SHA-512 is assigned.</preamble>
<artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: TBD1 (ED25519SHA512)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=
# coresponding to 82260384628080122645190204142262 INT
example.com. 3600 IN DNSKEY 257 3 TBD (
l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )
example.com. 3600 IN DS 3613 TBD 2 (
3aa5ab37efce57f737fc1627013fee07bdf241bd10f3
b1964ab55c78e79a304b )
www.example.com. 3600 IN A 192.0.2.1
www.example.com. 3600 IN RRSIG A TBD 3 3600 (
20150820000000 20150730000000 3613 example.com.
cvTRVrU7dwnemQuBq9/E4tlIiRpvWcEmYdzqs6SCQxw6
qmczBBQGldssMx1TCJnwsEs9ZuA2phPzuJNoon9BCA== )
]]></artwork>
</figure>
<figure>
<artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: TBD1 (ED25519SHA512)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=
example.com. 3600 IN DNSKEY 257 3 TBD (
zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )
example.com. 3600 IN DS 55648 TBD 2 (
96401675bc7ecdd541ec0f70d69238c7b95d3bd4de1e
231a068ceb214d02a4ed )
www.example.com. 3600 IN A 192.0.2.1
www.example.com. 3600 IN RRSIG A TBD 3 3600 (
20150820000000 20150730000000 35452 example.com.
yuGb9rCNIuhDaRJbuhYHj89Y/3Pi8KWUm7lOt00ivVRGvgulmVX8DgpE
AFyMP2MKXJrqYJr+ViiCIDwcOIbPAQ==)
]]></artwork>
</figure>
</section>
<section title="Ed448 Example">
<t>[[TODO]]</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Some of the material in this document is copied liberally from
<xref target="RFC6605">RFC 6605</xref>.
</t>
<t>
The author of this document wants to thanks Pieter Lexis and
Kees Monshouwer for a review of this document.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This document updates the IANA registry "Domain Name System
Security (DNSSEC) Algorithm Numbers". The following entry have
been added to the registry:</t>
<texttable>
<ttcol></ttcol> <ttcol></ttcol>
<c>Number</c> <c>TBD1</c>
<c>Description</c> <c>Ed25519 with SHA-512</c>
<c>Mnemonic</c> <c>Ed25519SHA512</c>
<c>Zone Signing</c> <c>Y</c>
<c>Trans. Sec.</c> <c>*</c>
<c>Reference</c> <c>This document</c>
<postamble>* There has been no determination of
standardization of the use of this algorithm with Transaction
Security.</postamble>
</texttable>
<texttable>
<ttcol></ttcol> <ttcol></ttcol>
<c>Number</c> <c>TBD2</c>
<c>Description</c> <c>Ed448 with SHA-512</c>
<c>Mnemonic</c> <c>Ed448SHA512</c>
<c>Zone Signing</c> <c>Y</c>
<c>Trans. Sec.</c> <c>*</c>
<c>Reference</c> <c>This document</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>Ed25519 is targeted to provide attack resistance comparable
to quality 128-bit symmetric ciphers, and Ed448 is targeted to
provide attack resistance comparable to quality 224-bit
symmetric ciphers. Such an assessment could, of course, change
in the future if new attacks that work better than the ones
known today are found.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
&RFC2119;
&RFC4033;
&RFC4034;
&RFC4035;
&CURVES;
&EDDSA;
</references>
<references title="Informative References">
&RFC6605;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:42 |