RFC's
RFC 4686 - Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Network Working Group                                          J. Fenton

Request for Comments: 4686 Cisco Systems, Inc.

Category: Informational September 2006

Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Status of This Memo

This memo provides information for the Internet community. It does

not specify an Internet standard of any kind. Distribution of this

memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2006).

Abstract

This document provides an analysis of some threats against Internet

mail that are intended to be addressed by signature-based mail

authentication, in particular DomainKeys Identified Mail. It

discusses the nature and location of the bad actors, what their

capabilities are, and what they intend to accomplish via their

attacks.

Fenton Informational [Page 1]

RFC 4686 DKIM Threat Analysis September 2006

Table of Contents

1. Introduction ....................................................3

1.1. Terminology and Model ......................................3

1.2. Document Structure .........................................5

2. The Bad Actors ..................................................6

2.1. Characteristics ............................................6

2.2. Capabilities ...............................................6

2.3. Location ...................................................8

2.3.1. Externally-Located Bad Actors .......................8

2.3.2. Within Claimed Originator's Administrative Unit .....8

2.3.3. Within Recipient's Administrative Unit ..............9

3. Representative Bad Acts .........................................9

3.1. Use of Arbitrary Identities ................................9

3.2. Use of Specific Identities ................................10

3.2.1. Exploitation of Social Relationships ...............10

3.2.2. Identity-Related Fraud .............................11

3.2.3. Reputation Attacks .................................11

3.2.4. Reflection Attacks .................................11

4. Attacks on Message Signing .....................................12

4.1. Attacks against Message Signatures ........................12

4.1.1. Theft of Private Key for Domain ....................13

4.1.2. Theft of Delegated Private Key .....................13

4.1.3. Private Key Recovery via Side Channel Attack .......14

4.1.4. Chosen Message Replay ..............................14

4.1.5. Signed Message Replay ..............................16

4.1.6. Denial-of-Service Attack against Verifier ..........16

4.1.7. Denial-of-Service Attack against Key Service .......17

4.1.8. Canonicalization Abuse .............................17

4.1.9. Body Length Limit Abuse ............................17

4.1.10. Use of Revoked Key ................................18

4.1.11. Compromise of Key Server ..........................18

4.1.12. Falsification of Key Service Replies ..............19

4.1.13. Publication of Malformed Key Records

and/or Signatures .................................19

4.1.14. Cryptographic Weaknesses in Signature Generation ..20

4.1.15. Display Name Abuse ................................21

4.1.16. Compromised System within Originator's Network ....21

4.1.17. Verification Probe Attack .........................21

4.1.18. Key Publication by Higher-Level Domain ............22

4.2. Attacks against Message Signing Practices .................23

4.2.1. Look-Alike Domain Names ............................23

4.2.2. Internationalized Domain Name Abuse ................23

4.2.3. Denial-of-Service Attack against Signing

Practices ..........................................24

4.2.4. Use of Multiple From Addresses .....................24

4.2.5. Abuse of Third-Party Signatures ....................24

4.2.6. Falsification of Sender Signing Practices Replies ..25

Fenton Informational [Page 2]

RFC 4686 DKIM Threat Analysis September 2006

4.3. Other Attacks .............................................25

4.3.1. Packet Amplification Attacks via DNS ...............25

5. Derived Requirements ...........................................26

6. Security Considerations ........................................26

7. Informative References .........................................27

Appendix A. Acknowledgements ......................................28

1. Introduction

The DomainKeys Identified Mail (DKIM) protocol is being specified by

the IETF DKIM Working Group. The DKIM protocol defines a mechanism

by which email messages can be cryptographically signed, permitting a

signing domain to claim responsibility for the use of a given email

address. Message recipients 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. This document

addresses threats relative to two works in progress by the DKIM

Working Group, the DKIM signature specification [DKIM-BASE] and DKIM

Sender Signing Practices [DKIM-SSP].

Once the attesting party or parties have been established, the

recipient may evaluate the message in the context of additional

information such as locally-maintained whitelists, shared reputation

services, and/or third-party accreditation. The description of these

mechanisms is outside the scope of the IETF DKIM Working Group

effort. By applying a signature, a good player enables a verifier to

associate a positive reputation with the message, in hopes that it

will receive preferential treatment by the recipient.

This effort is not intended to address threats associated with

message confidentiality nor does it intend to provide a long-term

archival signature.

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 originator and

recipient typically develop trust relationships with the

administrative units that send and receive their email, respectively,

to perform the signing and verification of their messages.

The origin address is the address on an email message, typically the

RFC 2822 From: address, which is associated with the alleged author

of the message and is displayed by the recipient's Mail User Agent

(MUA) as the source of the message.

Fenton Informational [Page 3]

RFC 4686 DKIM Threat Analysis September 2006

The following diagram illustrates a typical usage flowchart for DKIM:

+---------------------------------+

| SIGNATURE CREATION |

| (Originating or Relaying AU) |

| |

| Sign (Message, Domain, Key) |

| |

+---------------------------------+

| - Message (Domain, Key)

|

[Internet]

|

V

+---------------------------------+

+-----------+ | 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, as defined in RFC 2822 [RFC2822]. The

transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and

such elements as the envelope-from and envelope-to addresses and the

HELO domain are not relevant to DKIM verification. This is an

intentional decision made to allow verification of messages via

protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]

which an MUA acting as a verifier might use.

The Sender Signing Practices Query referred to in the diagram above

is a means by which the verifier can query the alleged author's

domain to determine their practices for signing messages, which in

turn may influence their evaluation of the message. If, for example,

a message arrives without any valid signatures, and the alleged

author's domain advertises that they sign all messages, the verifier

might handle that message differently than if a signature was not

necessarily to be expected.

Fenton Informational [Page 4]

RFC 4686 DKIM Threat Analysis September 2006

1.2. Document Structure

The remainder of this document describes the problems that DKIM might

be expected to address, and the extent to which it may be successful

in so doing. These are described in terms of the potential bad

actors, their capabilities and location in the network, and the bad

acts that they might wish to commit.

This is followed by a description of postulated attacks on DKIM

message signing and on the use of Sender Signing Practices to assist

in the treatment of unsigned messages. A list of derived

requirements is also presented, which is intended to guide the DKIM

design and review process.

The sections dealing with attacks on DKIM each begin with a table

summarizing the postulated attacks in each category along with their

expected impact and likelihood. 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

Fenton Informational [Page 5]

RFC 4686 DKIM Threat Analysis September 2006

2. The Bad Actors

2.1. Characteristics

The problem space being addressed by DKIM is characterized by a wide

range of attackers in terms of motivation, sophistication, and

capabilities.

At the low end of the spectrum are bad actors who may simply send

email, perhaps using one of many commercially available tools, that

the recipient does not want to receive. These tools typically allow

one to falsify the origin address of messages, and may, in the

future, be capable of generating message signatures as well.

At the next tier are what would be considered "professional" senders

of unwanted email. These attackers would deploy specific

infrastructure, including Mail Transfer Agents (MTAs), registered

domains and networks of compromised computers ("zombies") to send

messages, and in some cases to harvest addresses to which to send.

These senders often operate as commercial enterprises and send

messages on behalf of third parties.

The most sophisticated and financially-motivated senders of messages

are those who stand to receive substantial financial benefit, such as

from an email-based fraud scheme. These attackers can be expected to

employ all of the above mechanisms and additionally may attack the

Internet infrastructure itself, including DNS cache-poisoning attacks

and IP routing attacks.

2.2. Capabilities

In general, the bad actors described above should be expected to have

access to the following:

1. An extensive corpus of messages from domains they might wish to

impersonate

2. Knowledge of the business aims and model for domains they might

wish to impersonate

3. Access to public keys and associated authorization records

associated with the domain

and the ability to do at least some of the following:

1. Submit messages to MTAs and Message Submission Agents (MSAs) at

multiple locations in the Internet

Fenton Informational [Page 6]

RFC 4686 DKIM Threat Analysis September 2006

2. Construct arbitrary message header fields, including those

claiming to be mailing lists, resenders, and other mail agents

3. Sign messages on behalf of domains under their control

4. Generate substantial numbers of either unsigned or apparently-

signed messages that might be used to attempt a denial-of-service

attack

5. Resend messages that may have been previously signed by the

domain

6. Transmit messages using any envelope information desired

7. Act as an authorized submitter for messages from a compromised

computer

As noted above, certain classes of bad actors may have substantial

financial motivation for their activities, and therefore should be

expected to have more capabilities at their disposal. These include:

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

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

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

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

network.

Either of the first two of these mechanisms could be used to allow

the bad actor to function as a man-in-the-middle between author and

recipient, if that attack is useful.

Fenton Informational [Page 7]

RFC 4686 DKIM Threat Analysis September 2006

2.3. Location

Bad actors or their proxies can be located anywhere in the Internet.

Certain attacks are possible primarily within the administrative unit

of the claimed originator and/or recipient domain have capabilities

beyond those elsewhere, as described in the below sections. Bad

actors can also collude by acting from multiple locations (a

"distributed bad actor").

It should also be noted that with the use of "zombies" and other

proxies, externally-located bad actors may gain some of the

capabilities of being located within the claimed originator's or

recipient's administrative unit. This emphasizes the importance of

appropriate security measures, such as authenticated submission of

messages, even within administrative units.

2.3.1. Externally-Located Bad Actors

DKIM focuses primarily on bad actors located outside of the

administrative units of the claimed originator and the recipient.

These administrative units frequently correspond to the protected

portions of the network adjacent to the originator and recipient. It

is in this area that the trust relationships required for

authenticated message submission do not exist and do not scale

