Build | | GitHub | Twitter

This document provide note and summary of RFC 4686, Analysis of Threats Motivating DomainKeys Identified Mail (DKIM).

1. Introduction

The DKIM protocol defines a mechanism by which email messages can be cryptographically signed by Message Submission Agent (MSA) based on domain name. Recipients then can verify the signature by querying the signer’s domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain.

1.1. Terminology and Model

An administrative unit (AU) is the portion of the path of an email message that is under common administration.

The following diagram illustrates a typical usage flowchart for DKIM:

                      |       SIGNATURE CREATION        |
                      |  (Originating or Relaying AU)   |
                      |                                 |
                      |   Sign (Message, Domain, Key)   |
                      |                                 |
                                       | - Message (Domain, Key)
     +-----------+    |     SIGNATURE VERIFICATION      |
     |           |    |  (Relaying or Delivering AU)    |
     |    KEY    |    |                                 |
     |   QUERY   +--->|  Verify (Message, Domain, Key)  |
     |           |    |                                 |
     +-----------+    +----------------+----------------+
                                       |  - Verified Domain
     +-----------+                     V  - [Report]
     |  SENDER   |    +----------------+----------------+
     |  SIGNING  |    |                                 |
     | PRACTICES +--->|        SIGNER EVALUATION        |
     |   QUERY   |    |                                 |
     +-----------+    +---------------------------------+

DKIM operates entirely on the content (body and selected header fields) of the message.

The following definitions were used as rough criteria for scoring the attacks:

  • Impact:

    • High: Affects the verification of messages from an entire domain or multiple domains

    • Medium: Affects the verification of messages from specific users, Mail Transfer Agents (MTAs), and/or bounded time periods

    • Low: Affects the verification of isolated individual messages only

  • Likelihood:

    • High: All email users should expect this attack on a frequent basis

    • Medium: Email users should expect this attack occasionally; frequently for a few users

    • Low: Attack is expected to be rare and/or very infrequent

2. The Bad Actors

The bad actors are expected to have access to the following:

  • An extensive corpus of messages from domains they might wish to impersonate

  • Knowledge of the business aims and model for domains they might wish to impersonate

  • Access to public keys and associated authorization records associated with the domain

The bad actors are expected to be able to,

  • Submit messages to MTAs MSAs at multiple locations in the Internet

  • Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents

  • Sign messages on behalf of domains under their control

  • Generate substantial numbers of either unsigned or apparently-signed messages that might be used to attempt a denial-of-service attack

  • Resend messages that may have been previously signed by the domain

  • Transmit messages using any envelope information desired

  • Act as an authorized submitter for messages from a compromised computer

  • Manipulation of IP routing. This could be used to submit messages from specific IP addresses or difficult-to-trace addresses, or to cause diversion of messages to a specific domain.

  • Limited influence over portions of DNS using mechanisms such as cache poisoning. This might be used to influence message routing or to falsify advertisements of DNS-based keys or signing practices.

  • Access to significant computing resources, for example, through the conscription of worm-infected "zombie" computers. This could allow the bad actor to perform various types of brute-force attacks.

  • Ability to eavesdrop on existing traffic, perhaps from a wireless network.

2.1. Location

The bad actors can reside inside the AU or outside the AU.

External bad actors usually try to send unwanted message to local mailbox, either without signature, with incorrect signature, or valid signature.

When the bad actors come from inside, DKIM is not directly effective because the signature is generated after the message has been submitted. One of defense againts internal bad actors is by applying authentication to MSA.

3. Representative Bad Acts

One of the most fundamental bad acts being attempted is the delivery of messages that are not intended to have been sent by the alleged originating domain.

3.1. Use of Arbitrary Identities

DKIM is not effective against the use of addresses controlled by bad actors.

Accreditation and reputation systems and locally-maintained whitelists and blacklists can be used to enhance the accountability of DKIM-verified addresses and/or the likelihood that signed messages are desirable.

3.2. Use of Specific Identities

DKIM is not effective against the domains controlled by bad actors.

DKIM is effective against the use of specific identities only when there is an expectation that such messages will, in fact, be signed. The primary means for establishing this is the use of Sender Signing Practices (SSP).

3.2.1. Exploitation of Social Relationships

DKIM could be effective in mitigating these acts by limiting the scope of origin addresses for which a valid signature can be obtained when sending the messages from other locations.

DKIM is effective in defending against the fraudulent use of origin addresses on signed messages. When the published sender signing practices of the origin address indicate that all messages from that address should be signed, DKIM further mitigates against the attempted fraudulent use of the origin address on unsigned messages.

3.2.3. Reputation Attacks

It is for this reason that reputation systems must be based on an identity that is, in practice, fairly reliable.

3.2.4. Reflection Attacks

It is common and useful practice for a message’s return path not to correspond to the origin address. For these reasons, DKIM is not effective against reflection attacks.

4. Attacks on Message Signing

4.1. Attacks against Message Signatures

The following is a summary of postulated attacks against DKIM signatures:

| Attack Name                                            | Impact | Likelihood

| Theft of private key for domain                        | High   | Low
| Theft of delegated private key                         | Medium | Medium
| Private key recovery via side channel attack           | High   | Low
| Chosen message replay                                  | Low    | Medium/High
| Signed message replay                                  | Low    | High
| Denial-of-service attack against verifier              | High   | Medium
| Denial-of-service attack against key service           | High   | Medium
| Canonicalization abuse                                 | Low    | Medium
| Body length limit abuse                                | Medium | Medium
| Use of revoked key                                     | Medium | Low
| Compromise of key server                               | High   | Low
| Falsification of key service replies                   | Medium | Medium
| Publication of malformed key records and/or signatures | High   | Low
| Cryptographic weaknesses in signature generation       | High   | Low
| Display name abuse                                     | Medium | High
| Compromised system within originator's network         | High   | Medium
| Verification probe attack                              | Medium | Medium
| Key publication by higher-level domain                 | High   | Low

4.2. Attacks against Message Signing Practices

The following is a summary of postulated attacks against signing practices:

| Attack Name                                          | Impact | Likelihood

| Look-alike domain names                              | High   | High
| Internationalized domain name abuse                  | High   | High
| Denial-of-service attack against signing practices   | Medium | Medium
| Use of multiple From addresses                       | Low    | Medium
| Abuse of third-party signatures                      | Medium | High
| Falsification of Sender Signing Practices replies    | Medium | Medium

4.3. Other Attacks

| Attack Name                          | Impact | Likelihood

| Packet amplification attacks via DNS |   N/A  |   Medium

5. Derived Requirements

These requirements include:

  • The store for key and SSP records must be capable of utilizing multiple geographically-dispersed servers.

  • Key and SSP records must be cacheable, either by the verifier requesting them or by other infrastructure.

  • The cache time-to-live for key records must be specifiable on a per-record basis.

  • The signature algorithm identifier in the message must be one of the ones listed in a key record for the identified domain.

  • The algorithm(s) used for message signatures need to be secure against expected cryptographic developments several years in the future.