One document matched: draft-sury-dnskey-ed448-00.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 RFC5933 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5933.xml">
<!ENTITY RFC6605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6605.xml">
<!ENTITY RFC6781 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6781.xml">
<!ENTITY RFC6982 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6982.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-ed448-00" ipr="trust200902">
<front>
<title>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>
<author fullname="Robert Edmonds" initials="R.E."
surname="Edmonds">
<organization>Farsight Security, Inc.</organization>
<address>
<postal>
<street>155 Bovet Rd #476</street>
<city>San Mateo</city>
<code>94402</code>
<region>California</region>
<country>US</country>
</postal>
<phone>+1 650 489 7919</phone>
<email>edmonds@fsi.io</email>
</address>
</author>
<date month="September" year="2015" />
<area>Security</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>dnssec</keyword>
<keyword>ed448</keyword>
<abstract>
<t>
This document describes how to specify Ed448 keys and
signatures in DNS Security (DNSSEC). It uses the Ed448
instance of the Edwards-curve Digital Signature Algorithm
(EdDSA) with the SHA-512 hash algorithm.
</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. <xref target="RFC5933"/>
and <xref target="RFC6605"/> later defined the use of GOST and
NIST specified elliptic curve cryptography in DNSSEC.
</t>
<t>
This document defines the use of DNSSEC's DS, DNSKEY, and
RRSIG resource records (RRs) with a new signing algorithm: the
Ed448 instance of the Edwards-curve Digital Signature
Algorithm (EdDSA) used with the SHA-512 hash algorithm. A
more thorough description of Ed448 can be found in (TODO:
Simon is going to add Ed448 to his draft) <xref
target="I-D.josefsson-eddsa-ed25519"/>.
</t>
<t>
Ed448 has a 224-bit security target, which is considered to
be equivalent in strength to RSA with ~12000-bit keys. Ed448
public keys are 448 bits (56 bytes) long while signatures are
896 bits (112 bytes) long. The curve is meant as a more
conservative alternative to Ed25519.
</t>
<t>
The usage of the Ed448 algorithm in DNSSEC has advantages and
disadvantages relative to RSA. Ed448 keys are much shorter
than RSA keys. At RSA-4096 strength that is the maximum
defined for DNSSEC, Ed448 keys are 456 bytes smaller than
RSA-4096 keys. Similarly, an Ed448 signature saves 400 bytes
over an RSA-4096 signature.
</t>
<t>
However, DNSSEC with RSA is not commonly deployed on the
Internet with signatures as large as 3072 bits. <xref
target="RFC6781"/> contemplates the routine use of RSA-1024
and RSA-2048 in DNSSEC. Even when compared to the use of RSA
at reduced strengths, Ed448 still provides smaller keys and
signatures.
</t>
<t>
TODO - this is boilerplate :), we need to see the numbers.
Signing with Ed448 is significantly faster than signing with
equivalently strong RSA. However, the validation of RSA
signatures is significantly faster than the validation of
Ed448 signatures.
</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 and RRSIG Resource Records for Ed448">
<t>
An Ed448 public key consists of a 56-byte value that
represents the compressed encoding of the curve point, 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 Chapter 5.5 in
<xref target="I-D.josefsson-eddsa-ed25519"/>. (TODO)
</t>
<t>
An Ed448 signature consists of a 112-byte value, which is
encoded into the Signature field of an RRSIG resource record
as a simple bit string. The Ed448 signature algorithm is
described in Chapter 5.6 in
<xref target="I-D.josefsson-eddsa-ed25519"/>. (TODO)
</t>
<t>
The algorithm number associated with the use of Ed448 with
SHA-512 in DS, DNSKEY and RRSIG resource records is TBD. This
registration is fully defined in the IANA Considerations
section.
</t>
</section>
<section title="Examples">
<figure align="center">
<preamble>This section needs an update after the algorithm for
Ed448 is assigned. NOTE: Also the examples are copied from
Ed25519 draft and they need to be replaces with real
examples.</preamble>
<artwork align="left"><![CDATA[
Private-key-format: v1.2
Algorithm: TBD (ED448SHA512)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=
# corresponding 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: TBD (ED448SHA512)
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 anchor="Acknowledgements" title="Acknowledgements">
<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 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 has
been added to the registry:</t>
<texttable>
<ttcol></ttcol> <ttcol></ttcol>
<c>Number</c> <c>TBD</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="Implementation" title="Implementation Status">
<t>
(Note to the RFC Editor: please remove this entire section as well as the reference to RFC 6982 before publication.)
</t>
<t>
This section records the status of known implementations of
the protocol defined by this specification at the time of
posting of this Internet-Draft, and is based on a proposal
described in <xref target="RFC6982"/>. The description of
implementations in this section is intended to assist the IETF
in its decision processes in progressing drafts to RFCs.
Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no
effort has been spent to verify the information presented here
that was supplied by IETF contributors. This is not intended
as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to
note that other implementations may exist.
</t>
<t>
According to <xref target="RFC6982"/>, "this will allow
reviewers and working groups to assign due consideration to
documents that have the benefit of running code, which may
serve as evidence of valuable experimentation and feedback
that have made the implemented protocols more mature. It is
up to the individual working groups to use this information as
they see fit".
</t>
<t>
TODO: Fill out this section.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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;
&EDDSA;
</references>
<references title="Informative References">
&RFC5933;
&RFC6605;
&RFC6781;
&RFC6982;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:35:44 |