Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
Extracted elements (17)
ECDSA keys and signatures are much shorter than RSA equivalents at comparable security levels (256 vs 3072 bits for keys at ~128-bit security), making ECDSA advantageous for DNSSEC which must store and transmit both keys and signatures in DNS records.
The document defines only two algorithms pairing matched key and hash sizes (P-256 with SHA-256, P-384 with SHA-384) to prevent an attacker from exploiting the weaker half of a mismatched algorithm pair, such as RSA-2048 with SHA-256 where the signing strength is significantly weaker than the hash strength.
This document does not define NSEC3-specific algorithm aliases (as RFC 5155 did for older algorithms) because that mechanism was solely to protect pre-RFC-5155 implementations from unknown record types — a concern that does not apply to newly defined algorithms.
ECDSA signing is significantly faster than RSA (over 20× in some implementations), but RSA signature validation is significantly faster than ECDSA validation (about 5× faster), which has implications for validator performance when deploying ECDSA in DNSSEC.
A DNSSEC validator implementing 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 using the signing algorithms defined in this document with NSEC denial of existence.
Conformant DNSSEC verifiers MUST implement verification for both ECDSAP256SHA256 and ECDSAP384SHA384 algorithms.
Conformant implementations that create records to be put into the DNS MUST implement signing and verification for both ECDSAP256SHA256 (algorithm 13) and ECDSAP384SHA384 (algorithm 14).
For P-256, each of the ECDSA signature integers r and s MUST be encoded as 32 octets; for P-384, each MUST be encoded as 48 octets.
ECDSA parameters for DNSSEC use NIST curves P-256 and P-384 as specified in FIPS 186-3 sections D.1.2.3 and D.1.2.4 respectively, which are the same as the 256-bit and 384-bit Random ECP Groups in RFC 5114.
Two new DNSSEC algorithm numbers are defined: algorithm 13 for ECDSA with curve P-256 and SHA-256 (ECDSAP256SHA256), and algorithm 14 for ECDSA with curve P-384 and SHA-384 (ECDSAP384SHA384), used in DNSKEY and RRSIG RRs.
The IANA 'Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms' registry is updated with digest type value 4 for SHA-384, with status OPTIONAL.
The IANA 'Domain Name System Security (DNSSEC) Algorithm Numbers' registry is updated with two new entries: number 13 (ECDSAP256SHA256) and number 14 (ECDSAP384SHA384), both supporting zone signing; Transaction Security use is not standardized.
The cryptographic work factor of ECDSA with curve P-256 is considered equivalent to 128 bits of security, and P-384 equivalent to 192 bits, based on the principle that equivalent strength is half the key length. This assessment could change if new attacks are found.
ECDSA public key (Q) is stored in DNSKEY RRs as an uncompressed curve point in the form 'x | y' — a simple bit string with no compression indicator byte. For P-256 this is 64 octets; for P-384 it is 96 octets.
ECDSA signatures in RRSIG RRs are stored as the concatenation 'r | s', where each integer is a fixed-length octet string: 32 octets each for P-256 (total 64 octets), and 48 octets each for P-384 (total 96 octets).
SHA-384 DS records use digest type code 4, and the digest value is 48 bytes long. The implementation follows RFC 4509 (SHA-256 DS records) except for the underlying algorithm and digest length.