adequately to be practical. Conversely, within these administrative

units, there are other mechanisms such as authenticated message

submission that are easier to deploy and more likely to be used than

DKIM.

External bad actors are usually attempting to exploit the "any to

any" nature of email that motivates most recipient MTAs to accept

messages from anywhere for delivery to their local domain. They may

generate messages without signatures, with incorrect signatures, or

with correct signatures from domains with little traceability. They

may also pose as mailing lists, greeting cards, or other agents that

legitimately send or resend messages on behalf of others.

2.3.2. Within Claimed Originator's Administrative Unit

Bad actors in the form of rogue or unauthorized users or malware-

infected computers can exist within the administrative unit

corresponding to a message's origin address. Since the submission of

messages in this area generally occurs prior to the application of a

message signature, DKIM is not directly effective against these bad

actors. Defense against these bad actors is dependent upon other

means, such as proper use of firewalls, and Message Submission Agents

that are configured to authenticate the author.

Fenton Informational [Page 8]

RFC 4686 DKIM Threat Analysis September 2006

In the special case where the administrative unit is non-contiguous

(e.g., a company that communicates between branches over the external

Internet), DKIM signatures can be used to distinguish between

legitimate externally-originated messages and attempts to spoof

addresses in the local domain.

2.3.3. Within Recipient's Administrative Unit

Bad actors may also exist within the administrative unit of the

message recipient. These bad actors may attempt to exploit the trust

relationships that exist within the unit. Since messages will

typically only have undergone DKIM verification at the administrative

unit boundary, DKIM is not effective against messages submitted in

this area.

For example, the bad actor may attempt to spoof a header field

indicating the results of verification. This header field would

normally be added by the verifier, which would also detect spoofed

header fields on messages it was attempting to verify. This could be

used to falsely indicate that the message was authenticated

successfully.

As in the originator case, these bad actors can be dealt with by

controlling the submission of messages within the administrative

unit. Since DKIM permits verification to occur anywhere within the

recipient's administrative unit, these threats can also be minimized

by moving verification closer to the recipient, such as at the Mail

Delivery Agent (MDA), or on the recipient's MUA itself.

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. As described above, these messages might merely

be unwanted by the recipient, or might be part of a confidence scheme

or a delivery vector for malware.

3.1. Use of Arbitrary Identities

This class of bad acts includes the sending of messages that aim to

obscure the identity of the actual author. In some cases, the actual

sender might be the bad actor, or in other cases might be a third-

party under the control of the bad actor (e.g., a compromised

computer).

Particularly when coupled with sender signing practices that indicate

the domain owner signs all messages, DKIM can be effective in

mitigating against the abuse of addresses not controlled by bad

Fenton Informational [Page 9]

RFC 4686 DKIM Threat Analysis September 2006

actors. DKIM is not effective against the use of addresses

controlled by bad actors. In other words, the presence of a valid

DKIM signature does not guarantee that the signer is not a bad actor.

It also does not guarantee the accountability of the signer, since

DKIM does not attempt to identify the signer individually, but rather

identifies the domain that they control. 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

A second major class of bad acts involves the assertion of specific

identities in email.

Note that some bad acts involving specific identities can sometimes

be accomplished, although perhaps less effectively, with similar

looking identities that mislead some recipients. For example, if the

bad actor is able to control the domain "examp1e.com" (note the "one"

between the p and e), they might be able to convince some recipients

that a message from admin@examp1e.com is really from

admin@example.com. Similar types of attacks using internationalized

domain names have been hypothesized where it could be very difficult

to see character differences in popular typefaces. Similarly, if

example2.com was controlled by a bad actor, the bad actor could sign

messages from bigbank.example2.com, which might also mislead some

recipients. To the extent that these domains are controlled by bad

actors, DKIM is not effective against these attacks, although it

could support the ability of reputation and/or accreditation systems

to aid the user in identifying them.

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), which will be specified by the IETF DKIM Working

Group.

3.2.1. Exploitation of Social Relationships

One reason for asserting a specific origin address is to encourage a

recipient to read and act on particular email messages by appearing

to be an acquaintance or previous correspondent that the recipient

might trust. This tactic has been used by email-propagated malware

that mail themselves to addresses in the infected host's address

book. In this case, however, the author's address may not be

falsified, so DKIM would not be effective in defending against this

act.

Fenton Informational [Page 10]

RFC 4686 DKIM Threat Analysis September 2006

It is also possible for address books to be harvested and used by an

attacker to post messages from elsewhere. 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.

3.2.2. Identity-Related Fraud

Bad acts related to email-based fraud often, but not always, involve

the transmission of messages using specific origin addresses of other

entities as part of the fraud scheme. The use of a specific address

of origin sometimes contributes to the success of the fraud by

helping convince the recipient that the message was actually sent by

the alleged author.

To the extent that the success of the fraud depends on or is enhanced

by the use of a specific origin address, the bad actor may have

significant financial motivation and resources to circumvent any

measures taken to protect specific addresses from unauthorized use.

When signatures are verified by or for the recipient, 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

Another motivation for using a specific origin address in a message

is to harm the reputation of another, commonly referred to as a

"joe-job". For example, a commercial entity might wish to harm the

reputation of a competitor, perhaps by sending unsolicited bulk email

on behalf of that competitor. 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

A commonly-used tactic by some bad actors is the indirect

transmission of messages by intentionally mis-addressing the message

and causing it to be "bounced", or sent to the return address (RFC

2821 envelope-from address) on the message. In this case, the

specific identity asserted in the email is that of the actual target

of the message, to whom the message is "returned".

DKIM does not, in general, attempt to validate the RFC2821.mailfrom

return address on messages, either directly (noting that the mailfrom

Fenton Informational [Page 11]

RFC 4686 DKIM Threat Analysis September 2006

address is an element of the SMTP protocol, and not the message

content on which DKIM operates), or via the optional Return-Path

header field. Furthermore, as is noted in Section 4.4 of RFC 2821

[RFC2821], 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

Bad actors can be expected to exploit all of the limitations of

message authentication systems. They are also likely to be motivated

to degrade the usefulness of message authentication systems in order

to hinder their deployment. Both the signature mechanism itself and

declarations made regarding use of message signatures (referred to

here as Sender Signing Practices or SSP) can be expected to be the

target of attacks.

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 | M/H |

| 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 | High | Low |

| signatures | | |

| Cryptographic weaknesses in signature | High | Low |

| generation | | |

| Display name abuse | Medium | High |

| Compromised system within originator's | High | Medium |

| network | | |

| Verification probe attack | Medium | Medium |

| Key publication by higher-level domain | High | Low |

+---------------------------------------------+--------+------------+

Fenton Informational [Page 12]

RFC 4686 DKIM Threat Analysis September 2006

4.1.1. Theft of Private Key for Domain

Message signing technologies such as DKIM are vulnerable to theft of

the private keys used to sign messages. This includes "out-of-band"

means for this theft, such as burglary, bribery, extortion, and the

like, as well as electronic means for such theft, such as a

compromise of network and host security around the place where a

private key is stored.

Keys that are valid for all addresses in a domain typically reside in

MTAs that should be located in well-protected sites, such as data

centers. Various means should be employed for minimizing access to

private keys, such as non-existence of commands for displaying their

value, although ultimately memory dumps and the like will probably

contain the keys. Due to the unattended nature of MTAs, some

countermeasures, such as the use of a pass phrase to "unlock" a key,

are not practical to use. Other mechanisms, such as the use of

dedicated hardware devices that contain the private key and perform

the cryptographic signature operation, would be very effective in

denying export of the private key to those without physical access to

the device. Such devices would almost certainly make the theft of

the key visible, so that appropriate action (revocation of the

corresponding public key) can be taken should that happen.

4.1.2. Theft of Delegated Private Key

There are several circumstances where a domain owner will want to

delegate the ability to sign messages for the domain to an individual

user or a third party associated with an outsourced activity such as

a corporate benefits administrator or a marketing campaign. Since

these keys may exist on less well-protected devices than the domain's

own MTAs, they will in many cases be more susceptible to compromise.

In order to mitigate this exposure, keys used to sign such messages

can be restricted by the domain owner to be valid for signing

messages only on behalf of specific addresses in the domain. This

maintains protection for the majority of addresses in the domain.

A related threat is the exploitation of weaknesses in the delegation

process itself. This threat can be mitigated through the use of

customary precautions against the theft of private keys and the

falsification of public keys in transit. For example, the exposure

to theft can be minimized if the delegate generates the keypair to be

used, and sends the public key to the domain owner. The exposure to

falsification (substitution of a different public key) can be reduced

if this transmission is signed by the delegate and verified by the

domain owner.

Fenton Informational [Page 13]

RFC 4686 DKIM Threat Analysis September 2006

4.1.3. Private Key Recovery via Side Channel Attack

All popular digital signature algorithms are subject to a variety of

side channel attacks. The most well-known of these are timing

channels [Kocher96], power analysis [Kocher99], and cache timing

analysis [Bernstein04]. Most of these attacks require either

physical access to the machine or the ability to run processes

directly on the target machine. Defending against these attacks is

out of scope for DKIM.

However, remote timing analysis (at least on local area networks) is

known to be feasible [Boneh03], particularly in server-type platforms

where the attacker can inject traffic that will immediately be

subject to the cryptographic operation in question. With enough

samples, these techniques can be used to extract private keys even in

the face of modest amounts of noise in the timing measurements.

The three commonly proposed countermeasures against timing analysis

are:

1. Make the operation run in constant time. This turns out in

practice to be rather difficult.

2. Make the time independent of the input data. This can be

difficult, but see [Boneh03] for more details.

