Cryptographic Algorithm and Key Usage Update to DKIMKitterman Technical Services3611 Scheel DrEllicott CityMD21042+1 301 325-5475scott@kitterman.comThe cryptographic algorithm and key size requirements included when DKIM
was designed in the last decade are functionally obsolete and in need of
immediate revision. This document updates DKIM requirements to those
minimaly suitable for operation with currently specified algorithms. This
document updates RFC 6376.Discussion about this draft is directed to the
dcrup@ietf.org mailing list.DKIM signs e-mail messages, by creating hashes of the message
headers and content and signing the header hash with a digital signature.
Message recipients fetch the signature verification key from the DNS where it is
stored in a TXT record.
The defining documents specify a single signing algorithm, RSA,
and recommends key sizes of 1024 to 2048 bits (but require verification of 512 bit keys).
As discussed in US-CERT VU#268267, the operational
community has recognized that shorter keys compromise the effectiveness of DKIM.
While 1024 bit signatures are common, stronger signatures are not. Widely used DNS
configuration software places a practical limit on key sizes, because the software only
handles a single 256 octet string in a TXT record, and RSA keys longer than 1024 bits don't
fit in 256 octets.
The capitalized 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
.This section replaces Section 3.3 in its
entirety.Generally, DKIM supports multiple digital signature algorithms. One
algorithms, rsa-sha256, is currenlty defined. Signers MUST implement and
sign using rsa-sha256. Verifiers MUST implement rsa-sha256.The rsa-sha256 Signing Algorithm computes a message hash as described in
, Section 3.7 using SHA-256 [FIPS-180-3-2008] as
the hash-alg. That hash is then signed by the Signer using the RSA
algorithm (defined in PKCS#1 version 1.5 ) as the
crypt-alg and the Signer's private key. The hash MUST NOT be truncated or
converted into any form other than the native binary form before being
signed. The signing algorithm SHOULD use a public exponent of 65537.Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
all keys. Verifiers MUST be able to validate signatures with
keys ranging from 1024 bits to 4096 bits, and they MAY be able to
validate signatures with larger keys. Verifier policies can use the
length of the signing key as one metric for determining whether a
signature is acceptable.Factors that should influence the key size choice include the
following:
The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packetThe security constraint that keys smaller than 2048 bits may be
subject to off-line attacksLarger keys impose higher CPU costs to verify and sign emailKeys can be replaced on a regular basis; thus, their lifetime can
be relatively shortThe security goals of DKIM,, are modest
compared to typical goals of other systems that employ digital
signaturesSee for further discussion on selecting key
sizes.Other algorithms will be defined in the future. Verifiers MUST ignore
any signatures using algorithms that they do not implement.This section updates the a= tag in Section 3.5.The text description of the tag is now:
The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha256"; Signers MUST sign using
"rsa-sha256". See Section 3.3 (as updated by this
document) for a description of the algorithms.The following ABNF element is updated:This section updates the h= tag in Section 3.6.1.The following ABNF element is updated: This document does not change the Security Considerations of
. It reduces the risk of signature compromise
due to weak cryptography. The SHA-1 risks discussed in
Section 3 are resolved due to the removal of
rsa-sha1 from DKIM..IANA is requested to update registries as follows.
The following value is changed in the DKIM Hash AlgorithmsTYPEREFERENCESTATUSsha1(this document)obsoleteVulnerability Note VU#268267, DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trustUS-CERT The author wishes to acknowledge the following for their
review and comment on this proposal:
Kurt Andersen, Murray S. Kucherawy, Martin Thomson, John Levine,
Russ Housley, and Jim Fenton. Thanks to John Levine for draft-ietf-dcrup-dkim-crypto-00, which was
the source for much of the introductory material in this draft.