Ed25519 for DNSSEC

DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035,, uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm is RSA. RFC 6605 defines usage of Elliptic Curve Digital Signature Algorithm (ECDSA) for DNSSEC with curve P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384. This document defines the DNSKEY and RRSIG resource records (RRs) of one new signing algorithm: curve Ed25519 and SHA-256. (A description of Ed25519 can be found in EdDSA and Ed25519.) The DS RR for SHA-256 is already defined in RFC 4509. Ed25519 is targeted to provide attack resistance comparable to quality 128-bit symmetric ciphers that is equivalent strength of RSA with 3072-bit keys. Public keys are 256 bits (32 bytes) in length and signatures are 512 bits (64 bytes). Using Ed25519 curve in DNSSEC has some advantages and disadvantage relative to using RSA with SHA-256 and with 3072-bit keys. Ed25519 keys are much shorter than RSA keys; at this size, the difference is 256 versus 3072 bits. Similarly, Ed25519 signatures are much shorter than RSA signatures; at this size, the difference is 512 versus vs 3072 bits. This is relevant because DNSSEC stores and transmits both keys and signatures. In the signing algorithm 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 (SHA-256). The size of the signatures are also matched with size of the hashing algorithm (SHA-256). Signing with Ed25519 is significantly faster than with RSA (The reference implementation signs 109000 messages per second on a quad-core 2.4GHz Westmere CPU). However, validating RSA signatures is significantly faster than validating Ed25519 signatures.

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.

The Ed25519 public keys consist of a 32-byte value that represents encoding of the curve point. The generation of public key is defined Chapter 5.5 in I-D.josefsson-eddsa-ed25519. In DNSSEC keys, the Ed25519 public key is a simple bit string that represents uncompressed form of a curve point. The Ed25519 signature constist of a 64-byte value. The Ed25519 signature algorithm is described Chapter 5.6 in I-D.josefsson-eddsa-ed25519. In DNSSEC keys, the Ed25519 signatures is a simple bit string that represents Ed25519 signature. The algorithm number associated with the DNSKEY and RRSIG resource records are fully defined in the IANA Considerations section. They are: DNSKEY and RRSIG RRs signifying Ed25519 and SHA-512 use the algorithm number TBD.

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.

This needs a real example - this copied example of P-256

Some of the material in this document is copied liberally from RFC 6605.

This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entry have been added to the registry: Number TBD Description Ed25519 with SHA-512 Mnemonic Ed25519SHA512 Zone Signing Y Trans. Sec. * Reference This document * There has been no determination of standardization of the use of this algorithm with Transaction Security.

Ed25519 is targeted to provide attack resistance comparable to quality 128-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. The security considerations listed in RFC 4509 apply here as well.