3. Use blinding. This is generally considered the best current

practice countermeasure, and while not proved generally secure is

a countermeasure against known timing attacks. It adds about

2-10% to the cost of the operation and is implemented in many

common cryptographic libraries. Unfortunately, Digital Signature

Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have

standard methods though some defenses may exist.

Note that adding random delays to the operation is only a partial

countermeasure. Because the noise is generally uniformly

distributed, a large enough number of samples can be used to average

it out and extract an accurate timing signal.

4.1.4. Chosen Message Replay

Chosen message replay refers to the scenario where the attacker

creates a message and obtains a signature for it by sending it

through an MTA authorized by the originating domain to

himself/herself or an accomplice. They then "replay" the signed

message by sending it, using different envelope addresses, to a

(typically large) number of other recipients.

Fenton Informational [Page 14]

RFC 4686 DKIM Threat Analysis September 2006

Due to the requirement to get an attacker-generated message signed,

chosen message replay would most commonly be experienced by consumer

ISPs or others offering email accounts to clients, particularly where

there is little or no accountability to the account holder (the

attacker in this case). One approach to solving this problem is for

the domain to only sign email for clients that have passed a vetting

process to provide traceability to the message originator in the

event of abuse. At present, the low cost of email accounts (zero)

does not make it practical for any vetting to occur. It remains to

be seen whether this will be the model with signed mail as well, or

whether a higher level of trust will be required to obtain an email

signature.

A variation on this attack involves the attacker sending a message

with the intent of obtaining a signed reply containing their original

message. The reply might come from an innocent user or might be an

automatic response such as a "user unknown" bounce message. In some

cases, this signed reply message might accomplish the attacker's

objectives if replayed. This variation on chosen message replay can

be mitigated by limiting the extent to which the original content is

quoted in automatic replies, and by the use of complementary

mechanisms such as egress content filtering.

Revocation of the signature or the associated key is a potential

countermeasure. However, the rapid pace at which the message might

be replayed (especially with an army of "zombie" computers), compared

with the time required to detect the attack and implement the

revocation, is likely to be problematic. A related problem is the

likelihood that domains will use a small number of signing keys for a

large number of customers, which is beneficial from a caching

standpoint but is likely to result in a great deal of collateral

damage (in the form of signature verification failures) should a key

be revoked suddenly.

Signature revocation addresses the collateral damage problem at the

expense of significant scaling requirements. At the extreme,

verifiers could be required to check for revocation of each signature

verified, which would result in very significant transaction rates.

An alternative, "revocation identifiers", has been proposed, which

would permit revocation on an intermediate level of granularity,

perhaps on a per-account basis. Messages containing these

identifiers would result in a query to a revocation database, which

might be represented in DNS.

Further study is needed to determine if the benefits from revocation

(given the potential speed of a replay attack) outweigh the

transactional cost of querying a revocation database.

Fenton Informational [Page 15]

RFC 4686 DKIM Threat Analysis September 2006

4.1.5. Signed Message Replay

Signed message replay refers to the retransmission of already-signed

messages to additional recipients beyond those intended by the author

or the original poster of the message. The attacker arranges to

receive a message from the victim, and then retransmits it intact but

with different envelope addresses. This might be done, for example,

to make it look like a legitimate sender of messages is sending a

large amount of spam. When reputation services are deployed, this

could damage the author's reputation or that of the author's domain.

A larger number of domains are potential victims of signed message

replay than chosen message replay because the former does not require

the ability for the attacker to send messages from the victim domain.

However, the capabilities of the attacker are lower. Unless coupled

with another attack such as body length limit abuse, it isn't

possible for the attacker to use this, for example, for advertising.

Many mailing lists, especially those that do not modify the content

of the message and signed header fields and hence do not invalidate

the signature, engage in a form of signed message replay. The use of

body length limits and other mechanisms to enhance the survivability

of messages effectively enhances the ability to do so. The only

things that distinguish this case from undesirable forms of signed

message replay is the intent of the replayer, which cannot be

determined by the network.

4.1.6. Denial-of-Service Attack against Verifier

While it takes some computing resources to sign and verify a

signature, it takes negligible computing resources to generate an

invalid signature. An attacker could therefore construct a "make

work" attack against a verifier, by sending a large number of

incorrectly-signed messages to a given verifier, perhaps with

multiple signatures each. The motivation might be to make it too

expensive to verify messages.

While this attack is feasible, it can be greatly mitigated by the

manner in which the verifier operates. For example, it might decide

to accept only a certain number of signatures per message, limit the

maximum key size it will accept (to prevent outrageously large

signatures from causing unneeded work), and verify signatures in a

particular order. The verifier could also maintain state

representing the current signature verification failure rate and

adopt a defensive posture when attacks may be under way.

Fenton Informational [Page 16]

RFC 4686 DKIM Threat Analysis September 2006

4.1.7. Denial-of-Service Attack against Key Service

An attacker might also attempt to degrade the availability of an

originator's key service, in order to cause that originator's

messages to be unverifiable. One way to do this might be to quickly

send a large number of messages with signatures that reference a

particular key, thereby creating a heavy load on the key server.

Other types of DoS attacks on the key server or the network

infrastructure serving it are also possible.

The best defense against this attack is to provide redundant key

servers, preferably on geographically-separate parts of the Internet.

Caching also helps a great deal, by decreasing the load on

authoritative key servers when there are many simultaneous key

requests. The use of a key service protocol that minimizes the

transactional cost of key lookups is also beneficial. It is noted

that the Domain Name System has all these characteristics.

4.1.8. Canonicalization Abuse

Canonicalization algorithms represent a tradeoff between the survival

of the validity of a message signature and the desire not to allow

the message to be altered inappropriately. In the past,

canonicalization algorithms have been proposed that would have

permitted attackers, in some cases, to alter the meaning of a

message.

Message signatures that support multiple canonicalization algorithms

give the signer the ability to decide the relative importance of

signature survivability and immutability of the signed content. If

an unexpected vulnerability appears in a canonicalization algorithm

in general use, new algorithms can be deployed, although it will be a

slow process because the signer can never be sure which algorithm(s)

the verifier supports. For this reason, canonicalization algorithms,

like cryptographic algorithms, should undergo a wide and careful

review process.

4.1.9. Body Length Limit Abuse

A body length limit is an optional indication from the signer of how

much content has been signed. The verifier can either ignore the

limit, verify the specified portion of the message, or truncate the

message to the specified portion and verify it. The motivation for

this feature is the behavior of many mailing lists that add a

trailer, perhaps identifying the list, at the end of messages.

Fenton Informational [Page 17]

RFC 4686 DKIM Threat Analysis September 2006

When body length limits are used, there is the potential for an

attacker to add content to the message. It has been shown that this

content, although at the end, can cover desirable content, especially

in the case of HTML messages.

If the body length isn't specified, or if the verifier decides to

ignore the limit, body length limits are moot. If the verifier or

recipient truncates the message at the signed content, there is no

opportunity for the attacker to add anything.

If the verifier observes body length limits when present, there is

the potential that an attacker can make undesired content visible to

the recipient. The size of the appended content makes little

difference, because it can simply be a URL reference pointing to the

actual content. Receiving MUAs can mitigate this threat by, at a

minimum, identifying the unsigned content in the message.

4.1.10. Use of Revoked Key

The benefits obtained by caching of key records opens the possibility

that keys that have been revoked may be used for some period of time

after their revocation. The best examples of this occur when a

holder of a key delegated by the domain administrator must be

unexpectedly deauthorized from sending mail on behalf of one or more

addresses in the domain.

The caching of key records is normally short-lived, on the order of

hours to days. In many cases, this threat can be mitigated simply by

setting a short time-to-live (TTL) for keys not under the domain

administrator's direct control (assuming, of course, that control of

the TTL value may be specified for each record, as it can with DNS).

In some cases, such as the recovery following a stolen private key

belonging to one of the domain's MTAs, the possibility of theft and

the effort required to revoke the key authorization must be

considered when choosing a TTL. The chosen TTL must be long enough

to mitigate denial-of-service attacks and provide reasonable

transaction efficiency, and no longer.

4.1.11. Compromise of Key Server

Rather than by attempting to obtain a private key, an attacker might

instead focus efforts on the server used to publish public keys for a

domain. As in the key theft case, the motive might be to allow the

attacker to sign messages on behalf of the domain. This attack

provides the attacker with the additional capability to remove

legitimate keys from publication, thereby denying the domain the

ability for the signatures on its mail to verify correctly.

Fenton Informational [Page 18]

RFC 4686 DKIM Threat Analysis September 2006

In order to limit the ability to sign a message to entities

authorized by the owner of a signing domain, a relationship must be

established between the signing address and the location from which a

public key is obtained to verify the message. DKIM does this by

publishing either the public key or a reference to it within the DNS

hierarchy of the signing domain. The verifier derives the location

from which to retrieve the public key from the signing address or

domain. The security of the verification process is therefore

dependent on the security of the DNS hierarchy for the signing

domain.

An attacker might successfully compromise the host that is the

primary key server for the signing domain, such as the domain's DNS

master server. Another approach might be to compromise a higher-

level DNS server and change the delegation of name servers for the

signing domain to others under the control of the attacker.

This attack can be mitigated somewhat by independent monitoring to

audit the key service. Such auditing of the key service should occur

by means of zone transfers rather than queries to the zone's primary

server, so that the addition of records to the zone can be detected.

4.1.12. Falsification of Key Service Replies

Replies from the key service may also be spoofed by a suitably

positioned attacker. For DNS, one such way to do this is "cache

poisoning", in which the attacker provides unnecessary (and

incorrect) additional information in DNS replies, which is cached.

