Internet Engineering Task Force (IETF) O. Sury Request for Comments: 8080 CZ.NIC Category: Standards Track R. Edmonds ISSN: 2070-1721 Fastly February 2017
Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm in use is RSA. GOST [RFC5933] and NIST-specified elliptic curve cryptography [RFC6605] are also standardized.
[RFC8032] describes the elliptic curve signature system Edwards-curve Digital Signature Algorithm (EdDSA) and recommends two curves, Ed25519 and Ed448.
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.
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 [RFC8032].
Sury & Edmonds Standards Track [Page 2]
RFC 8080 EdDSA for DNSSEC February 2017
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 [RFC8032].
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 [RFC8032], respectively.
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 [RFC8032], respectively.
5. Algorithm Number for DS, DNSKEY, and RRSIG Resource Records
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.
The security considerations of [RFC8032] and [RFC7748] are inherited in the usage of Ed25519 and Ed448 in DNSSEC.
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
Sury & Edmonds Standards Track [Page 5]
RFC 8080 EdDSA for DNSSEC February 2017
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.
These assessments could, of course, change in the future if new attacks that work better than the ones known today are found.
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.