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