DNSSEC [RFC4033] is the preferred means of mitigating this threat,

but the current uptake rate for DNSSEC is slow enough that one would

not like to create a dependency on its deployment. In the case of a

cache poisoning attack, the vulnerabilities created by this attack

are both localized and of limited duration, although records with

relatively long TTL may persist beyond the attack itself.

4.1.13. Publication of Malformed Key Records and/or Signatures

In this attack, the attacker publishes suitably crafted key records

or sends mail with intentionally malformed signatures, in an attempt

to confuse the verifier and perhaps disable verification altogether.

This attack is really a characteristic of an implementation

vulnerability, a buffer overflow or lack of bounds checking, for

example, rather than a vulnerability of the signature mechanism

itself. This threat is best mitigated by careful implementation and

creation of test suites that challenge the verification process.

Fenton Informational [Page 19]

RFC 4686 DKIM Threat Analysis September 2006

4.1.14. Cryptographic Weaknesses in Signature Generation

The cryptographic algorithms used to generate mail signatures,

specifically the hash algorithm and digital signature generation and

verification operations, may over time be subject to mathematical

techniques that degrade their security. At this writing, the SHA-1

hash algorithm is the subject of extensive mathematical analysis that

has considerably lowered the time required to create two messages

with the same hash value. This trend can be expected to continue.

One consequence of a weakness in the hash algorithm is a hash

collision attack. Hash collision attacks in message signing systems

involve the same person creating two different messages that have the

same hash value, where only one of the two messages would normally be

signed. The attack is based on the second message inheriting the

signature of the first. For DKIM, this means that a sender might

create a "good" message and a "bad" message, where some filter at the

signing party's site would sign the good message but not the bad

message. The attacker gets the good message signed, and then

incorporates that signature in the bad message. This scenario is not

common, but could happen, for example, at a site that does content

analysis on messages before signing them.

Current known attacks against SHA-1 make this attack extremely

difficult to mount, but as attacks improve and computing power

becomes more readily available, such an attack could become

achievable.

The message signature system must be designed to support multiple

signature and hash algorithms, and the signing domain must be able to

specify which algorithms it uses to sign messages. The choice of

algorithms must be published in key records, and not only in the

signature itself, to ensure that an attacker is not able to create

signatures using algorithms weaker than the domain wishes to permit.

Because the signer and verifier of email do not, in general,

communicate directly, negotiation of the algorithms used for signing

cannot occur. In other words, a signer has no way of knowing which

algorithm(s) a verifier supports or (due to mail forwarding) where

the verifier is. For this reason, it is expected that once message

signing is widely deployed, algorithm change will occur slowly, and

legacy algorithms will need to be supported for a considerable

period. Algorithms used for message signatures therefore need to be

secure against expected cryptographic developments several years into

the future.

Fenton Informational [Page 20]

RFC 4686 DKIM Threat Analysis September 2006

4.1.15. Display Name Abuse

Message signatures only relate to the address-specification portion

of an email address, while some MUAs only display (or some recipients

only pay attention to) the display name portion of the address. This

inconsistency leads to an attack where the attacker uses a From

header field such as:

From: "Dudley DoRight" <whiplash></whiplash>

In this example, the attacker, whiplash@example.org, can sign the

message and still convince some recipients that the message is from

Dudley DoRight, who is presumably a trusted individual. Coupled with

the use of a throw-away domain or email address, it may be difficult

to hold the attacker accountable for using another's display name.

This is an attack that must be dealt with in the recipient's MUA.

One approach is to require that the signer's address specification

(and not just the display name) be visible to the recipient.

4.1.16. Compromised System within Originator's Network

In many cases, MTAs may be configured to accept and sign messages

that originate within the topological boundaries of the originator's

network (i.e., within a firewall). The increasing use of compromised

systems to send email presents a problem for such policies, because

the attacker, using a compromised system as a proxy, can generate

signed mail at will.

Several approaches exist for mitigating this attack. The use of

authenticated submission, even within the network boundaries, can be

used to limit the addresses for which the attacker may obtain a

signature. It may also help locate the compromised system that is

the source of the messages more quickly. Content analysis of

outbound mail to identify undesirable and malicious content, as well

as monitoring of the volume of messages being sent by users, may also

prevent arbitrary messages from being signed and sent.

4.1.17. Verification Probe Attack

As noted above, bad actors (attackers) can sign messages on behalf of

domains they control. Since they may also control the key service

(e.g., the authoritative DNS name servers for the _domainkey

subdomain), it is possible for them to observe public key lookups,

and their source, when messages are verified.

Fenton Informational [Page 21]

RFC 4686 DKIM Threat Analysis September 2006

One such attack, which we will refer to as a "verification probe", is

to send a message with a DKIM signature to each of many addresses in

a mailing list. The messages need not contain valid signatures, and

each instance of the message would typically use a different

selector. The attacker could then monitor key service requests and

determine which selectors had been accessed, and correspondingly

which addressees used DKIM verification. This could be used to

target future mailings at recipients who do not use DKIM

verification, on the premise that these addressees are more likely to

act on the message contents.

4.1.18. Key Publication by Higher-Level Domain

In order to support the ability of a domain to sign for subdomains

under its administrative control, DKIM permits the domain of a

signature (d= tag) to be any higher-level domain than the signature's

address (i= or equivalent). However, since there is no mechanism for

determining common administrative control of a subdomain, it is

possible for a parent to publish keys that are valid for any domain

below them in the DNS hierarchy. In other words, mail from the

domain example.anytown.ny.us could be signed using keys published by

anytown.ny.us, ny.us, or us, in addition to the domain itself.

Operation of a domain always requires a trust relationship with

higher-level domains. Higher-level domains already have ultimate

power over their subdomains: they could change the name server

delegation for the domain or disenfranchise it entirely. So it is

unlikely that a higher-level domain would intentionally compromise a

subdomain in this manner. However, if higher-level domains send mail

on their own behalf, they may wish to publish keys at their own

level. Higher-level domains must employ special care in the

delegation of keys they publish to ensure that any of their

subdomains are not compromised by misuse of such keys.

Fenton Informational [Page 22]

RFC 4686 DKIM Threat Analysis September 2006

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 | Medium | Medium |

| practices | | |

| Use of multiple From addresses | Low | Medium |

| Abuse of third-party signatures | Medium | High |

| Falsification of Sender Signing Practices | Medium | Medium |

| replies | | |

+---------------------------------------------+--------+------------+

4.2.1. Look-Alike Domain Names

Attackers may attempt to circumvent signing practices of a domain by

using a domain name that is close to, but not the same as, the domain

with signing practices. For instance, "example.com" might be

replaced by "examp1e.com". If the message is not to be signed, DKIM

does not require that the domain used actually exist (although other

mechanisms may make this a requirement). Services exist to monitor

domain registrations to identify potential domain name abuse, but

naturally do not identify the use of unregistered domain names.

A related attack is possible when the MUA does not render the domain

name in an easily recognizable format. If, for example, a Chinese

domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the

unfamiliarity of that representation may enable other domains to more

easily be mis-recognized as the expected domain.

Users that are unfamiliar with internet naming conventions may also

mis-recognize certain names. For example, users may confuse

online.example.com with online-example.com, the latter of which may

have been registered by an attacker.

4.2.2. Internationalized Domain Name Abuse

Internationalized domain names present a special case of the look-

alike domain name attack described above. Due to similarities in the

appearance of many Unicode characters, domains (particularly those

drawing characters from different groups) may be created that are

visually indistinguishable from other, possibly high-value domains.

This is discussed in detail in Unicode Technical Report 36 [UTR36].

Fenton Informational [Page 23]

RFC 4686 DKIM Threat Analysis September 2006

Surveillance of domain registration records may point out some of

these, but there are many such similarities. As in the look-alike

domain attack above, this technique may also be used to circumvent

sender signing practices of other domains.

4.2.3. Denial-of-Service Attack against Signing Practices

Just as the publication of public keys by a domain can be impacted by

an attacker, so can the publication of Sender Signing Practices (SSP)

by a domain. In the case of SSP, the transmission of large amounts

of unsigned mail purporting to come from the domain can result in a

heavy transaction load requesting the SSP record. More general DoS

