Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
RFC 6605

Document Type RFC - Proposed Standard (April 2012; No errata)
Authors Paul Hoffman  , Wouter Wijngaards 
Last updated 2020-11-26
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 6605 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ralph Droms
IESG note Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.
Send notices to (None)
Internet Engineering Task Force (IETF)                        P. Hoffman
Request for Comments: 6605                                VPN Consortium
Category: Standards Track                              W.C.A. Wijngaards
ISSN: 2070-1721                                               NLnet Labs
                                                              April 2012

      Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC


   This document describes how to specify Elliptic Curve Digital
   Signature Algorithm (DSA) keys and signatures in DNS Security
   (DNSSEC).  It lists curves of different sizes and uses the SHA-2
   family of hashes for signatures.

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 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2012 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.

Hoffman & Wijngaards         Standards Track                    [Page 1]
RFC 6605                    ECDSA for DNSSEC                  April 2012

1.  Introduction

   DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035
   ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and
   digital signatures to provide authentication of DNS data.  Currently,
   the most popular signature algorithm is RSA with SHA-1, using keys
   that are 1024 or 2048 bits long.

   This document defines the DNSKEY and RRSIG resource records (RRs) of
   two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve
   P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384.  (A
   description of ECDSA can be found in [FIPS-186-3].)  This document
   also defines the DS RR for the SHA-384 one-way hash algorithm; the
   associated DS RR for SHA-256 is already defined in RFC 4509
   [RFC4509].  [RFC6090] provides a good introduction to implementing

   Current estimates are that ECDSA with curve P-256 has an approximate
   equivalent strength to RSA with 3072-bit keys.  Using ECDSA with
   curve P-256 in DNSSEC has some advantages and disadvantages relative
   to using RSA with SHA-256 and with 3072-bit keys.  ECDSA keys are
   much shorter than RSA keys; at this size, the difference is 256
   versus 3072 bits.  Similarly, ECDSA signatures are much shorter than
   RSA signatures.  This is relevant because DNSSEC stores and transmits
   both keys and signatures.

   In the two signing algorithms defined in this document, the size of
   the key for the elliptic curve is matched with the size of the output
   of the hash algorithm.  This design is based on the widespread belief
   that the equivalent strength of P-256 and P-384 is half the length of
   the key, and also that the equivalent strength of SHA-256 and SHA-384
   is half the length of the key.  Using matched strengths prevents an
   attacker from choosing the weaker half of a signature algorithm.  For
   example, in a signature that uses RSA with 2048-bit keys and SHA-256,
   the signing portion is significantly weaker than the hash portion,
   whereas the two algorithms here are balanced.

   Signing with ECDSA is significantly faster than with RSA (over 20
   times in some implementations).  However, validating RSA signatures
   is significantly faster than validating ECDSA signatures (about 5
   times faster in some implementations).

   Some of the material in this document is copied liberally from RFC
   6460 [RFC6460].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Hoffman & Wijngaards         Standards Track                    [Page 2]
RFC 6605                    ECDSA for DNSSEC                  April 2012

2.  SHA-384 DS Records

   SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 6234 [RFC6234],
   and is similar to SHA-256 in many ways.  The implementation of SHA-
Show full document text