Software Engineering Institute

RFC 6376 states "DomainKeys Identified Mail (DKIM) permits a person, role, or organization to claim some responsibility for a message by associating a domain name [RFC1034] with the message [RFC5322], which they are authorized to use. This can be an author's organization, an operational relay, or one of their agents. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. A message can contain multiple signatures, from the same or different organizations involved with the message."

1) CWE-347: Improper Verification of Cryptographic Signature: DKIM information is conveyed in an email header called a DKIM-Signature header field. A Signer can indicate that a domain is testing DKIM by setting the DKIM Selector Flag (t=) flag to t=y. Some verifiers accept DKIM messages in testing mode when the messages should be treated as if they were not DKIM signed. From RFC 6376:

t= Flags, represented as a colon-separated list of names (plain-   text; OPTIONAL, default is no flags set).  Unrecognized flags MUST   be ignored.  The defined flags are as follows:   y  This domain is testing DKIM.  Verifiers MUST NOT treat messages      from Signers in testing mode differently from unsigned email,      even should the signature fail to verify.

Since short RSA keys more easily succumb to off-line attacks,   Signers MUST use RSA keys of at least 1024 bits for long-lived   keys.

The standard lists other factors that influence the choice of key size, implying that 1024-bit keys are not always necessary if the Signer assumes the risk that smaller keys will not be cracked before the message is verified, the signature expires, or the Signer stops using the key. Note that key sizes up to and including RSA-768 have been factored.

The standard does not require Verifiers to reject signatures made by keys with fewer than 1024 bits, however Verifiers may distinguish between e.g. signatures made with 512-bit keys or 1024 bit keys. It may be an important to recipients to know whether or not a DKIM signature could have been spoofed by an attacker who was able to factor a small RSA key.

Furthermore, a number of RSA keys of fewer than 1024 bits are used in production environments. Check the length of DKIM keys and consider using 1024 bit or longer keys, particularly for long-lived keys.

To identify keys with fewer than 1024 bits or test keys users are advised to inspect the server's RSA signing key.

It is possible that an attacker could factor the encryption key for a domain that is using DKIM allowing them to sign emails originating from that domain. An attacker may be able to use a test signing key that is treated as trusted.

System administrators should replace all RSA signing keys fewer that 1024 bits and configure their systems to not use or allow testing mode on production servers.

Users of OpenDKIM are advised to upgrade to 2.6.8 or 2.7.0 and above. The vendor had stated, "In both releases, signatures with key sizes below a configurable limit will be automatically restricted from yielding a "pass" result, and such keys will not be allowed to be used for signature generation. The limit will default to 1024. This applies both to the filter and the library."