]>
Elliptic Curve DSA for DNSSECVPN Consortiumpaul.hoffman@vpnc.orgNLnet Labswouter@nlnetlabs.nlThis document describes how to specify Elliptic Curve DSA keys and
signatures in DNSSEC. It lists curves of different sizes, and
uses the SHA-2 family of hashes for signatures.DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035
(, , and ), 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 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 .)
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 .
provides a good introducition to implementing ECDSA.
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 5430 .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 RFC 2119 .SHA-384 is defined in FIPS 180-3 and
RFC 6234 , and is similar to SHA-256 in many
ways. The implementation of SHA-384 in DNSSEC follows the
implementation of SHA-256 as specified in RFC 4509 except that the
underlying algorithm is SHA-384, the digest value is 48 bytes long,
and the digest type code is {TBA-1}.Verifying ECDSA signatures requires agreement between the signer
and the verifier of the parameters used. FIPS 186-3 lists some NIST-recommended elliptic curves.
(Other documents give more detail on ECDSA than is given
in FIPS 186-3.)
These are the same curves as listed in RFC 5114 .
The curves used in this document are:ECDSA public keys consist of a single value, called "Q" in FIPS
186-3. In DNSSEC keys, Q is a simple bit string that represents
the uncompressed form of a curve point, "x | y".The ECDSA signature is the combination of two non-negative integers,
called "r" and "s" in FIPS 186-3. The two integers, each of which is
formatted as a simple octet string, are combined into a single longer
octet string for DNSSEC as the concatenation "r | s".
For P-256, each integer MUST be encoded as 32 octets; for P-384,
each integer MUST each be encoded as 48 octets.The algorithm numbers associated with the DNSKEY and RRSIG resource
records are fully defined in the IANA Considerations section. They are:DNSKEY and RRSIG RRs signifying ECDSA with the
P-256 curve and SHA-256 use the algorithm number {TBA-2}.DNSKEY and RRSIG RRs signifying ECDSA with the
P-384 curve and SHA-384 use the algorithm number {TBA-3}.Conformant implementations that create records to be put into the DNS MUST
implement signing and verification for both of the above algorithms.
Conformant DNSSEC verifiers MUST implement verification for both of the above
algorithms.RFC 5155 defines new algorithm
identifiers for existing signing algorithms, to indicate that zones
signed with these algorithm identifiers can use NSEC3 as well as NSEC
records to provide denial of existence. That mechanism was chosen to
protect implementations predating RFC 5155 from encountering resource
records they could not know about. This document does not define
such algorithm aliases.A DNSSEC validator that implements the signing algorithms defined
in this document MUST be able to validate negative answers in the
form of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC
5155. An authoritative server that does not implement NSEC3 MAY
still serve zones that use the signing algorithms defined in this
document with NSEC denial of existence. The following are some examples of ECDSA keys and signatures in
DNS format. [[ IMPORTANT NOTE: This section is to be used for testing only until IANA
allocates code points. The examples use {TBA-1}: 4, {TBA-2}: 13, {TBA-3}: 14.
IANA is requested to allocate these code points to their respective registries
in the IANA Considerations section. ]]This document updates the IANA registry for digest types in DS records,
currently called "Delegation Signer Resource Record, Digest
Algorithms". The following entry is added:This document updates the IANA registry "Domain Name System
Security (DNSSEC) Algorithm Numbers". The following two entries are
added to the registry:The cryptographic work factor of ECDSA with curve P-256 or P-384 is
generally considered to be equivalent to half the size of the key, or
128 bits and 192 bits, respectively. Such an assessment could, of
course, change in the future if new attacks that work better than the
ones known today are found.The security considerations listed in RFC 4509 apply here
as well.Secure Hash Standard (SHS)National Institute of Standards and
Technology, U.S. Department of CommerceDigital Signature StandardNational Institute of Standards and
Technology, U.S. Department of Commerce
&rfc2119;
&rfc4033;
&rfc4034;
&rfc4035;
&rfc4509;
&rfc5114;
&rfc5155;
&rfc5430;
&rfc6090;
&rfc6234;