&lt;PRE&gt;Network Working Group J. Fenton Request for Comments: 4686 Cisco Systems, Inc. Category: Informational September 2006 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. Fenton Informational [Page 1] RFC 4686 DKIM Threat Analysis September 2006 Table of Contents 1. Introduction ....................................................3 1.1. Terminology and Model ......................................3 1.2. Document Structure .........................................5 2. The Bad Actors ..................................................6 2.1. Characteristics ............................................6 2.2. Capabilities ...............................................6 2.3. Location ...................................................8 2.3.1. Externally-Located Bad Actors .......................8 2.3.2. Within Claimed Originator&#039;s Administrative Unit .....8 2.3.3. Within Recipient&#039;s Administrative Unit ..............9 3. Representative Bad Acts .........................................9 3.1. Use of Arbitrary Identities ................................9 3.2. Use of Specific Identities ................................10 3.2.1. Exploitation of Social Relationships ...............10 3.2.2. Identity-Related Fraud .............................11 3.2.3. Reputation Attacks .................................11 3.2.4. Reflection Attacks .................................11 4. Attacks on Message Signing .....................................12 4.1. Attacks against Message Signatures ........................12 4.1.1. Theft of Private Key for Domain ....................13 4.1.2. Theft of Delegated Private Key .....................13 4.1.3. Private Key Recovery via Side Channel Attack .......14 4.1.4. Chosen Message Replay ..............................14 4.1.5. Signed Message Replay ..............................16 4.1.6. Denial-of-Service Attack against Verifier ..........16 4.1.7. Denial-of-Service Attack against Key Service .......17 4.1.8. Canonicalization Abuse .............................17 4.1.9. Body Length Limit Abuse ............................17 4.1.10. Use of Revoked Key ................................18 4.1.11. Compromise of Key Server ..........................18 4.1.12. Falsification of Key Service Replies ..............19 4.1.13. Publication of Malformed Key Records and/or Signatures .................................19 4.1.14. Cryptographic Weaknesses in Signature Generation ..20 4.1.15. Display Name Abuse ................................21 4.1.16. Compromised System within Originator&#039;s Network ....21 4.1.17. Verification Probe Attack .........................21 4.1.18. Key Publication by Higher-Level Domain ............22 4.2. Attacks against Message Signing Practices .................23 4.2.1. Look-Alike Domain Names ............................23 4.2.2. Internationalized Domain Name Abuse ................23 4.2.3. Denial-of-Service Attack against Signing Practices ..........................................24 4.2.4. Use of Multiple From Addresses .....................24 4.2.5. Abuse of Third-Party Signatures ....................24 4.2.6. Falsification of Sender Signing Practices Replies ..25 Fenton Informational [Page 2] RFC 4686 DKIM Threat Analysis September 2006 4.3. Other Attacks .............................................25 4.3.1. Packet Amplification Attacks via DNS ...............25 5. Derived Requirements ...........................................26 6. Security Considerations ........................................26 7. Informative References .........................................27 Appendix A. Acknowledgements ......................................28 1. Introduction The DomainKeys Identified Mail (DKIM) protocol is being specified by the IETF DKIM Working Group. The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. Message recipients can verify the signature by querying the signer&#039;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. This document addresses threats relative to two works in progress by the DKIM Working Group, the DKIM signature specification [DKIM-BASE] and DKIM Sender Signing Practices [DKIM-SSP]. Once the attesting party or parties have been established, the recipient may evaluate the message in the context of additional information such as locally-maintained whitelists, shared reputation services, and/or third-party accreditation. The description of these mechanisms is outside the scope of the IETF DKIM Working Group effort. By applying a signature, a good player enables a verifier to associate a positive reputation with the message, in hopes that it will receive preferential treatment by the recipient. This effort is not intended to address threats associated with message confidentiality nor does it intend to provide a long-term archival signature. 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 originator and recipient typically develop trust relationships with the administrative units that send and receive their email, respectively, to perform the signing and verification of their messages. The origin address is the address on an email message, typically the RFC 2822 From: address, which is associated with the alleged author of the message and is displayed by the recipient&#039;s Mail User Agent (MUA) as the source of the message. Fenton Informational [Page 3] RFC 4686 DKIM Threat Analysis September 2006 The following diagram illustrates a typical usage flowchart for DKIM: +---------------------------------+ | SIGNATURE CREATION | | (Originating or Relaying AU) | | | | Sign (Message, Domain, Key) | | | +---------------------------------+ | - Message (Domain, Key) | [Internet] | V +---------------------------------+ +-----------+ | SIGNATURE VERIFICATION | | | | (Relaying or Delivering AU) | | KEY | | | | QUERY +---&amp;gt;| Verify (Message, Domain, Key) | | | | | +-----------+ +----------------+----------------+ | - Verified Domain +-----------+ V - [Report] | SENDER | +----------------+----------------+ | SIGNING | | | | PRACTICES +---&amp;gt;| SIGNER EVALUATION | | QUERY | | | | | +---------------------------------+ +-----------+ DKIM operates entirely on the content (body and selected header fields) of the message, as defined in RFC 2822 [RFC2822]. The transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and such elements as the envelope-from and envelope-to addresses and the HELO domain are not relevant to DKIM verification. This is an intentional decision made to allow verification of messages via protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501] which an MUA acting as a verifier might use. The Sender Signing Practices Query referred to in the diagram above is a means by which the verifier can query the alleged author&#039;s domain to determine their practices for signing messages, which in turn may influence their evaluation of the message. If, for example, a message arrives without any valid signatures, and the alleged author&#039;s domain advertises that they sign all messages, the verifier might handle that message differently than if a signature was not necessarily to be expected. Fenton Informational [Page 4] RFC 4686 DKIM Threat Analysis September 2006 1.2. Document Structure The remainder of this document describes the problems that DKIM might be expected to address, and the extent to which it may be successful in so doing. These are described in terms of the potential bad actors, their capabilities and location in the network, and the bad acts that they might wish to commit. This is followed by a description of postulated attacks on DKIM message signing and on the use of Sender Signing Practices to assist in the treatment of unsigned messages. A list of derived requirements is also presented, which is intended to guide the DKIM design and review process. The sections dealing with attacks on DKIM each begin with a table summarizing the postulated attacks in each category along with their expected impact and likelihood. 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 Fenton Informational [Page 5] RFC 4686 DKIM Threat Analysis September 2006 2. The Bad Actors 2.1. Characteristics The problem space being addressed by DKIM is characterized by a wide range of attackers in terms of motivation, sophistication, and capabilities. At the low end of the spectrum are bad actors who may simply send email, perhaps using one of many commercially available tools, that the recipient does not want to receive. These tools typically allow one to falsify the origin address of messages, and may, in the future, be capable of generating message signatures as well. At the next tier are what would be considered &quot;professional&quot; senders of unwanted email. These attackers would deploy specific infrastructure, including Mail Transfer Agents (MTAs), registered domains and networks of compromised computers (&quot;zombies&quot;) to send messages, and in some cases to harvest addresses to which to send. These senders often operate as commercial enterprises and send messages on behalf of third parties. The most sophisticated and financially-motivated senders of messages are those who stand to receive substantial financial benefit, such as from an email-based fraud scheme. These attackers can be expected to employ all of the above mechanisms and additionally may attack the Internet infrastructure itself, including DNS cache-poisoning attacks and IP routing attacks. 2.2. Capabilities In general, the bad actors described above should be expected to have access to the following: 1. An extensive corpus of messages from domains they might wish to impersonate 2. Knowledge of the business aims and model for domains they might wish to impersonate 3. Access to public keys and associated authorization records associated with the domain and the ability to do at least some of the following: 1. Submit messages to MTAs and Message Submission Agents (MSAs) at multiple locations in the Internet Fenton Informational [Page 6] RFC 4686 DKIM Threat Analysis September 2006 2. Construct arbitrary message header fields, including those claiming to be mailing lists, resenders, and other mail agents 3. Sign messages on behalf of domains under their control 4. Generate substantial numbers of either unsigned or apparently- signed messages that might be used to attempt a denial-of-service attack 5. Resend messages that may have been previously signed by the domain 6. Transmit messages using any envelope information desired 7. Act as an authorized submitter for messages from a compromised computer As noted above, certain classes of bad actors may have substantial financial motivation for their activities, and therefore should be expected to have more capabilities at their disposal. These include: 1. 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. 2. 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. 3. Access to significant computing resources, for example, through the conscription of worm-infected &quot;zombie&quot; computers. This could allow the bad actor to perform various types of brute-force attacks. 4. Ability to eavesdrop on existing traffic, perhaps from a wireless network. Either of the first two of these mechanisms could be used to allow the bad actor to function as a man-in-the-middle between author and recipient, if that attack is useful. Fenton Informational [Page 7] RFC 4686 DKIM Threat Analysis September 2006 2.3. Location Bad actors or their proxies can be located anywhere in the Internet. Certain attacks are possible primarily within the administrative unit of the claimed originator and/or recipient domain have capabilities beyond those elsewhere, as described in the below sections. Bad actors can also collude by acting from multiple locations (a &quot;distributed bad actor&quot;). It should also be noted that with the use of &quot;zombies&quot; and other proxies, externally-located bad actors may gain some of the capabilities of being located within the claimed originator&#039;s or recipient&#039;s administrative unit. This emphasizes the importance of appropriate security measures, such as authenticated submission of messages, even within administrative units. 2.3.1. Externally-Located Bad Actors DKIM focuses primarily on bad actors located outside of the administrative units of the claimed originator and the recipient. These administrative units frequently correspond to the protected portions of the network adjacent to the originator and recipient. It is in this area that the trust relationships required for authenticated message submission do not exist and do not scale adequately to be practical. Conversely, within these administrative units, there are other mechanisms such as authenticated message submission that are easier to deploy and more likely to be used than DKIM. External bad actors are usually attempting to exploit the &quot;any to any&quot; nature of email that motivates most recipient MTAs to accept messages from anywhere for delivery to their local domain. They may generate messages without signatures, with incorrect signatures, or with correct signatures from domains with little traceability. They may also pose as mailing lists, greeting cards, or other agents that legitimately send or resend messages on behalf of others. 2.3.2. Within Claimed Originator&#039;s Administrative Unit Bad actors in the form of rogue or unauthorized users or malware- infected computers can exist within the administrative unit corresponding to a message&#039;s origin address. Since the submission of messages in this area generally occurs prior to the application of a message signature, DKIM is not directly effective against these bad actors. Defense against these bad actors is dependent upon other means, such as proper use of firewalls, and Message Submission Agents that are configured to authenticate the author. Fenton Informational [Page 8] RFC 4686 DKIM Threat Analysis September 2006 In the special case where the administrative unit is non-contiguous (e.g., a company that communicates between branches over the external Internet), DKIM signatures can be used to distinguish between legitimate externally-originated messages and attempts to spoof addresses in the local domain. 2.3.3. Within Recipient&#039;s Administrative Unit Bad actors may also exist within the administrative unit of the message recipient. These bad actors may attempt to exploit the trust relationships that exist within the unit. Since messages will typically only have undergone DKIM verification at the administrative unit boundary, DKIM is not effective against messages submitted in this area. For example, the bad actor may attempt to spoof a header field indicating the results of verification. This header field would normally be added by the verifier, which would also detect spoofed header fields on messages it was attempting to verify. This could be used to falsely indicate that the message was authenticated successfully. As in the originator case, these bad actors can be dealt with by controlling the submission of messages within the administrative unit. Since DKIM permits verification to occur anywhere within the recipient&#039;s administrative unit, these threats can also be minimized by moving verification closer to the recipient, such as at the Mail Delivery Agent (MDA), or on the recipient&#039;s MUA itself. 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. As described above, these messages might merely be unwanted by the recipient, or might be part of a confidence scheme or a delivery vector for malware. 3.1. Use of Arbitrary Identities This class of bad acts includes the sending of messages that aim to obscure the identity of the actual author. In some cases, the actual sender might be the bad actor, or in other cases might be a third- party under the control of the bad actor (e.g., a compromised computer). Particularly when coupled with sender signing practices that indicate the domain owner signs all messages, DKIM can be effective in mitigating against the abuse of addresses not controlled by bad Fenton Informational [Page 9] RFC 4686 DKIM Threat Analysis September 2006 actors. DKIM is not effective against the use of addresses controlled by bad actors. In other words, the presence of a valid DKIM signature does not guarantee that the signer is not a bad actor. It also does not guarantee the accountability of the signer, since DKIM does not attempt to identify the signer individually, but rather identifies the domain that they control. 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 A second major class of bad acts involves the assertion of specific identities in email. Note that some bad acts involving specific identities can sometimes be accomplished, although perhaps less effectively, with similar looking identities that mislead some recipients. For example, if the bad actor is able to control the domain &quot;examp1e.com&quot; (note the &quot;one&quot; between the p and e), they might be able to convince some recipients that a message from admin@examp1e.com is really from admin@example.com. Similar types of attacks using internationalized domain names have been hypothesized where it could be very difficult to see character differences in popular typefaces. Similarly, if example2.com was controlled by a bad actor, the bad actor could sign messages from bigbank.example2.com, which might also mislead some recipients. To the extent that these domains are controlled by bad actors, DKIM is not effective against these attacks, although it could support the ability of reputation and/or accreditation systems to aid the user in identifying them. 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), which will be specified by the IETF DKIM Working Group. 3.2.1. Exploitation of Social Relationships One reason for asserting a specific origin address is to encourage a recipient to read and act on particular email messages by appearing to be an acquaintance or previous correspondent that the recipient might trust. This tactic has been used by email-propagated malware that mail themselves to addresses in the infected host&#039;s address book. In this case, however, the author&#039;s address may not be falsified, so DKIM would not be effective in defending against this act. Fenton Informational [Page 10] RFC 4686 DKIM Threat Analysis September 2006 It is also possible for address books to be harvested and used by an attacker to post messages from elsewhere. 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. 3.2.2. Identity-Related Fraud Bad acts related to email-based fraud often, but not always, involve the transmission of messages using specific origin addresses of other entities as part of the fraud scheme. The use of a specific address of origin sometimes contributes to the success of the fraud by helping convince the recipient that the message was actually sent by the alleged author. To the extent that the success of the fraud depends on or is enhanced by the use of a specific origin address, the bad actor may have significant financial motivation and resources to circumvent any measures taken to protect specific addresses from unauthorized use. When signatures are verified by or for the recipient, 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 Another motivation for using a specific origin address in a message is to harm the reputation of another, commonly referred to as a &quot;joe-job&quot;. For example, a commercial entity might wish to harm the reputation of a competitor, perhaps by sending unsolicited bulk email on behalf of that competitor. 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 A commonly-used tactic by some bad actors is the indirect transmission of messages by intentionally mis-addressing the message and causing it to be &quot;bounced&quot;, or sent to the return address (RFC 2821 envelope-from address) on the message. In this case, the specific identity asserted in the email is that of the actual target of the message, to whom the message is &quot;returned&quot;. DKIM does not, in general, attempt to validate the RFC2821.mailfrom return address on messages, either directly (noting that the mailfrom Fenton Informational [Page 11] RFC 4686 DKIM Threat Analysis September 2006 address is an element of the SMTP protocol, and not the message content on which DKIM operates), or via the optional Return-Path header field. Furthermore, as is noted in Section 4.4 of RFC 2821 [RFC2821], it is common and useful practice for a message&#039;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 Bad actors can be expected to exploit all of the limitations of message authentication systems. They are also likely to be motivated to degrade the usefulness of message authentication systems in order to hinder their deployment. Both the signature mechanism itself and declarations made regarding use of message signatures (referred to here as Sender Signing Practices or SSP) can be expected to be the target of attacks. 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 | M/H | | 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 | High | Low | | signatures | | | | Cryptographic weaknesses in signature | High | Low | | generation | | | | Display name abuse | Medium | High | | Compromised system within originator&#039;s | High | Medium | | network | | | | Verification probe attack | Medium | Medium | | Key publication by higher-level domain | High | Low | +---------------------------------------------+--------+------------+ Fenton Informational [Page 12] RFC 4686 DKIM Threat Analysis September 2006 4.1.1. Theft of Private Key for Domain Message signing technologies such as DKIM are vulnerable to theft of the private keys used to sign messages. This includes &quot;out-of-band&quot; means for this theft, such as burglary, bribery, extortion, and the like, as well as electronic means for such theft, such as a compromise of network and host security around the place where a private key is stored. Keys that are valid for all addresses in a domain typically reside in MTAs that should be located in well-protected sites, such as data centers. Various means should be employed for minimizing access to private keys, such as non-existence of commands for displaying their value, although ultimately memory dumps and the like will probably contain the keys. Due to the unattended nature of MTAs, some countermeasures, such as the use of a pass phrase to &quot;unlock&quot; a key, are not practical to use. Other mechanisms, such as the use of dedicated hardware devices that contain the private key and perform the cryptographic signature operation, would be very effective in denying export of the private key to those without physical access to the device. Such devices would almost certainly make the theft of the key visible, so that appropriate action (revocation of the corresponding public key) can be taken should that happen. 4.1.2. Theft of Delegated Private Key There are several circumstances where a domain owner will want to delegate the ability to sign messages for the domain to an individual user or a third party associated with an outsourced activity such as a corporate benefits administrator or a marketing campaign. Since these keys may exist on less well-protected devices than the domain&#039;s own MTAs, they will in many cases be more susceptible to compromise. In order to mitigate this exposure, keys used to sign such messages can be restricted by the domain owner to be valid for signing messages only on behalf of specific addresses in the domain. This maintains protection for the majority of addresses in the domain. A related threat is the exploitation of weaknesses in the delegation process itself. This threat can be mitigated through the use of customary precautions against the theft of private keys and the falsification of public keys in transit. For example, the exposure to theft can be minimized if the delegate generates the keypair to be used, and sends the public key to the domain owner. The exposure to falsification (substitution of a different public key) can be reduced if this transmission is signed by the delegate and verified by the domain owner. Fenton Informational [Page 13] RFC 4686 DKIM Threat Analysis September 2006 4.1.3. Private Key Recovery via Side Channel Attack All popular digital signature algorithms are subject to a variety of side channel attacks. The most well-known of these are timing channels [Kocher96], power analysis [Kocher99], and cache timing analysis [Bernstein04]. Most of these attacks require either physical access to the machine or the ability to run processes directly on the target machine. Defending against these attacks is out of scope for DKIM. However, remote timing analysis (at least on local area networks) is known to be feasible [Boneh03], particularly in server-type platforms where the attacker can inject traffic that will immediately be subject to the cryptographic operation in question. With enough samples, these techniques can be used to extract private keys even in the face of modest amounts of noise in the timing measurements. The three commonly proposed countermeasures against timing analysis are: 1. Make the operation run in constant time. This turns out in practice to be rather difficult. 2. Make the time independent of the input data. This can be difficult, but see [Boneh03] for more details. 3. Use blinding. This is generally considered the best current practice countermeasure, and while not proved generally secure is a countermeasure against known timing attacks. It adds about 2-10% to the cost of the operation and is implemented in many common cryptographic libraries. Unfortunately, Digital Signature Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have standard methods though some defenses may exist. Note that adding random delays to the operation is only a partial countermeasure. Because the noise is generally uniformly distributed, a large enough number of samples can be used to average it out and extract an accurate timing signal. 4.1.4. Chosen Message Replay Chosen message replay refers to the scenario where the attacker creates a message and obtains a signature for it by sending it through an MTA authorized by the originating domain to himself/herself or an accomplice. They then &quot;replay&quot; the signed message by sending it, using different envelope addresses, to a (typically large) number of other recipients. Fenton Informational [Page 14] RFC 4686 DKIM Threat Analysis September 2006 Due to the requirement to get an attacker-generated message signed, chosen message replay would most commonly be experienced by consumer ISPs or others offering email accounts to clients, particularly where there is little or no accountability to the account holder (the attacker in this case). One approach to solving this problem is for the domain to only sign email for clients that have passed a vetting process to provide traceability to the message originator in the event of abuse. At present, the low cost of email accounts (zero) does not make it practical for any vetting to occur. It remains to be seen whether this will be the model with signed mail as well, or whether a higher level of trust will be required to obtain an email signature. A variation on this attack involves the attacker sending a message with the intent of obtaining a signed reply containing their original message. The reply might come from an innocent user or might be an automatic response such as a &quot;user unknown&quot; bounce message. In some cases, this signed reply message might accomplish the attacker&#039;s objectives if replayed. This variation on chosen message replay can be mitigated by limiting the extent to which the original content is quoted in automatic replies, and by the use of complementary mechanisms such as egress content filtering. Revocation of the signature or the associated key is a potential countermeasure. However, the rapid pace at which the message might be replayed (especially with an army of &quot;zombie&quot; computers), compared with the time required to detect the attack and implement the revocation, is likely to be problematic. A related problem is the likelihood that domains will use a small number of signing keys for a large number of customers, which is beneficial from a caching standpoint but is likely to result in a great deal of collateral damage (in the form of signature verification failures) should a key be revoked suddenly. Signature revocation addresses the collateral damage problem at the expense of significant scaling requirements. At the extreme, verifiers could be required to check for revocation of each signature verified, which would result in very significant transaction rates. An alternative, &quot;revocation identifiers&quot;, has been proposed, which would permit revocation on an intermediate level of granularity, perhaps on a per-account basis. Messages containing these identifiers would result in a query to a revocation database, which might be represented in DNS. Further study is needed to determine if the benefits from revocation (given the potential speed of a replay attack) outweigh the transactional cost of querying a revocation database. Fenton Informational [Page 15] RFC 4686 DKIM Threat Analysis September 2006 4.1.5. Signed Message Replay Signed message replay refers to the retransmission of already-signed messages to additional recipients beyond those intended by the author or the original poster of the message. The attacker arranges to receive a message from the victim, and then retransmits it intact but with different envelope addresses. This might be done, for example, to make it look like a legitimate sender of messages is sending a large amount of spam. When reputation services are deployed, this could damage the author&#039;s reputation or that of the author&#039;s domain. A larger number of domains are potential victims of signed message replay than chosen message replay because the former does not require the ability for the attacker to send messages from the victim domain. However, the capabilities of the attacker are lower. Unless coupled with another attack such as body length limit abuse, it isn&#039;t possible for the attacker to use this, for example, for advertising. Many mailing lists, especially those that do not modify the content of the message and signed header fields and hence do not invalidate the signature, engage in a form of signed message replay. The use of body length limits and other mechanisms to enhance the survivability of messages effectively enhances the ability to do so. The only things that distinguish this case from undesirable forms of signed message replay is the intent of the replayer, which cannot be determined by the network. 4.1.6. Denial-of-Service Attack against Verifier While it takes some computing resources to sign and verify a signature, it takes negligible computing resources to generate an invalid signature. An attacker could therefore construct a &quot;make work&quot; attack against a verifier, by sending a large number of incorrectly-signed messages to a given verifier, perhaps with multiple signatures each. The motivation might be to make it too expensive to verify messages. While this attack is feasible, it can be greatly mitigated by the manner in which the verifier operates. For example, it might decide to accept only a certain number of signatures per message, limit the maximum key size it will accept (to prevent outrageously large signatures from causing unneeded work), and verify signatures in a particular order. The verifier could also maintain state representing the current signature verification failure rate and adopt a defensive posture when attacks may be under way. Fenton Informational [Page 16] RFC 4686 DKIM Threat Analysis September 2006 4.1.7. Denial-of-Service Attack against Key Service An attacker might also attempt to degrade the availability of an originator&#039;s key service, in order to cause that originator&#039;s messages to be unverifiable. One way to do this might be to quickly send a large number of messages with signatures that reference a particular key, thereby creating a heavy load on the key server. Other types of DoS attacks on the key server or the network infrastructure serving it are also possible. The best defense against this attack is to provide redundant key servers, preferably on geographically-separate parts of the Internet. Caching also helps a great deal, by decreasing the load on authoritative key servers when there are many simultaneous key requests. The use of a key service protocol that minimizes the transactional cost of key lookups is also beneficial. It is noted that the Domain Name System has all these characteristics. 4.1.8. Canonicalization Abuse Canonicalization algorithms represent a tradeoff between the survival of the validity of a message signature and the desire not to allow the message to be altered inappropriately. In the past, canonicalization algorithms have been proposed that would have permitted attackers, in some cases, to alter the meaning of a message. Message signatures that support multiple canonicalization algorithms give the signer the ability to decide the relative importance of signature survivability and immutability of the signed content. If an unexpected vulnerability appears in a canonicalization algorithm in general use, new algorithms can be deployed, although it will be a slow process because the signer can never be sure which algorithm(s) the verifier supports. For this reason, canonicalization algorithms, like cryptographic algorithms, should undergo a wide and careful review process. 4.1.9. Body Length Limit Abuse A body length limit is an optional indication from the signer of how much content has been signed. The verifier can either ignore the limit, verify the specified portion of the message, or truncate the message to the specified portion and verify it. The motivation for this feature is the behavior of many mailing lists that add a trailer, perhaps identifying the list, at the end of messages. Fenton Informational [Page 17] RFC 4686 DKIM Threat Analysis September 2006 When body length limits are used, there is the potential for an attacker to add content to the message. It has been shown that this content, although at the end, can cover desirable content, especially in the case of HTML messages. If the body length isn&#039;t specified, or if the verifier decides to ignore the limit, body length limits are moot. If the verifier or recipient truncates the message at the signed content, there is no opportunity for the attacker to add anything. If the verifier observes body length limits when present, there is the potential that an attacker can make undesired content visible to the recipient. The size of the appended content makes little difference, because it can simply be a URL reference pointing to the actual content. Receiving MUAs can mitigate this threat by, at a minimum, identifying the unsigned content in the message. 4.1.10. Use of Revoked Key The benefits obtained by caching of key records opens the possibility that keys that have been revoked may be used for some period of time after their revocation. The best examples of this occur when a holder of a key delegated by the domain administrator must be unexpectedly deauthorized from sending mail on behalf of one or more addresses in the domain. The caching of key records is normally short-lived, on the order of hours to days. In many cases, this threat can be mitigated simply by setting a short time-to-live (TTL) for keys not under the domain administrator&#039;s direct control (assuming, of course, that control of the TTL value may be specified for each record, as it can with DNS). In some cases, such as the recovery following a stolen private key belonging to one of the domain&#039;s MTAs, the possibility of theft and the effort required to revoke the key authorization must be considered when choosing a TTL. The chosen TTL must be long enough to mitigate denial-of-service attacks and provide reasonable transaction efficiency, and no longer. 4.1.11. Compromise of Key Server Rather than by attempting to obtain a private key, an attacker might instead focus efforts on the server used to publish public keys for a domain. As in the key theft case, the motive might be to allow the attacker to sign messages on behalf of the domain. This attack provides the attacker with the additional capability to remove legitimate keys from publication, thereby denying the domain the ability for the signatures on its mail to verify correctly. Fenton Informational [Page 18] RFC 4686 DKIM Threat Analysis September 2006 In order to limit the ability to sign a message to entities authorized by the owner of a signing domain, a relationship must be established between the signing address and the location from which a public key is obtained to verify the message. DKIM does this by publishing either the public key or a reference to it within the DNS hierarchy of the signing domain. The verifier derives the location from which to retrieve the public key from the signing address or domain. The security of the verification process is therefore dependent on the security of the DNS hierarchy for the signing domain. An attacker might successfully compromise the host that is the primary key server for the signing domain, such as the domain&#039;s DNS master server. Another approach might be to compromise a higher- level DNS server and change the delegation of name servers for the signing domain to others under the control of the attacker. This attack can be mitigated somewhat by independent monitoring to audit the key service. Such auditing of the key service should occur by means of zone transfers rather than queries to the zone&#039;s primary server, so that the addition of records to the zone can be detected. 4.1.12. Falsification of Key Service Replies Replies from the key service may also be spoofed by a suitably positioned attacker. For DNS, one such way to do this is &quot;cache poisoning&quot;, in which the attacker provides unnecessary (and incorrect) additional information in DNS replies, which is cached. DNSSEC [RFC4033] is the preferred means of mitigating this threat, but the current uptake rate for DNSSEC is slow enough that one would not like to create a dependency on its deployment. In the case of a cache poisoning attack, the vulnerabilities created by this attack are both localized and of limited duration, although records with relatively long TTL may persist beyond the attack itself. 4.1.13. Publication of Malformed Key Records and/or Signatures In this attack, the attacker publishes suitably crafted key records or sends mail with intentionally malformed signatures, in an attempt to confuse the verifier and perhaps disable verification altogether. This attack is really a characteristic of an implementation vulnerability, a buffer overflow or lack of bounds checking, for example, rather than a vulnerability of the signature mechanism itself. This threat is best mitigated by careful implementation and creation of test suites that challenge the verification process. Fenton Informational [Page 19] RFC 4686 DKIM Threat Analysis September 2006 4.1.14. Cryptographic Weaknesses in Signature Generation The cryptographic algorithms used to generate mail signatures, specifically the hash algorithm and digital signature generation and verification operations, may over time be subject to mathematical techniques that degrade their security. At this writing, the SHA-1 hash algorithm is the subject of extensive mathematical analysis that has considerably lowered the time required to create two messages with the same hash value. This trend can be expected to continue. One consequence of a weakness in the hash algorithm is a hash collision attack. Hash collision attacks in message signing systems involve the same person creating two different messages that have the same hash value, where only one of the two messages would normally be signed. The attack is based on the second message inheriting the signature of the first. For DKIM, this means that a sender might create a &quot;good&quot; message and a &quot;bad&quot; message, where some filter at the signing party&#039;s site would sign the good message but not the bad message. The attacker gets the good message signed, and then incorporates that signature in the bad message. This scenario is not common, but could happen, for example, at a site that does content analysis on messages before signing them. Current known attacks against SHA-1 make this attack extremely difficult to mount, but as attacks improve and computing power becomes more readily available, such an attack could become achievable. The message signature system must be designed to support multiple signature and hash algorithms, and the signing domain must be able to specify which algorithms it uses to sign messages. The choice of algorithms must be published in key records, and not only in the signature itself, to ensure that an attacker is not able to create signatures using algorithms weaker than the domain wishes to permit. Because the signer and verifier of email do not, in general, communicate directly, negotiation of the algorithms used for signing cannot occur. In other words, a signer has no way of knowing which algorithm(s) a verifier supports or (due to mail forwarding) where the verifier is. For this reason, it is expected that once message signing is widely deployed, algorithm change will occur slowly, and legacy algorithms will need to be supported for a considerable period. Algorithms used for message signatures therefore need to be secure against expected cryptographic developments several years into the future. Fenton Informational [Page 20] RFC 4686 DKIM Threat Analysis September 2006 4.1.15. Display Name Abuse Message signatures only relate to the address-specification portion of an email address, while some MUAs only display (or some recipients only pay attention to) the display name portion of the address. This inconsistency leads to an attack where the attacker uses a From header field such as: From: &quot;Dudley DoRight&quot; &lt;WHIPLASH@EXAMPLE.ORG&gt; In this example, the attacker, whiplash@example.org, can sign the message and still convince some recipients that the message is from Dudley DoRight, who is presumably a trusted individual. Coupled with the use of a throw-away domain or email address, it may be difficult to hold the attacker accountable for using another&#039;s display name. This is an attack that must be dealt with in the recipient&#039;s MUA. One approach is to require that the signer&#039;s address specification (and not just the display name) be visible to the recipient. 4.1.16. Compromised System within Originator&#039;s Network In many cases, MTAs may be configured to accept and sign messages that originate within the topological boundaries of the originator&#039;s network (i.e., within a firewall). The increasing use of compromised systems to send email presents a problem for such policies, because the attacker, using a compromised system as a proxy, can generate signed mail at will. Several approaches exist for mitigating this attack. The use of authenticated submission, even within the network boundaries, can be used to limit the addresses for which the attacker may obtain a signature. It may also help locate the compromised system that is the source of the messages more quickly. Content analysis of outbound mail to identify undesirable and malicious content, as well as monitoring of the volume of messages being sent by users, may also prevent arbitrary messages from being signed and sent. 4.1.17. Verification Probe Attack As noted above, bad actors (attackers) can sign messages on behalf of domains they control. Since they may also control the key service (e.g., the authoritative DNS name servers for the _domainkey subdomain), it is possible for them to observe public key lookups, and their source, when messages are verified. Fenton Informational [Page 21] RFC 4686 DKIM Threat Analysis September 2006 One such attack, which we will refer to as a &quot;verification probe&quot;, is to send a message with a DKIM signature to each of many addresses in a mailing list. The messages need not contain valid signatures, and each instance of the message would typically use a different selector. The attacker could then monitor key service requests and determine which selectors had been accessed, and correspondingly which addressees used DKIM verification. This could be used to target future mailings at recipients who do not use DKIM verification, on the premise that these addressees are more likely to act on the message contents. 4.1.18. Key Publication by Higher-Level Domain In order to support the ability of a domain to sign for subdomains under its administrative control, DKIM permits the domain of a signature (d= tag) to be any higher-level domain than the signature&#039;s address (i= or equivalent). However, since there is no mechanism for determining common administrative control of a subdomain, it is possible for a parent to publish keys that are valid for any domain below them in the DNS hierarchy. In other words, mail from the domain example.anytown.ny.us could be signed using keys published by anytown.ny.us, ny.us, or us, in addition to the domain itself. Operation of a domain always requires a trust relationship with higher-level domains. Higher-level domains already have ultimate power over their subdomains: they could change the name server delegation for the domain or disenfranchise it entirely. So it is unlikely that a higher-level domain would intentionally compromise a subdomain in this manner. However, if higher-level domains send mail on their own behalf, they may wish to publish keys at their own level. Higher-level domains must employ special care in the delegation of keys they publish to ensure that any of their subdomains are not compromised by misuse of such keys. Fenton Informational [Page 22] RFC 4686 DKIM Threat Analysis September 2006 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 | Medium | Medium | | practices | | | | Use of multiple From addresses | Low | Medium | | Abuse of third-party signatures | Medium | High | | Falsification of Sender Signing Practices | Medium | Medium | | replies | | | +---------------------------------------------+--------+------------+ 4.2.1. Look-Alike Domain Names Attackers may attempt to circumvent signing practices of a domain by using a domain name that is close to, but not the same as, the domain with signing practices. For instance, &quot;example.com&quot; might be replaced by &quot;examp1e.com&quot;. If the message is not to be signed, DKIM does not require that the domain used actually exist (although other mechanisms may make this a requirement). Services exist to monitor domain registrations to identify potential domain name abuse, but naturally do not identify the use of unregistered domain names. A related attack is possible when the MUA does not render the domain name in an easily recognizable format. If, for example, a Chinese domain name is rendered in &quot;punycode&quot; as xn--cjsp26b3obxw7f.com, the unfamiliarity of that representation may enable other domains to more easily be mis-recognized as the expected domain. Users that are unfamiliar with internet naming conventions may also mis-recognize certain names. For example, users may confuse online.example.com with online-example.com, the latter of which may have been registered by an attacker. 4.2.2. Internationalized Domain Name Abuse Internationalized domain names present a special case of the look- alike domain name attack described above. Due to similarities in the appearance of many Unicode characters, domains (particularly those drawing characters from different groups) may be created that are visually indistinguishable from other, possibly high-value domains. This is discussed in detail in Unicode Technical Report 36 [UTR36]. Fenton Informational [Page 23] RFC 4686 DKIM Threat Analysis September 2006 Surveillance of domain registration records may point out some of these, but there are many such similarities. As in the look-alike domain attack above, this technique may also be used to circumvent sender signing practices of other domains. 4.2.3. Denial-of-Service Attack against Signing Practices Just as the publication of public keys by a domain can be impacted by an attacker, so can the publication of Sender Signing Practices (SSP) by a domain. In the case of SSP, the transmission of large amounts of unsigned mail purporting to come from the domain can result in a heavy transaction load requesting the SSP record. More general DoS attacks against the servers providing the SSP records are possible as well. This is of particular concern since the default signing practices are &quot;we don&#039;t sign everything&quot;, which means that SSP failures result in the verifier&#039;s failure to heed more stringent signing practices. As with defense against DoS attacks for key servers, the best defense against this attack is to provide redundant servers, preferably on geographically-separate parts of the Internet. Caching again helps a great deal, and signing practices should rarely change, so TTL values can be relatively large. 4.2.4. Use of Multiple From Addresses Although this usage is never seen by most recipients, RFC 2822 [RFC2822] permits the From address to contain multiple address specifications. The lookup of Sender Signing Practices is based on the From address, so if addresses from multiple domains are in the From address, the question arises which signing practices to use. A rule (say, &quot;use the first address&quot;) could be specified, but then an attacker could put a throwaway address prior to that of a high-value domain. It is also possible for SSP to look at all addresses, and choose the most restrictive rule. This is an area in need of further study. 4.2.5. Abuse of Third-Party Signatures In a number of situations, including mailing lists, event invitations, and &quot;send this article to a friend&quot; services, the DKIM signature on a message may not come from the originating address domain. For this reason, &quot;third-party&quot; signatures, those attached by the mailing list, invitation service, or news service, frequently need to be regarded as having some validity. Since this effectively makes it possible for any domain to sign any message, a sending Fenton Informational [Page 24] RFC 4686 DKIM Threat Analysis September 2006 domain may publish sender signing practices stating that it does not use such services, and accordingly that verifiers should view such signatures with suspicion. However, the restrictions placed on a domain by publishing &quot;no third-party&quot; signing practices effectively disallows many existing uses of email. For the majority of domains that are unable to adopt these practices, an attacker may with some degree of success sign messages purporting to come from the domain. For this reason, accreditation and reputation services, as well as locally-maintained whitelists and blacklists, will need to play a significant role in evaluating messages that have been signed by third parties. 4.2.6. Falsification of Sender Signing Practices Replies In an analogous manner to the falsification of key service replies described in Section 4.1.12, replies to sender signing practices queries can also be falsified. One such attack would be to weaken the signing practices to make unsigned messages allegedly from a given domain appear less suspicious. Another attack on a victim domain that is not signing messages could attempt to make the domain&#039;s messages look more suspicious, in order to interfere with the victim&#039;s ability to send mail. As with the falsification of key service replies, DNSSEC is the preferred means of mitigating this attack. Even in the absence of DNSSEC, vulnerabilities due to cache poisoning are localized. 4.3. Other Attacks This section describes attacks against other Internet infrastructure that are enabled by deployment of DKIM. A summary of these postulated attacks is as follows: +--------------------------------------+--------+------------+ | Attack Name | Impact | Likelihood | +--------------------------------------+--------+------------+ | Packet amplification attacks via DNS | N/A | Medium | +--------------------------------------+--------+------------+ 4.3.1. Packet Amplification Attacks via DNS Recently, there has been an increase in denial-of-service attacks involving the transmission of spoofed UDP DNS requests to openly- accessible domain name servers [US-CERT-DNS]. To the extent that the response from the name server is larger than the request, the name server functions as an amplifier for such an attack. Fenton Informational [Page 25] RFC 4686 DKIM Threat Analysis September 2006 DKIM contributes indirectly to this attack by requiring the publication of fairly large DNS records for distributing public keys. The names of these records are also well known, since the record names can be determined by examining properly-signed messages. This attack does not h
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft