# Software Engineering Institute

## DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust

#### Vulnerability Note VU#268267

Original Release Date: 2012-10-24 | Last Revised: 2016-03-16

### Overview

DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust when messages are signed using keys that are too weak (< 1024 bits) or that are marked as test keys.

### Description

 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.A DKIM-compliant email client, including web-based clients, should not convey any DKIM-related trust to the user about messages in testing mode.2) CWE-326: Inadequate Encryption Strength: DKIM signing keys with fewer than 1024 bits are weak. From RFC 6376: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.

### Impact

 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.

### Solution

 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."

### Vendor Information

268267

Notified:  August 22, 2012 Updated: October 23, 2012

Affected

### Vendor Statement

We have not received a statement from the vendor.

### Vendor Information

We are not aware of further vendor information regarding this vulnerability.

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

### Microsoft Corporation Affected

Notified:  August 22, 2012 Updated: October 23, 2012

Affected

### Vendor Statement

We have not received a statement from the vendor.

### Vendor Information

We are not aware of further vendor information regarding this vulnerability.

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

### Yahoo, Inc. Affected

Notified:  August 22, 2012 Updated: October 23, 2012

Affected

### Vendor Statement

We have not received a statement from the vendor.

### Vendor Information

We are not aware of further vendor information regarding this vulnerability.

This vendor was reported to have one or many domains affected by either of this vulnerabilities.

### Bluehost Unknown

Updated:  March 11, 2016

Unknown

### Vendor Statement

We have not received a statement from the vendor.

### Vendor Information

We are not aware of further vendor information regarding this vulnerability.

### Yandex Unknown

Updated:  March 15, 2016

Unknown

### Vendor Statement

We have not received a statement from the vendor.

### Vendor Information

We are not aware of further vendor information regarding this vulnerability.

### CVSS Metrics

Group Score Vector
Base 4.6 AV:N/AC:H/Au:M/C:C/I:N/A:N
Temporal 3.5 E:U/RL:U/RC:UC
Environmental 6.1 CDP:MH/TD:H/CR:ND/IR:ND/AR:ND

### Acknowledgements

Thanks to Zachary Harris for reporting this vulnerability.

This document was written by Michael Orlando.

### Other Information

 CVE IDs: None Date Public: 2012-10-23 Date First Published: 2012-10-24 Date Last Updated: 2016-03-16 01:55 UTC Document Revision: 46