Document shepherd writeup for draft-ietf-dcrup-dkim-crypto-09
The Document Shepherd for this document is Jim Fenton. The responsible Area Director is Alexey Melnikov.
DKIM [RFC6376] signs e-mail messages, by creating hashes of the message headers and body and signing the header hash with a digital signature. Message recipients fetch the signature verification key from the DNS. The defining documents specify a single signing algorithm, RSA [RFC3447].
This document adds a new stronger signing algorithm, Edwards-Curve Digital Signature Algorithm using the Curve25519 curve (ed25519), which has much shorter keys than RSA for similar levels of security. This is important in overcoming the practical limitations in storing long keys in DNS.
Publication is being requested as a Proposed Standard ("Standards Track" in the draft).
2. Review and Consensus
This document represents the consensus of the dcrup working group. The need for longer DKIM signing keys has become more acute as compute power (and therefore the ability to factor short RSA keys) increases. Initially, two approaches were considered: (1) publication of key fingerprints (hashes), rather than RSA keys in DNS; (2) use of the ed25519 signing algorithm, which has shorter keys for equivalent cryptographic strength. Ultimately, approach (1) was discarded because (2) was sufficient to satisfy the goals of the specification. There was also significant dicussion on the format to be used for publishing ed25529 public keys in DNS; a "raw key" format was adopted (without ASN1/DER wrapping).
The specification has received extensive review from significant members of the email community and input (such as algorithm selection) from WG technical advisor Eric Rescorla.
Multiple interoperating implementations exist, including dkimpy-milter, exim, NoSpamProxy, and OpenDKIM.
3. Intellectual property
One IPR disclosure (#3025) was filed regarding this draft, but this is no longer applicable because the disclosure related to the use of RSA fingerprints, which has been removed in an earlier revision.
No other IPR claims are known.
4. Other Points
This document contains a normative reference to RFC 8032, an informational RFC that describes ed25519. This is consistent with current practice; RFC 8032 is already listed on the Downref Registry because of a similar reference in RFC 8037.
This document also contains a normative reference to RFC 3447, which has been obsoleted by RFC 8017.
All references are listed as normative; it is possible that there is at least one informative reference (most likely the reference to RFC 3447).
There is also a reference to a NIST FIPS standard. While not an IETF document, we consider it sufficiently stable to be normatively referenced in a standards-track document.
Section 9.2 (URIs) and the Discussion Venue reference in the introduction should be removed by the RFC editor at publication.
In the opinion of the shepherd, the document is ready for publication.