draft-ietf-dkim-threats-03.txt   rfc4686.txt 
DKIM Working Group J. Fenton Network Working Group J. Fenton
Internet-Draft Cisco Systems, Inc. Request for Comments: 4686 Cisco Systems, Inc.
Expires: November 27, 2006 May 26, 2006 Category: Informational September 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
draft-ietf-dkim-threats-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2006. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document provides an analysis of some threats against Internet This document provides an analysis of some threats against Internet
mail that are intended to be addressed by signature-based mail mail that are intended to be addressed by signature-based mail
authentication, in particular DomainKeys Identified Mail. It authentication, in particular DomainKeys Identified Mail. It
discusses the nature and location of the bad actors, what their discusses the nature and location of the bad actors, what their
capabilities are, and what they intend to accomplish via their capabilities are, and what they intend to accomplish via their
attacks. attacks.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Terminology and Model . . . . . . . . . . . . . . . . . . 4 1.1. Terminology and Model ......................................3
1.2. Document Structure . . . . . . . . . . . . . . . . . . . . 6 1.2. Document Structure .........................................5
2. The Bad Actors . . . . . . . . . . . . . . . . . . . . . . . . 6 2. The Bad Actors ..................................................6
2.1. Characteristics . . . . . . . . . . . . . . . . . . . . . 6 2.1. Characteristics ............................................6
2.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Capabilities ...............................................6
2.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Location ...................................................8
2.3.1. Externally-located Bad Actors . . . . . . . . . . . . 9 2.3.1. Externally-Located Bad Actors .......................8
2.3.2. Within Claimed Originator's Administrative Unit . . . 9 2.3.2. Within Claimed Originator's Administrative Unit .....8
2.3.3. Within Recipient's Administrative Unit . . . . . . . . 9 2.3.3. Within Recipient's Administrative Unit ..............9
3. Representative Bad Acts . . . . . . . . . . . . . . . . . . . 10 3. Representative Bad Acts .........................................9
3.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 10 3.1. Use of Arbitrary Identities ................................9
3.2. Use of Specific Identities . . . . . . . . . . . . . . . . 10 3.2. Use of Specific Identities ................................10
3.2.1. Exploitation of Social Relationships . . . . . . . . . 11 3.2.1. Exploitation of Social Relationships ...............10
3.2.2. Identity-Related Fraud . . . . . . . . . . . . . . . . 11 3.2.2. Identity-Related Fraud .............................11
3.2.3. Reputation Attacks . . . . . . . . . . . . . . . . . . 12 3.2.3. Reputation Attacks .................................11
3.2.4. Reflection Attacks . . . . . . . . . . . . . . . . . . 12 3.2.4. Reflection Attacks .................................11
4. Attacks on Message Signing . . . . . . . . . . . . . . . . . . 12 4. Attacks on Message Signing .....................................12
4.1. Attacks Against Message Signatures . . . . . . . . . . . . 13 4.1. Attacks against Message Signatures ........................12
4.1.1. Theft of Private Key for Domain . . . . . . . . . . . 13 4.1.1. Theft of Private Key for Domain ....................13
4.1.2. Theft of Delegated Private Key . . . . . . . . . . . . 14 4.1.2. Theft of Delegated Private Key .....................13
4.1.3. Private Key Recovery via Side Channel Attack . . . . . 14 4.1.3. Private Key Recovery via Side Channel Attack .......14
4.1.4. Chosen Message Replay . . . . . . . . . . . . . . . . 15 4.1.4. Chosen Message Replay ..............................14
4.1.5. Signed Message Replay . . . . . . . . . . . . . . . . 16 4.1.5. Signed Message Replay ..............................16
4.1.6. Denial-of-Service Attack Against Verifier . . . . . . 17 4.1.6. Denial-of-Service Attack against Verifier ..........16
4.1.7. Denial-of-Service Attack Against Key Service . . . . . 17 4.1.7. Denial-of-Service Attack against Key Service .......17
4.1.8. Canonicalization Abuse . . . . . . . . . . . . . . . . 18 4.1.8. Canonicalization Abuse .............................17
4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 18 4.1.9. Body Length Limit Abuse ............................17
4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 19 4.1.10. Use of Revoked Key ................................18
4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 19 4.1.11. Compromise of Key Server ..........................18
4.1.12. Falsification of Key Service Replies . . . . . . . . . 20 4.1.12. Falsification of Key Service Replies ..............19
4.1.13. Publication of Malformed Key Records and/or 4.1.13. Publication of Malformed Key Records
Signatures . . . . . . . . . . . . . . . . . . . . . . 20 and/or Signatures .................................19
4.1.14. Cryptographic Weaknesses in Signature Generation . . . 20 4.1.14. Cryptographic Weaknesses in Signature Generation ..20
4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 21 4.1.15. Display Name Abuse ................................21
4.1.16. Compromised System Within Originator's Network . . . . 22 4.1.16. Compromised System within Originator's Network ....21
4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 22 4.1.17. Verification Probe Attack .........................21
4.1.18. Key Publication by Higher Level Domain . . . . . . . . 22 4.1.18. Key Publication by Higher-Level Domain ............22
4.2. Attacks Against Message Signing Policy . . . . . . . . . . 23 4.2. Attacks against Message Signing Practices .................23
4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 23 4.2.1. Look-Alike Domain Names ............................23
4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 24 4.2.2. Internationalized Domain Name Abuse ................23
4.2.3. Denial-of-Service Attack Against Signing Policy . . . 24 4.2.3. Denial-of-Service Attack against Signing
4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 24 Practices ..........................................24
4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 25 4.2.4. Use of Multiple From Addresses .....................24
4.2.6. Falsification of Sender Signing Policy Replies . . . . 25 4.2.5. Abuse of Third-Party Signatures ....................24
4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 25 4.2.6. Falsification of Sender Signing Practices Replies ..25
4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 26 4.3. Other Attacks .............................................25
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. Packet Amplification Attacks via DNS ...............25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. Derived Requirements ...........................................26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations ........................................26
8. Informative References . . . . . . . . . . . . . . . . . . . . 27 7. Informative References .........................................27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28 Appendix A. Acknowledgements ......................................28
Appendix B. Edit History . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
The DomainKeys Identified Mail (DKIM) protocol is being specified by The DomainKeys Identified Mail (DKIM) protocol is being specified by
the IETF DKIM Working Group. The DKIM protocol defines a mechanism the IETF DKIM Working Group. The DKIM protocol defines a mechanism
by which email messages can be cryptographically signed, permitting a by which email messages can be cryptographically signed, permitting a
signing domain to claim responsibility for the use of a given email signing domain to claim responsibility for the use of a given email
address. Message recipients can verify the signature by querying the address. Message recipients can verify the signature by querying the
signer's domain directly to retrieve the appropriate public key, and signer's domain directly to retrieve the appropriate public key, and
thereby confirm that the message was attested to by a party in thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain. 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 Once the attesting party or parties have been established, the
recipient may evaluate the message in the context of additional recipient may evaluate the message in the context of additional
information such as locally-maintained whitelists, shared reputation information such as locally-maintained whitelists, shared reputation
services, and/or third-party accreditation. The description of these services, and/or third-party accreditation. The description of these
mechanisms is outside the scope of the IETF DKIM Working Group mechanisms is outside the scope of the IETF DKIM Working Group
effort. By applying a signature, a good player enables a verifier to effort. By applying a signature, a good player enables a verifier to
associate a positive reputation with the message, in hopes that it associate a positive reputation with the message, in hopes that it
will receive preferential treatment by the recipient. will receive preferential treatment by the recipient.
skipping to change at page 4, line 39 skipping to change at page 3, line 48
1.1. Terminology and Model 1.1. Terminology and Model
An administrative unit (AU) is the portion of the path of an email An administrative unit (AU) is the portion of the path of an email
message that is under common administration. The originator and message that is under common administration. The originator and
recipient typically develop trust relationships with the recipient typically develop trust relationships with the
administrative units that send and receive their email, respectively, administrative units that send and receive their email, respectively,
to perform the signing and verification of their messages. to perform the signing and verification of their messages.
The origin address is the address on an email message, typically the The origin address is the address on an email message, typically the
RFC 2822 From: address, which is associated with the alleged author RFC 2822 From: address, which is associated with the alleged author
of the message and is displayed by the recipient's MUA as the source of the message and is displayed by the recipient's Mail User Agent
of the message. (MUA) as the source of the message.
The following diagram illustrates a typical usage flowchart for DKIM: The following diagram illustrates a typical usage flowchart for DKIM:
+---------------------------------+ +---------------------------------+
| SIGNATURE CREATION | | SIGNATURE CREATION |
| (Originating or Relaying AU) | | (Originating or Relaying AU) |
| | | |
| Sign (Message, Domain, Key) | | Sign (Message, Domain, Key) |
| | | |
+---------------------------------+ +---------------------------------+
skipping to change at page 6, line 10 skipping to change at page 5, line 10
a message arrives without any valid signatures, and the alleged a message arrives without any valid signatures, and the alleged
author's domain advertises that they sign all messages, the verifier author's domain advertises that they sign all messages, the verifier
might handle that message differently than if a signature was not might handle that message differently than if a signature was not
necessarily to be expected. necessarily to be expected.
1.2. Document Structure 1.2. Document Structure
The remainder of this document describes the problems that DKIM might The remainder of this document describes the problems that DKIM might
be expected to address, and the extent to which it may be successful 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 in so doing. These are described in terms of the potential bad
actors, their capabilities and location in the network, and in terms actors, their capabilities and location in the network, and the bad
of the bad acts that they might wish to commit. acts that they might wish to commit.
This is followed by a description of postulated attacks on DKIM This is followed by a description of postulated attacks on DKIM
message signing and on the use of Sender Signing Practices to assist message signing and on the use of Sender Signing Practices to assist
in the treatment of unsigned messages. A list of derived in the treatment of unsigned messages. A list of derived
requirements is also presented which is intended to guide the DKIM requirements is also presented, which is intended to guide the DKIM
design and review process. design and review process.
The sections dealing with attacks on DKIM each begin with a table The sections dealing with attacks on DKIM each begin with a table
summarizing the postulated attacks in each category along with their summarizing the postulated attacks in each category along with their
expected impact and likelihood. The following definitions were used expected impact and likelihood. The following definitions were used
as rough criteria for scoring the attacks: as rough criteria for scoring the attacks:
Impact: Impact:
High: Affects the verification of messages from an entire domain High: Affects the verification of messages from an entire domain
or multiple domains or multiple domains
Medium: Affects the verification of messages from specific users, Medium: Affects the verification of messages from specific users,
MTAs, and/or bounded time periods Mail Transfer Agents (MTAs), and/or bounded time periods
Low: Affects the verification of isolated individual messages only Low: Affects the verification of isolated individual messages
only
Likelihood: Likelihood:
High: All email users should expect this attack on a frequent High: All email users should expect this attack on a frequent
basis basis
Medium: Email users should expect this attack occasionally; Medium: Email users should expect this attack occasionally;
frequently for a few users frequently for a few users
Low: Attack is expected to be rare and/or very infrequent Low: Attack is expected to be rare and/or very infrequent
2. The Bad Actors 2. The Bad Actors
2.1. Characteristics 2.1. Characteristics
The problem space being addressed by DKIM is characterized by a wide The problem space being addressed by DKIM is characterized by a wide
range of attackers in terms of motivation, sophistication, and range of attackers in terms of motivation, sophistication, and
capabilities. capabilities.
At the low end of the spectrum are bad actors who may simply send At the low end of the spectrum are bad actors who may simply send
email, perhaps using one of many commercially available tools, which email, perhaps using one of many commercially available tools, that
the recipient does not want to receive. These tools typically allow the recipient does not want to receive. These tools typically allow
one to falsify the origin address of messages, and may, in the one to falsify the origin address of messages, and may, in the
future, be capable of generating message signatures as well. future, be capable of generating message signatures as well.
At the next tier are what would be considered "professional" senders At the next tier are what would be considered "professional" senders
of unwanted email. These attackers would deploy specific of unwanted email. These attackers would deploy specific
infrastructure, including Mail Transfer Agents (MTAs), registered infrastructure, including Mail Transfer Agents (MTAs), registered
domains and networks of compromised computers ("zombies") to send domains and networks of compromised computers ("zombies") to send
messages, and in some cases to harvest addresses to which to send. messages, and in some cases to harvest addresses to which to send.
These senders often operate as commercial enterprises and send These senders often operate as commercial enterprises and send
skipping to change at page 7, line 42 skipping to change at page 6, line 50
impersonate impersonate
2. Knowledge of the business aims and model for domains they might 2. Knowledge of the business aims and model for domains they might
wish to impersonate wish to impersonate
3. Access to public keys and associated authorization records 3. Access to public keys and associated authorization records
associated with the domain associated with the domain
and the ability to do at least some of the following: and the ability to do at least some of the following:
1. Submit messages to MTAs and MSAs at multiple locations in the 1. Submit messages to MTAs and Message Submission Agents (MSAs) at
Internet multiple locations in the Internet
2. Construct arbitrary message header fields, including those 2. Construct arbitrary message header fields, including those
claiming to be mailing lists, resenders, and other mail agents claiming to be mailing lists, resenders, and other mail agents
3. Sign messages on behalf of domains under their control 3. Sign messages on behalf of domains under their control
4. Generate substantial numbers of either unsigned or apparently- 4. Generate substantial numbers of either unsigned or apparently-
signed messages which might be used to attempt a denial of signed messages that might be used to attempt a denial-of-service
service attack attack
5. Resend messages which may have been previously signed by the
5. Resend messages that may have been previously signed by the
domain domain
6. Transmit messages using any envelope information desired 6. Transmit messages using any envelope information desired
7. Act as an authorized submitter for messages from a compromised 7. Act as an authorized submitter for messages from a compromised
computer computer
As noted above, certain classes of bad actors may have substantial As noted above, certain classes of bad actors may have substantial
financial motivation for their activities, and therefore should be financial motivation for their activities, and therefore should be
expected to have more capabilities at their disposal. These include: expected to have more capabilities at their disposal. These include:
1. Manipulation of IP routing. This could be used to submit 1. Manipulation of IP routing. This could be used to submit
messages from specific IP addresses or difficult-to-trace messages from specific IP addresses or difficult-to-trace
addresses, or to cause diversion of messages to a specific addresses, or to cause diversion of messages to a specific
domain. domain.
2. Limited influence over portions of DNS using mechanisms such as 2. Limited influence over portions of DNS using mechanisms such as
cache poisoning. This might be used to influence message cache poisoning. This might be used to influence message routing
routing, or to cause falsification of DNS-based key or policy or to falsify advertisements of DNS-based keys or signing
advertisements. practices.
3. Access to significant computing resources, for example through 3. Access to significant computing resources, for example, through
the conscription of worm-infected "zombie" computers. This could the conscription of worm-infected "zombie" computers. This could
allow the bad actor to perform various types of brute-force allow the bad actor to perform various types of brute-force
attacks. attacks.
4. Ability to eavesdrop on existing traffic, perhaps from a wireless 4. Ability to eavesdrop on existing traffic, perhaps from a wireless
network. network.
Either of the first two of these mechanisms could be used to allow 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 the bad actor to function as a man-in-the-middle between author and
recipient, if that attack is useful. recipient, if that attack is useful.
skipping to change at page 9, line 6 skipping to change at page 8, line 21
actors can also collude by acting from multiple locations (a actors can also collude by acting from multiple locations (a
"distributed bad actor"). "distributed bad actor").
It should also be noted that with the use of "zombies" and other It should also be noted that with the use of "zombies" and other
proxies, externally-located bad actors may gain some of the proxies, externally-located bad actors may gain some of the
capabilities of being located within the claimed originator's or capabilities of being located within the claimed originator's or
recipient's administrative unit. This emphasizes the importance of recipient's administrative unit. This emphasizes the importance of
appropriate security measures, such as authenticated submission of appropriate security measures, such as authenticated submission of
messages, even within administrative units. messages, even within administrative units.
2.3.1. Externally-located Bad Actors 2.3.1. Externally-Located Bad Actors
DKIM focuses primarily on bad actors located outside of the DKIM focuses primarily on bad actors located outside of the
administrative units of the claimed originator and the recipient. administrative units of the claimed originator and the recipient.
These administrative units frequently correspond to the protected These administrative units frequently correspond to the protected
portions of the network adjacent to the originator and recipient. It portions of the network adjacent to the originator and recipient. It
is in this area that the trust relationships required for is in this area that the trust relationships required for
authenticated message submission do not exist and do not scale authenticated message submission do not exist and do not scale
adequately to be practical. Conversely, within these administrative adequately to be practical. Conversely, within these administrative
units, there are other mechanisms such as authenticated message units, there are other mechanisms such as authenticated message
submission that are easier to deploy and more likely to be used than submission that are easier to deploy and more likely to be used than
DKIM. DKIM.
External bad actors are usually attempting to exploit the "any to External bad actors are usually attempting to exploit the "any to
any" nature of email which motivates most recipient MTAs to accept any" nature of email that motivates most recipient MTAs to accept
messages from anywhere for delivery to their local domain. They may messages from anywhere for delivery to their local domain. They may
generate messages without signatures, with incorrect signatures, or generate messages without signatures, with incorrect signatures, or
with correct signatures from domains with little traceability. They with correct signatures from domains with little traceability. They
may also pose as mailing lists, greeting cards, or other agents which may also pose as mailing lists, greeting cards, or other agents that
legitimately send or re-send messages on behalf of others. legitimately send or resend messages on behalf of others.
2.3.2. Within Claimed Originator's Administrative Unit 2.3.2. Within Claimed Originator's Administrative Unit
Bad actors in the form of rogue or unauthorized users or malware- Bad actors in the form of rogue or unauthorized users or malware-
infected computers can exist within the administrative unit infected computers can exist within the administrative unit
corresponding to a message's origin address. Since the submission of corresponding to a message's origin address. Since the submission of
messages in this area generally occurs prior to the application of a messages in this area generally occurs prior to the application of a
message signature, DKIM is not directly effective against these bad message signature, DKIM is not directly effective against these bad
actors. Defense against these bad actors is dependent upon other actors. Defense against these bad actors is dependent upon other
means, such as proper use of firewalls, and mail submission agents means, such as proper use of firewalls, and Message Submission Agents
that are configured to authenticate the author. that are configured to authenticate the author.
In the special case where the administrative unit is non-contiguous In the special case where the administrative unit is non-contiguous
(e.g., a company that communicates between branches over the external (e.g., a company that communicates between branches over the external
Internet), DKIM signatures can be used to distinguish between Internet), DKIM signatures can be used to distinguish between
legitimate externally-originated messages and attempts to spoof legitimate externally-originated messages and attempts to spoof
addresses in the local domain. addresses in the local domain.
2.3.3. Within Recipient's Administrative Unit 2.3.3. Within Recipient's Administrative Unit
Bad actors may also exist within the administrative unit of the Bad actors may also exist within the administrative unit of the
message recipient. These bad actors may attempt to exploit the trust message recipient. These bad actors may attempt to exploit the trust
relationships which exist within the unit. Since messages will relationships that exist within the unit. Since messages will
typically only have undergone DKIM verification at the administrative typically only have undergone DKIM verification at the administrative
unit boundary, DKIM is not effective against messages submitted in unit boundary, DKIM is not effective against messages submitted in
this area. this area.
For example, the bad actor may attempt to spoof a header field For example, the bad actor may attempt to spoof a header field
indicating the results of verification. This header field would indicating the results of verification. This header field would
normally be added by the verifier, which would also detect spoofed normally be added by the verifier, which would also detect spoofed
header fields on messages it was attempting to verify. This could be header fields on messages it was attempting to verify. This could be
used to falsely indicate that the message was authenticated used to falsely indicate that the message was authenticated
successfully. successfully.
As in the originator case, these bad actors can be dealt with by As in the originator case, these bad actors can be dealt with by
controlling the submission of messages within the administrative controlling the submission of messages within the administrative
unit. Since DKIM permits verification to occur anywhere within the unit. Since DKIM permits verification to occur anywhere within the
recipient's administrative unit, these threats can also be minimized recipient's administrative unit, these threats can also be minimized
by moving verification closer to the recipient, such as at the mail by moving verification closer to the recipient, such as at the Mail
delivery agent (MDA), or on the recipient's MUA itself. Delivery Agent (MDA), or on the recipient's MUA itself.
3. Representative Bad Acts 3. Representative Bad Acts
One of the most fundamental bad acts being attempted is the delivery One of the most fundamental bad acts being attempted is the delivery
of messages which are not intended to have been sent by the alleged of messages that are not intended to have been sent by the alleged
originating domain. As described above, these messages might merely originating domain. As described above, these messages might merely
be unwanted by the recipient, or might be part of a confidence scheme be unwanted by the recipient, or might be part of a confidence scheme
or a delivery vector for malware. or a delivery vector for malware.
3.1. Use of Arbitrary Identities 3.1. Use of Arbitrary Identities
This class of bad acts includes the sending of messages which aim to 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 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- 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 party under the control of the bad actor (e.g., a compromised
computer). computer).
Particularly when coupled with sender signing practices that indicate Particularly when coupled with sender signing practices that indicate
the domain owner signs all messages, DKIM can be effective in the domain owner signs all messages, DKIM can be effective in
mitigating against the abuse of addresses not controlled by bad mitigating against the abuse of addresses not controlled by bad
actors. DKIM is not effective against the use of addresses actors. DKIM is not effective against the use of addresses
controlled by bad actors. In other words, the presence of a valid 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. DKIM signature does not guarantee that the signer is not a bad actor.
It also does not guarantee the accountability of the signer, since It also does not guarantee the accountability of the signer, since
DKIM does not attempt to identify the signer individually, but rather DKIM does not attempt to identify the signer individually, but rather
identifies the domain which they control. Accreditation and identifies the domain that they control. Accreditation and
reputation systems and locally-maintained whitelists and blacklists reputation systems and locally-maintained whitelists and blacklists
can be used to enhance the accountability of DKIM-verified addresses can be used to enhance the accountability of DKIM-verified addresses
and/or the likelihood that signed messages are desirable. and/or the likelihood that signed messages are desirable.
3.2. Use of Specific Identities 3.2. Use of Specific Identities
A second major class of bad acts involves the assertion of specific A second major class of bad acts involves the assertion of specific
identities in email. identities in email.
Note that some bad acts involving specific identities can sometimes Note that some bad acts involving specific identities can sometimes
be accomplished, although perhaps less effectively, with similar be accomplished, although perhaps less effectively, with similar
looking identities that mislead some recipients. For example, if the looking identities that mislead some recipients. For example, if the
bad actor is able to control the domain "examp1e.com" (note the "one" 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 between the p and e), they might be able to convince some recipients
that a message from admin@examp1e.com is really admin@example.com. that a message from admin@examp1e.com is really from
Similar types of attacks using internationalized domain names have admin@example.com. Similar types of attacks using internationalized
been hypothesized where it could be very difficult to see character domain names have been hypothesized where it could be very difficult
differences in popular typefaces. Similarly, if example2.com was to see character differences in popular typefaces. Similarly, if
controlled by a bad actor, the bad actor could sign messages from example2.com was controlled by a bad actor, the bad actor could sign
bigbank.example2.com which might also mislead some recipients. To messages from bigbank.example2.com, which might also mislead some
the extent that these domains are controlled by bad actors, DKIM is recipients. To the extent that these domains are controlled by bad
not effective against these attacks, although it could support the actors, DKIM is not effective against these attacks, although it
ability of reputation and/or accreditation systems to aid the user in could support the ability of reputation and/or accreditation systems
identifying them. to aid the user in identifying them.
DKIM is effective against the use of specific identities only when DKIM is effective against the use of specific identities only when
there is an expectation that such messages will, in fact, be signed. there is an expectation that such messages will, in fact, be signed.
The primary means for establishing this is the use of Sender Signing The primary means for establishing this is the use of Sender Signing
Practices (SSP), which will be specified by the IETF DKIM Working Practices (SSP), which will be specified by the IETF DKIM Working
Group. Group.
3.2.1. Exploitation of Social Relationships 3.2.1. Exploitation of Social Relationships
One reason for asserting a specific origin address is to encourage a One reason for asserting a specific origin address is to encourage a
recipient to read and act on particular email messages by appearing recipient to read and act on particular email messages by appearing
to be an acquaintance or previous correspondent that the recipient to be an acquaintance or previous correspondent that the recipient
might trust. This tactic has been used by email-propagated malware might trust. This tactic has been used by email-propagated malware
which mail themselves to addresses in the infected host's address that mail themselves to addresses in the infected host's address
book. In this case, however, the author's address may not be book. In this case, however, the author's address may not be
falsified, so DKIM would not be effective in defending against this falsified, so DKIM would not be effective in defending against this
act. act.
It is also possible for address books to be harvested and used by an 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 attacker to post messages from elsewhere. DKIM could be effective in
mitigating these acts by limiting the scope of origin addresses for mitigating these acts by limiting the scope of origin addresses for
which a valid signature can be obtained when sending the messages which a valid signature can be obtained when sending the messages
from other locations. from other locations.
skipping to change at page 12, line 20 skipping to change at page 11, line 35
When signatures are verified by or for the recipient, DKIM is When signatures are verified by or for the recipient, DKIM is
effective in defending against the fraudulent use of origin addresses effective in defending against the fraudulent use of origin addresses
on signed messages. When the published sender signing practices of on signed messages. When the published sender signing practices of
the origin address indicate that all messages from that address the origin address indicate that all messages from that address
should be signed, DKIM further mitigates against the attempted should be signed, DKIM further mitigates against the attempted
fraudulent use of the origin address on unsigned messages. fraudulent use of the origin address on unsigned messages.
3.2.3. Reputation Attacks 3.2.3. Reputation Attacks
Another motivation for using a specific origin address in a message Another motivation for using a specific origin address in a message
is to harm the reputation of another, commonly referred to as a "joe- is to harm the reputation of another, commonly referred to as a
job". For example, a commercial entity might wish to harm the "joe-job". For example, a commercial entity might wish to harm the
reputation of a competitor, perhaps by sending unsolicited bulk email reputation of a competitor, perhaps by sending unsolicited bulk email
on behalf of that competitor. It is for this reason that reputation on behalf of that competitor. It is for this reason that reputation
systems must be based on an identity that is, in practice, fairly systems must be based on an identity that is, in practice, fairly
reliable. reliable.
3.2.4. Reflection Attacks 3.2.4. Reflection Attacks
A commonly-used tactic by some bad actors is the indirect A commonly-used tactic by some bad actors is the indirect
transmission of messages by intentionally mis-addressing the message transmission of messages by intentionally mis-addressing the message
and causing it to be "bounced", or sent to the return address and causing it to be "bounced", or sent to the return address (RFC
(RFC2821 envelope-from address) on the message. In this case, the 2821 envelope-from address) on the message. In this case, the
specific identity asserted in the email is that of the actual target specific identity asserted in the email is that of the actual target
of the message, to whom the message is "returned". of the message, to whom the message is "returned".
DKIM does not, in general, attempt to validate the RFC2821.mailfrom DKIM does not, in general, attempt to validate the RFC2821.mailfrom
return address on messages, either directly (noting that the mailfrom return address on messages, either directly (noting that the mailfrom
address is an element of the SMTP protocol, and not the message address is an element of the SMTP protocol, and not the message
content on which DKIM operates), or via the optional Return-Path content on which DKIM operates), or via the optional Return-Path
header field. Furthermore, as is noted in section 4.4 of RFC 2821 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 [RFC2821], it is common and useful practice for a message's return
path not to correspond to the origin address. For these reasons, path not to correspond to the origin address. For these reasons,
DKIM is not effective against reflection attacks. DKIM is not effective against reflection attacks.
4. Attacks on Message Signing 4. Attacks on Message Signing
Bad actors can be expected to exploit all of the limitations of Bad actors can be expected to exploit all of the limitations of
message authentication systems. They are also likely to be motivated message authentication systems. They are also likely to be motivated
to degrade the usefulness of message authentication systems in order to degrade the usefulness of message authentication systems in order
to hinder their deployment. Both the signature mechanism itself and to hinder their deployment. Both the signature mechanism itself and
declarations made regarding use of message signatures (referred to declarations made regarding use of message signatures (referred to
here as Sender Signing Practices or SSP) can be expected to be the here as Sender Signing Practices or SSP) can be expected to be the
target of attacks. target of attacks.
4.1. Attacks Against Message Signatures 4.1. Attacks against Message Signatures
Summary of postulated attacks against DKIM signatures: The following is a summary of postulated attacks against DKIM
signatures:
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood | | Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
| Theft of private key for domain | High | Low | | Theft of private key for domain | High | Low |
| Theft of delegated private key | Medium | Medium | | Theft of delegated private key | Medium | Medium |
| Private key recovery via side channel | High | Low | | Private key recovery via side channel attack| High | Low |
| attack | | |
| Chosen message replay | Low | M/H | | Chosen message replay | Low | M/H |
| Signed message replay | Low | High | | Signed message replay | Low | High |
| Denial-of-service attack against verifier | High | Medium | | Denial-of-service attack against verifier | High | Medium |
| Denial-of-service attack against key | High | Medium | | Denial-of-service attack against key service| High | Medium |
| service | | |
| Canonicalization abuse | Low | Medium | | Canonicalization abuse | Low | Medium |
| Body length limit abuse | Medium | Medium | | Body length limit abuse | Medium | Medium |
| Use of revoked key | Medium | Low | | Use of revoked key | Medium | Low |
| Compromise of key server | High | Low | | Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium | | Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low | | Publication of malformed key records and/or | High | Low |
| signatures | | | | signatures | | |
| Cryptographic weaknesses in signature | High | Low | | Cryptographic weaknesses in signature | High | Low |
| generation | | | | generation | | |
| Display name abuse | Medium | High | | Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium | | Compromised system within originator's | High | Medium |
| network | | | | network | | |
| Verification probe attack | Medium | Medium | | Verification probe attack | Medium | Medium |
| Key publication by higher level domain | High | Low | | Key publication by higher-level domain | High | Low |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
4.1.1. Theft of Private Key for Domain 4.1.1. Theft of Private Key for Domain
Message signing technologies such as DKIM are vulnerable to theft of Message signing technologies such as DKIM are vulnerable to theft of
the private keys used to sign messages. This includes "out-of-band" the private keys used to sign messages. This includes "out-of-band"
means for this theft, such as burglary, bribery, extortion, and the means for this theft, such as burglary, bribery, extortion, and the
like, as well as electronic means for such theft, such as a like, as well as electronic means for such theft, such as a
compromise of network and host security around the place where a compromise of network and host security around the place where a
private key is stored. private key is stored.
Keys which are valid for all addresses in a domain typically reside Keys that are valid for all addresses in a domain typically reside in
in MTAs which should be located in well-protected sites, such as data MTAs that should be located in well-protected sites, such as data
centers. Various means should be employed for minimizing access to centers. Various means should be employed for minimizing access to
private keys, such as non-existence of commands for displaying their private keys, such as non-existence of commands for displaying their
value, although ultimately memory dumps and the like will probably value, although ultimately memory dumps and the like will probably
contain the keys. Due to the unattended nature of MTAs, some contain the keys. Due to the unattended nature of MTAs, some
countermeasures, such as the use of a pass phrase to "unlock" a key, 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 are not practical to use. Other mechanisms, such as the use of
dedicated hardware devices which contain the private key and perform dedicated hardware devices that contain the private key and perform
the cryptographic signature operation, would be very effective in the cryptographic signature operation, would be very effective in
denying export of the private key to those without physical access to denying export of the private key to those without physical access to
the device. Such devices would almost certainly make the theft of the device. Such devices would almost certainly make the theft of
the key visible, so that appropriate action (revocation of the the key visible, so that appropriate action (revocation of the
corresponding public key) can be taken should that happen. corresponding public key) can be taken should that happen.
4.1.2. Theft of Delegated Private Key 4.1.2. Theft of Delegated Private Key
There are several circumstances where a domain owner will want to There are several circumstances where a domain owner will want to
delegate the ability to sign messages for the domain to an individual delegate the ability to sign messages for the domain to an individual
user or a third-party associated with an outsourced activity such as user or a third party associated with an outsourced activity such as
a corporate benefits administrator or a marketing campaign. Since a corporate benefits administrator or a marketing campaign. Since
these keys may exist on less well-protected devices than the domain's 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. own MTAs, they will in many cases be more susceptible to compromise.
In order to mitigate this exposure, keys used to sign such messages In order to mitigate this exposure, keys used to sign such messages
can be restricted by the domain owner to be valid for signing can be restricted by the domain owner to be valid for signing
messages only on behalf of specific addresses in the domain. This messages only on behalf of specific addresses in the domain. This
maintains protection for the majority of addresses in the domain. maintains protection for the majority of addresses in the domain.
A related threat is the exploitation of weaknesses in the delegation A related threat is the exploitation of weaknesses in the delegation
skipping to change at page 14, line 51 skipping to change at page 14, line 17
All popular digital signature algorithms are subject to a variety of All popular digital signature algorithms are subject to a variety of
side channel attacks. The most well-known of these are timing side channel attacks. The most well-known of these are timing
channels [Kocher96], power analysis [Kocher99], and cache timing channels [Kocher96], power analysis [Kocher99], and cache timing
analysis [Bernstein04]. Most of these attacks require either analysis [Bernstein04]. Most of these attacks require either
physical access to the machine or the ability to run processes physical access to the machine or the ability to run processes
directly on the target machine. Defending against these attacks is directly on the target machine. Defending against these attacks is
out of scope for DKIM. out of scope for DKIM.
However, remote timing analysis (at least on local area networks) is However, remote timing analysis (at least on local area networks) is
known to be feasible [Boneh03], particularly in server-type platforms known to be feasible [Boneh03], particularly in server-type platforms
where the attacker can inject traffic which will immediately subject where the attacker can inject traffic that will immediately be
to the cryptographic operation in question. With enough samples, subject to the cryptographic operation in question. With enough
these techniques can be used to extract private keys even in the face samples, these techniques can be used to extract private keys even in
of modest amounts of noise in the timing measurements. the face of modest amounts of noise in the timing measurements.
The three commonly proposed countermeasures against timing analysis The three commonly proposed countermeasures against timing analysis
are: are:
1. Make the operation run in constant time. This turns out in 1. Make the operation run in constant time. This turns out in
practice to be rather difficult. practice to be rather difficult.
2. Make the time independent of the input data. This can be 2. Make the time independent of the input data. This can be
difficult but see [Boneh03] for more details. difficult, but see [Boneh03] for more details.
3. Use blinding. This is generally considered the best current 3. Use blinding. This is generally considered the best current
practice countermeasure, and while not proved generally secure is practice countermeasure, and while not proved generally secure is
a countermeasure against known timing attacks. It adds about a countermeasure against known timing attacks. It adds about
2-10% to the cost of the operation and is implemented in many 2-10% to the cost of the operation and is implemented in many
common cryptographic libraries. Unfortunately, Digital Signature common cryptographic libraries. Unfortunately, Digital Signature
Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have
standard methods though some defenses may exist. standard methods though some defenses may exist.
Note that adding random delays to the operation is only a partial Note that adding random delays to the operation is only a partial
countermeasure. Because the noise is generally uniformly countermeasure. Because the noise is generally uniformly
distributed, a large enough number of samples can be used to average distributed, a large enough number of samples can be used to average
it out and extract an accurate timing signal. it out and extract an accurate timing signal.
4.1.4. Chosen Message Replay 4.1.4. Chosen Message Replay
Chosen message replay refers to the scenario where the attacker Chosen message replay refers to the scenario where the attacker
creates a message and obtains a signature for it by sending it creates a message and obtains a signature for it by sending it
through an MTA authorized by the originating domain to him/herself or through an MTA authorized by the originating domain to
an accomplice. They then "replay" the signed message by sending it, himself/herself or an accomplice. They then "replay" the signed
using different envelope addresses, to a (typically large) number of message by sending it, using different envelope addresses, to a
other recipients. (typically large) number of other recipients.
Due to the requirement to get an attacker-generated message signed, Due to the requirement to get an attacker-generated message signed,
chosen message replay would most commonly be experienced by consumer chosen message replay would most commonly be experienced by consumer
ISPs or others offering email accounts to clients, particularly where ISPs or others offering email accounts to clients, particularly where
there is little or no accountability to the account holder (the there is little or no accountability to the account holder (the
attacker in this case). One approach to solving this problem is for 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 the domain to only sign email for clients that have passed a vetting
process to provide traceability to the message originator in the process to provide traceability to the message originator in the
event of abuse. At present, the low cost of email accounts (zero) 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 does not make it practical for any vetting to occur. It remains to
skipping to change at page 16, line 30 skipping to change at page 15, line 43
likelihood that domains will use a small number of signing keys for a likelihood that domains will use a small number of signing keys for a
large number of customers, which is beneficial from a caching large number of customers, which is beneficial from a caching
standpoint but is likely to result in a great deal of collateral standpoint but is likely to result in a great deal of collateral
damage (in the form of signature verification failures) should a key damage (in the form of signature verification failures) should a key
be revoked suddenly. be revoked suddenly.
Signature revocation addresses the collateral damage problem at the Signature revocation addresses the collateral damage problem at the
expense of significant scaling requirements. At the extreme, expense of significant scaling requirements. At the extreme,
verifiers could be required to check for revocation of each signature verifiers could be required to check for revocation of each signature
verified, which would result in very significant transaction rates. verified, which would result in very significant transaction rates.
An alternative, "revocation identifiers", has been proposed which An alternative, "revocation identifiers", has been proposed, which
would permit revocation on an intermediate level of granularity, would permit revocation on an intermediate level of granularity,
perhaps on a per-account basis. Messages containing these perhaps on a per-account basis. Messages containing these
identifiers would result in a query to a revocation database, which identifiers would result in a query to a revocation database, which
might be represented in DNS. might be represented in DNS.
Further study is needed to determine if the benefits from revocation Further study is needed to determine if the benefits from revocation
(given the potential speed of a replay attack) outweigh the (given the potential speed of a replay attack) outweigh the
transactional cost of querying a revocation database. transactional cost of querying a revocation database.
4.1.5. Signed Message Replay 4.1.5. Signed Message Replay
skipping to change at page 17, line 9 skipping to change at page 16, line 23
large amount of spam. When reputation services are deployed, this large amount of spam. When reputation services are deployed, this
could damage the author's reputation or that of the author's domain. could damage the author's reputation or that of the author's domain.
A larger number of domains are potential victims of signed message A larger number of domains are potential victims of signed message
replay than chosen message replay because the former does not require replay than chosen message replay because the former does not require
the ability for the attacker to send messages from the victim domain. the ability for the attacker to send messages from the victim domain.
However, the capabilities of the attacker are lower. Unless coupled However, the capabilities of the attacker are lower. Unless coupled
with another attack such as body length limit abuse, it isn't with another attack such as body length limit abuse, it isn't
possible for the attacker to use this, for example, for advertising. possible for the attacker to use this, for example, for advertising.
Many mailing lists, especially those which do not modify the content Many mailing lists, especially those that do not modify the content
of the message and signed header fields and hence do not invalidate 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 the signature, engage in a form of signed message replay. The use of
body length limits and other mechanisms to enhance the survivability body length limits and other mechanisms to enhance the survivability
of messages effectively enhances the ability to do so. The only of messages effectively enhances the ability to do so. The only
things that distinguish this case from undesirable forms of signed things that distinguish this case from undesirable forms of signed
message replay is the intent of the replayer, which cannot be message replay is the intent of the replayer, which cannot be
determined by the network. determined by the network.
4.1.6. Denial-of-Service Attack Against Verifier 4.1.6. Denial-of-Service Attack against Verifier
While it takes some compute resources to sign and verify a signature, While it takes some computing resources to sign and verify a
it takes negligible compute resources to generate an invalid signature, it takes negligible computing resources to generate an
signature. An attacker could therefore construct a "make work" invalid signature. An attacker could therefore construct a "make
attack against a verifier, by sending a large number of incorrectly- work" attack against a verifier, by sending a large number of
signed messages to a given verifier, perhaps with multiple signatures incorrectly-signed messages to a given verifier, perhaps with
each. The motivation might be to make it too expensive to verify multiple signatures each. The motivation might be to make it too
messages. expensive to verify messages.
While this attack is feasible, it can be greatly mitigated by the While this attack is feasible, it can be greatly mitigated by the
manner in which the verifier operates. For example, it might decide manner in which the verifier operates. For example, it might decide
to accept only a certain number of signatures per message, limit the to accept only a certain number of signatures per message, limit the
maximum key size it will accept (to prevent outrageously large maximum key size it will accept (to prevent outrageously large
signatures from causing unneeded work), and verify signatures in a signatures from causing unneeded work), and verify signatures in a
particular order. The verifier could also maintain state particular order. The verifier could also maintain state
representing the current signature verification failure rate and representing the current signature verification failure rate and
adopt a defensive posture when attacks may be underway. adopt a defensive posture when attacks may be underway.
4.1.7. Denial-of-Service Attack Against Key Service 4.1.7. Denial-of-Service Attack against Key Service
An attacker might also attempt to degrade the availability of an An attacker might also attempt to degrade the availability of an
originator's key service, in order to cause that originator's originator's key service, in order to cause that originator's
messages to be unverifiable. One way to do this might be to quickly messages to be unverifiable. One way to do this might be to quickly
send a large number of messages with signatures which reference a send a large number of messages with signatures that reference a
particular key, thereby creating a heavy load on the key server. particular key, thereby creating a heavy load on the key server.
Other types of DoS attacks on the key server or the network Other types of DoS attacks on the key server or the network
infrastructure serving it are also possible. infrastructure serving it are also possible.
The best defense against this attack is to provide redundant key The best defense against this attack is to provide redundant key
servers, preferably on geographically-separate parts of the Internet. servers, preferably on geographically-separate parts of the Internet.
Caching also helps a great deal, by decreasing the load on Caching also helps a great deal, by decreasing the load on
authoritative key servers when there are many simultaneous key authoritative key servers when there are many simultaneous key
requests. The use of a key service protocol which minimizes the requests. The use of a key service protocol that minimizes the
transactional cost of key lookups is also beneficial. It is noted transactional cost of key lookups is also beneficial. It is noted
that the Domain Name System has all these characteristics. that the Domain Name System has all these characteristics.
4.1.8. Canonicalization Abuse 4.1.8. Canonicalization Abuse
Canonicalization algorithms represent a tradeoff between the survival Canonicalization algorithms represent a tradeoff between the survival
of the validity of a message signature and the desire not to allow of the validity of a message signature and the desire not to allow
the message to be altered inappropriately. In the past, the message to be altered inappropriately. In the past,
canonicalization algorithms have been proposed which would have canonicalization algorithms have been proposed that would have
permitted attackers, in some cases, to alter the meaning of a permitted attackers, in some cases, to alter the meaning of a
message. message.
Message signatures which support multiple canonicalization algorithms Message signatures that support multiple canonicalization algorithms
give the signer the ability to decide the relative importance of give the signer the ability to decide the relative importance of
signature survivability and immutability of the signed content. If signature survivability and immutability of the signed content. If
an unexpected vulnerability appears in a canonicalization algorithm an unexpected vulnerability appears in a canonicalization algorithm
in general use, new algorithms can be deployed, although it will be a 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) slow process because the signer can never be sure which algorithm(s)
the verifier supports. For this reason, canonicalization algorithms, the verifier supports. For this reason, canonicalization algorithms,
like cryptographic algorithms, should undergo a wide and careful like cryptographic algorithms, should undergo a wide and careful
review process. review process.
4.1.9. Body Length Limit Abuse 4.1.9. Body Length Limit Abuse
A body length limit is an optional indication from the signer how A body length limit is an optional indication from the signer of how
much content has been signed. The verifier can either ignore the much content has been signed. The verifier can either ignore the
limit, verify the specified portion of the message, or truncate the limit, verify the specified portion of the message, or truncate the
message to the specified portion and verify it. The motivation for message to the specified portion and verify it. The motivation for
this feature is the behavior of many mailing lists which add a this feature is the behavior of many mailing lists that add a
trailer, perhaps identifying the list, at the end of messages. trailer, perhaps identifying the list, at the end of messages.
When body length limits are used, there is the potential for an 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 attacker to add content to the message. It has been shown that this
content, although at the end, can cover desirable content, especially content, although at the end, can cover desirable content, especially
in the case of HTML messages. in the case of HTML messages.
If the body length isn't specified, or if the verifier decides to 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 ignore the limit, body length limits are moot. If the verifier or
recipient truncates the message at the signed content, there is no recipient truncates the message at the signed content, there is no
skipping to change at page 19, line 8 skipping to change at page 18, line 25
If the verifier observes body length limits when present, there is If the verifier observes body length limits when present, there is
the potential that an attacker can make undesired content visible to the potential that an attacker can make undesired content visible to
the recipient. The size of the appended content makes little the recipient. The size of the appended content makes little
difference, because it can simply be a URL reference pointing to the difference, because it can simply be a URL reference pointing to the
actual content. Receiving MUAs can mitigate this threat by, at a actual content. Receiving MUAs can mitigate this threat by, at a
minimum, identifying the unsigned content in the message. minimum, identifying the unsigned content in the message.
4.1.10. Use of Revoked Key 4.1.10. Use of Revoked Key
The benefits obtained by caching of key records opens the possibility The benefits obtained by caching of key records opens the possibility
that keys which have been revoked may be used for some period of time 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 after their revocation. The best examples of this occur when a
holder of a key delegated by the domain administrator must be holder of a key delegated by the domain administrator must be
unexpectedly deauthorized from sending mail on behalf of one or more unexpectedly deauthorized from sending mail on behalf of one or more
addresses in the domain. addresses in the domain.
The caching of key records is normally short-lived, on the order of 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 hours to days. In many cases, this threat can be mitigated simply by
setting a short time-to-live for keys not under the domain setting a short time-to-live (TTL) for keys not under the domain
administrator's direct control (assuming, of course, that control of administrator's direct control (assuming, of course, that control of
the time-to-live value may be specified for each record, as it can the TTL value may be specified for each record, as it can with DNS).
with DNS). In some cases, such as the recovery following a stolen In some cases, such as the recovery following a stolen private key
private key belonging to one of the domain's MTAs, the possibility of belonging to one of the domain's MTAs, the possibility of theft and
theft and the effort required to revoke the key authorization must be the effort required to revoke the key authorization must be
considered when choosing a TTL. The chosen TTL must be long enough considered when choosing a TTL. The chosen TTL must be long enough
to mitigate denial-of-service attacks and provide reasonable to mitigate denial-of-service attacks and provide reasonable
transaction efficiency, and no longer. transaction efficiency, and no longer.
4.1.11. Compromise of Key Server 4.1.11. Compromise of Key Server
Rather than by attempting to obtain a private key, an attacker might 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 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 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 attacker to sign messages on behalf of the domain. This attack
skipping to change at page 19, line 47 skipping to change at page 19, line 16
authorized by the owner of a signing domain, a relationship must be authorized by the owner of a signing domain, a relationship must be
established between the signing address and the location from which a established between the signing address and the location from which a
public key is obtained to verify the message. DKIM does this by 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 publishing either the public key or a reference to it within the DNS
hierarchy of the signing domain. The verifier derives the location hierarchy of the signing domain. The verifier derives the location
from which to retrieve the public key from the signing address or from which to retrieve the public key from the signing address or
domain. The security of the verification process is therefore domain. The security of the verification process is therefore
dependent on the security of the DNS hierarchy for the signing dependent on the security of the DNS hierarchy for the signing
domain. domain.
An attacker might successfully compromise the host which is the An attacker might successfully compromise the host that is the
primary key server for the signing domain, such as the domain's DNS primary key server for the signing domain, such as the domain's DNS
master server. Another approach might be to compromise a higher- master server. Another approach might be to compromise a higher-
level DNS server and change the delegation of name servers for the level DNS server and change the delegation of name servers for the
signing domain to others under the control of the attacker. signing domain to others under the control of the attacker.
This attack can be mitigated somewhat by independent monitoring to This attack can be mitigated somewhat by independent monitoring to
audit the key service. Such auditing of the key service should occur 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 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. server, so that the addition of records to the zone can be detected.
skipping to change at page 20, line 22 skipping to change at page 19, line 39
Replies from the key service may also be spoofed by a suitably Replies from the key service may also be spoofed by a suitably
positioned attacker. For DNS, one such way to do this is "cache positioned attacker. For DNS, one such way to do this is "cache
poisoning", in which the attacker provides unnecessary (and poisoning", in which the attacker provides unnecessary (and
incorrect) additional information in DNS replies, which is cached. incorrect) additional information in DNS replies, which is cached.
DNSSEC [RFC4033] is the preferred means of mitigating this threat, DNSSEC [RFC4033] is the preferred means of mitigating this threat,
but the current uptake rate for DNSSEC is slow enough that one would 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 not like to create a dependency on its deployment. In the case of a
cache poisoning attack, the vulnerabilities created by this attack cache poisoning attack, the vulnerabilities created by this attack
are both localized and of limited duration, although records with are both localized and of limited duration, although records with
relatively long TTL may be persist beyond the attack itself. relatively long TTL may persist beyond the attack itself.
4.1.13. Publication of Malformed Key Records and/or Signatures 4.1.13. Publication of Malformed Key Records and/or Signatures
In this attack, the attacker publishes suitably crafted key records In this attack, the attacker publishes suitably crafted key records
or sends mail with intentionally malformed signatures, in an attempt or sends mail with intentionally malformed signatures, in an attempt
to confuse the verifier and perhaps disable verification altogether. to confuse the verifier and perhaps disable verification altogether.
This attack is really a characteristic of an implementation This attack is really a characteristic of an implementation
vulnerability, a buffer overflow or lack of bounds checking, for vulnerability, a buffer overflow or lack of bounds checking, for
example, rather than a vulnerability of the signature mechanism example, rather than a vulnerability of the signature mechanism
itself. This threat is best mitigated by careful implementation and itself. This threat is best mitigated by careful implementation and
creation of test suites that challenge the verification process. creation of test suites that challenge the verification process.
4.1.14. Cryptographic Weaknesses in Signature Generation 4.1.14. Cryptographic Weaknesses in Signature Generation
The cryptographic algorithms used to generate mail signatures, The cryptographic algorithms used to generate mail signatures,
specifically the hash algorithm and digital signature generation and specifically the hash algorithm and digital signature generation and
verification operations, may over time be subject to mathematical verification operations, may over time be subject to mathematical
techniques that degrade their security. At this writing, the SHA-1 techniques that degrade their security. At this writing, the SHA-1
hash algorithm is the subject of extensive mathematical analysis hash algorithm is the subject of extensive mathematical analysis that
which has considerably lowered the time required to create two has considerably lowered the time required to create two messages
messages with the same hash value. This trend can be expected to with the same hash value. This trend can be expected to continue.
continue.
One consequence of a weakness in the hash algorithm is a hash One consequence of a weakness in the hash algorithm is a hash
collision attack. Hash collision attacks in message signing systems collision attack. Hash collision attacks in message signing systems
involve the same person creating two different messages that have the involve the same person creating two different messages that have the
same hash value, where only one of the two messages would normally be same hash value, where only one of the two messages would normally be
signed. The attack is based on the second message inheriting the signed. The attack is based on the second message inheriting the
signature of the first. For DKIM, this means that a sender might 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 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 signing party's site would sign the good message but not the bad
message. The attacker gets the good message signed, and then message. The attacker gets the good message signed, and then
skipping to change at page 21, line 22 skipping to change at page 20, line 40
becomes more readily available, such an attack could become becomes more readily available, such an attack could become
achievable. achievable.
The message signature system must be designed to support multiple The message signature system must be designed to support multiple
signature and hash algorithms, and the signing domain must be able to signature and hash algorithms, and the signing domain must be able to
specify which algorithms it uses to sign messages. The choice of specify which algorithms it uses to sign messages. The choice of
algorithms must be published in key records, and not only in the algorithms must be published in key records, and not only in the
signature itself, to ensure that an attacker is not able to create signature itself, to ensure that an attacker is not able to create
signatures using algorithms weaker than the domain wishes to permit. signatures using algorithms weaker than the domain wishes to permit.
Due to the fact that the signer and verifier of email do not, in Because the signer and verifier of email do not, in general,
general, communicate directly, negotiation of the algorithms used for communicate directly, negotiation of the algorithms used for signing
signing cannot occur. In other words, a signer has no way of knowing cannot occur. In other words, a signer has no way of knowing which
which algorithm(s) a verifier supports, nor (due to mail forwarding) algorithm(s) a verifier supports or (due to mail forwarding) where
where the verifier is. For this reason, it is expected that once the verifier is. For this reason, it is expected that once message
message signing is widely deployed, algorithm change will occur signing is widely deployed, algorithm change will occur slowly, and
slowly, and legacy algorithms will need to be supported for a legacy algorithms will need to be supported for a considerable
considerable period. Algorithms used for message signatures period. Algorithms used for message signatures therefore need to be
therefore need to be secure against expected cryptographic secure against expected cryptographic developments several years into
developments several years into the future. the future.
4.1.15. Display Name Abuse 4.1.15. Display Name Abuse
Message signatures only relate to the address-specification portion Message signatures only relate to the address-specification portion
of an email address, while some MUAs only display (or some recipients of an email address, while some MUAs only display (or some recipients
only pay attention to) the display name portion of the address. This only pay attention to) the display name portion of the address. This
inconsistency leads to an attack where the attacker uses a From inconsistency leads to an attack where the attacker uses a From
header field such as: header field such as:
From: "Dudley DoRight" <whiplash@example.org> From: "Dudley DoRight" <whiplash@example.org>
In this example, the attacker, whiplash@example.org, can sign the In this example, the attacker, whiplash@example.org, can sign the
message and still convince some recipients that the message is from message and still convince some recipients that the message is from
Dudley DoRight, who is presumably a trusted individual. Coupled with Dudley DoRight, who is presumably a trusted individual. Coupled with
the use of a throw-away domain or email address, it may be difficult 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. to hold the attacker accountable for using another's display name.
This is an attack which must be dealt with in the recipient's MUA. 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 One approach is to require that the signer's address specification
(and not just the display name) be visible to the recipient. (and not just the display name) be visible to the recipient.
4.1.16. Compromised System Within Originator's Network 4.1.16. Compromised System within Originator's Network
In many cases, MTAs may be configured to accept and sign messages In many cases, MTAs may be configured to accept and sign messages
that originate within the topological boundaries of the originator's that originate within the topological boundaries of the originator's
network (i.e., within a firewall). The increasing use of compromised network (i.e., within a firewall). The increasing use of compromised
systems to send email presents a problem for such policies, because systems to send email presents a problem for such policies, because
the attacker, using a compromised system as a proxy, can generate the attacker, using a compromised system as a proxy, can generate
signed mail at will. signed mail at will.
Several approaches exist for mitigating this attack. The use of Several approaches exist for mitigating this attack. The use of
authenticated submission, even within the network boundaries, can be authenticated submission, even within the network boundaries, can be
skipping to change at page 22, line 42 skipping to change at page 22, line 16
to send a message with a DKIM signature to each of many addresses in 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 a mailing list. The messages need not contain valid signatures, and
each instance of the message would typically use a different each instance of the message would typically use a different
selector. The attacker could then monitor key service requests and selector. The attacker could then monitor key service requests and
determine which selectors had been accessed, and correspondingly determine which selectors had been accessed, and correspondingly
which addressees used DKIM verification. This could be used to which addressees used DKIM verification. This could be used to
target future mailings at recipients who do not use DKIM target future mailings at recipients who do not use DKIM
verification, on the premise that these addressees are more likely to verification, on the premise that these addressees are more likely to
act on the message contents. act on the message contents.
4.1.18. Key Publication by Higher Level Domain 4.1.18. Key Publication by Higher-Level Domain
In order to support the ability of a domain to sign for subdomains In order to support the ability of a domain to sign for subdomains
under its administrative control, DKIM permits the domain of a under its administrative control, DKIM permits the domain of a
signature (d= tag) to be any higher-level domain than the signature's signature (d= tag) to be any higher-level domain than the signature's
address (i= or equivalent). However, since there is no mechanism for address (i= or equivalent). However, since there is no mechanism for
determining common administrative control of a subdomain, it is determining common administrative control of a subdomain, it is
possible for a parent to publish keys which are valid for any domain 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 below them in the DNS hierarchy. In other words, mail from the
domain example.anytown.ny.us could be signed using keys published by 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. anytown.ny.us, ny.us, or us, in addition to the domain itself.
Operation of a domain always requires a trust relationship with Operation of a domain always requires a trust relationship with
higher level domains. Higher level domains already have ultimate higher-level domains. Higher-level domains already have ultimate
power over their subdomains: they could change the name server power over their subdomains: they could change the name server
delegation for the domain or disenfranchise it entirely. So it is delegation for the domain or disenfranchise it entirely. So it is
unlikely that a higher level domain would intentionally compromise a unlikely that a higher-level domain would intentionally compromise a
subdomain in this manner. However, if higher level domains send mail subdomain in this manner. However, if higher-level domains send mail
on their own behalf, they may wish to publish keys at their own on their own behalf, they may wish to publish keys at their own
level. Higher level domains must employ special care in the level. Higher-level domains must employ special care in the
delegation of keys they publish to ensure that any of their delegation of keys they publish to ensure that any of their
subdomains are not compromised by misuse of such keys. subdomains are not compromised by misuse of such keys.
4.2. Attacks Against Message Signing Policy 4.2. Attacks against Message Signing Practices
Summary of postulated attacks against signing policy: The following is a summary of postulated attacks against signing
practices:
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood | | Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
| Look-alike domain names | High | High | | Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High | | Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium | | Denial-of-service attack against signing | Medium | Medium |
| policy | | | | practices | | |
| Use of multiple From addresses | Low | Medium | | Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High | | Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Policy | Medium | Medium | | Falsification of Sender Signing Practices | Medium | Medium |
| replies | | | | replies | | |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names 4.2.1. Look-Alike Domain Names
Attackers may attempt to circumvent signing policy of a domain by Attackers may attempt to circumvent signing practices of a domain by
using a domain name which is close to, but not the same as the domain using a domain name that is close to, but not the same as, the domain
with a signing policy. For instance, "example.com" might be replaced with signing practices. For instance, "example.com" might be
by "examp1e.com". If the message is not to be signed, DKIM does not replaced by "examp1e.com". If the message is not to be signed, DKIM
require that the domain used actually exist (although other does not require that the domain used actually exist (although other
mechanisms may make this a requirement). Services exist to monitor mechanisms may make this a requirement). Services exist to monitor
domain registrations to identify potential domain name abuse, but domain registrations to identify potential domain name abuse, but
naturally do not identify the use of unregistered domain names. naturally do not identify the use of unregistered domain names.
A related attack is possible when the MUA does not render the domain A related attack is possible when the MUA does not render the domain
name in an easily recognizable format. If, for example, a Chinese name in an easily recognizable format. If, for example, a Chinese
domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the
unfamiliarity of that representation may enable other domains to more unfamiliarity of that representation may enable other domains to more
easily be mis-recognized as the expected domain. easily be mis-recognized as the expected domain.
Users that are unfamiliar with internet naming conventions may also Users that are unfamiliar with internet naming conventions may also
mis-recognize certain names. For example, users may confuse mis-recognize certain names. For example, users may confuse
online.example.com with online-example.com, the latter of which may online.example.com with online-example.com, the latter of which may
have been registered by an attacker. have been registered by an attacker.
4.2.2. Internationalized Domain Name Abuse 4.2.2. Internationalized Domain Name Abuse
Internationalized domain names present a special case of the look- Internationalized domain names present a special case of the look-
alike domain name attack described above. Due to similarities in the alike domain name attack described above. Due to similarities in the
appearance of many Unicode characters, domains (particularly those appearance of many Unicode characters, domains (particularly those
drawing characters from different groups) may be created which are drawing characters from different groups) may be created that are
visually indistinguishable from other, possibly high-value domains. visually indistinguishable from other, possibly high-value domains.
This is discussed in detail in Unicode TR 36 [UTR36]. Surveillance This is discussed in detail in Unicode Technical Report 36 [UTR36].
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
policy of other domains.
4.2.3. Denial-of-Service Attack Against Signing Policy 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 Just as the publication of public keys by a domain can be impacted by
an attacker, so can the publication of Sender Signing Policy (SSP) by an attacker, so can the publication of Sender Signing Practices (SSP)
a domain. In the case of SSP, the transmission of large amounts of by a domain. In the case of SSP, the transmission of large amounts
unsigned mail purporting to come from the domain can result in a of unsigned mail purporting to come from the domain can result in a
heavy transaction load requesting the SSP record. More general DoS heavy transaction load requesting the SSP record. More general DoS
attacks against the servers providing the SSP records are possible as attacks against the servers providing the SSP records are possible as
well. This is of particular concern since the default signing policy well. This is of particular concern since the default signing
is "we don't sign everything", which means that SSP, in effect, fails practices are "we don't sign everything", which means that SSP
open. failures result in the verifier's failure to heed more stringent
signing practices.
As with defense against DoS attacks for key servers, the best defense As with defense against DoS attacks for key servers, the best defense
against this attack is to provide redundant servers, preferably on against this attack is to provide redundant servers, preferably on
geographically-separate parts of the Internet. Caching again helps a geographically-separate parts of the Internet. Caching again helps a
great deal, and signing policy should rarely change, so TTL values great deal, and signing practices should rarely change, so TTL values
can be relatively large. can be relatively large.
4.2.4. Use of Multiple From Addresses 4.2.4. Use of Multiple From Addresses
Although this usage is never seen by most recipients, RFC 2822 Although this usage is never seen by most recipients, RFC 2822
[RFC2822] permits the From address to contain multiple address [RFC2822] permits the From address to contain multiple address
specifications. The lookup of Sender Signing Policy is based on the specifications. The lookup of Sender Signing Practices is based on
From address, so if addresses from multiple domains are in the From the From address, so if addresses from multiple domains are in the
address, the question arises which signing policy to use. A rule From address, the question arises which signing practices to use. A
(say, "use the first address") could be specified, but then an rule (say, "use the first address") could be specified, but then an
attacker could put a throwaway address prior to that of a high-value 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 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 choose the most restrictive rule. This is an area in need of further
study. study.
4.2.5. Abuse of Third-Party Signatures 4.2.5. Abuse of Third-Party Signatures
In a number of situations, including mailing lists, event In a number of situations, including mailing lists, event
invitations, and "send this article to a friend" services, the DKIM invitations, and "send this article to a friend" services, the DKIM
signature on a message may not come from the originating address signature on a message may not come from the originating address
domain. For this reason, "third-party" signatures, those attached by domain. For this reason, "third-party" signatures, those attached by
the mailing list, invitation service, or news service, frequently the mailing list, invitation service, or news service, frequently
need to be regarded as having some validity. Since this effectively need to be regarded as having some validity. Since this effectively
makes it possible for any domain to sign any message, a sending makes it possible for any domain to sign any message, a sending
domain may publish sender signing practices stating that it does not domain may publish sender signing practices stating that it does not
use such services, and accordingly that verifiers should view such use such services, and accordingly that verifiers should view such
signatures with suspicion. signatures with suspicion.
However, the restrictions placed on a domain by publishing "no third- However, the restrictions placed on a domain by publishing "no
party" signing practices effectively disallows many existing uses of third-party" signing practices effectively disallows many existing
e-mail. For the majority of domains that are unable to adopt these uses of email. For the majority of domains that are unable to adopt
practices, an attacker may with some degree of success sign messages these practices, an attacker may with some degree of success sign
purporting to come from the domain. For this reason, accreditation messages purporting to come from the domain. For this reason,
and reputation services, as well as locally-maintained whitelists and accreditation and reputation services, as well as locally-maintained
blacklists, will need to play a significant role in evaluating whitelists and blacklists, will need to play a significant role in
messages that have been signed by third parties. evaluating messages that have been signed by third parties.
4.2.6. Falsification of Sender Signing Policy Replies 4.2.6. Falsification of Sender Signing Practices Replies
In an analogous manner to the falsification of key service replies In an analogous manner to the falsification of key service replies
described in Section 4.1.12, replies to sender signing policy queries described in Section 4.1.12, replies to sender signing practices
can also be falsified. One such attack would be to weaken the queries can also be falsified. One such attack would be to weaken
signing policy to make unsigned messages allegedly from a given the signing practices to make unsigned messages allegedly from a
domain appear less suspicious. Another attack on a victim domain given domain appear less suspicious. Another attack on a victim
that is not signing messages could attempt to make the domain's domain that is not signing messages could attempt to make the
messages look more suspicious, in order to interfere with the domain's messages look more suspicious, in order to interfere with
victim's ability to send mail. the victim's ability to send mail.
As with the falsification of key service replies, DNSSEC is the As with the falsification of key service replies, DNSSEC is the
preferred means of mitigating this attack. Even in the absence of preferred means of mitigating this attack. Even in the absence of
DNSSEC, vulnerabilities due to cache poisoning are localized. DNSSEC, vulnerabilities due to cache poisoning are localized.
4.3. Other Attacks 4.3. Other Attacks
This section describes attacks against other internet infrastructure This section describes attacks against other Internet infrastructure
which are enabled by deployment of DKIM. A summary of these that are enabled by deployment of DKIM. A summary of these
postulated attacks is as follows: postulated attacks is as follows:
+--------------------------------------+--------+------------+ +--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood | | Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+ +--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium | | Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+ +--------------------------------------+--------+------------+
4.3.1. Packet Amplification Attacks via DNS 4.3.1. Packet Amplification Attacks via DNS
Recently [US-CERT-DNS], an increase in denial-of-service attacks Recently, there has been an increase in denial-of-service attacks
involving the transmission of spoofed UDP DNS requests to openly- involving the transmission of spoofed UDP DNS requests to openly-
accessible domain name servers. To the extent that the response from accessible domain name servers [US-CERT-DNS]. To the extent that the
the name server is larger than the request, the name server functions response from the name server is larger than the request, the name
as an amplifier for such an attack. server functions as an amplifier for such an attack.
DKIM contributes indirectly to this attack by requiring the DKIM contributes indirectly to this attack by requiring the
publication of fairly large DNS records for distributing public keys. publication of fairly large DNS records for distributing public keys.
The names of these records are also well known, since the record The names of these records are also well known, since the record
names can be determined by examining properly-signed messages. This names can be determined by examining properly-signed messages. This
attack does not have an impact on DKIM itself. DKIM, however, is not attack does not have an impact on DKIM itself. DKIM, however, is not
the only application which uses large DNS records, and a DNS-based the only application that uses large DNS records, and a DNS-based
solution to this problem will likely be required. solution to this problem will likely be required.
5. Derived Requirements 5. Derived Requirements
This section lists requirements for DKIM not explicitly stated in the This section lists requirements for DKIM not explicitly stated in the
above discussion. These requirements include: above discussion. These requirements include:
The store for key and SSP records must be capable of utilizing The store for key and SSP records must be capable of utilizing
multiple geographically-dispersed servers. multiple geographically-dispersed servers.
skipping to change at page 26, line 42 skipping to change at page 26, line 34
The cache time-to-live for key records must be specifiable on a The cache time-to-live for key records must be specifiable on a
per-record basis. per-record basis.
The signature algorithm identifier in the message must be one of The signature algorithm identifier in the message must be one of
the ones listed in a key record for the identified domain. the ones listed in a key record for the identified domain.
The algorithm(s) used for message signatures need to be secure The algorithm(s) used for message signatures need to be secure
against expected cryptographic developments several years in the against expected cryptographic developments several years in the
future. future.
6. IANA Considerations 6. Security Considerations
{{{ RFC Editor: Please delete this section prior to publication. }}}
This document defines no items requiring IANA assignment.
7. Security Considerations
This document describes the security threat environment in which This document describes the security threat environment in which
DomainKeys Identified Mail (DKIM) is expected to provide some DomainKeys Identified Mail (DKIM) is expected to provide some
benefit, and presents a number of attacks relevant to its deployment. benefit, and it presents a number of attacks relevant to its
deployment.
8. Informative References 7. Informative References
[Bernstein04] [Bernstein04] Bernstein, D., "Cache Timing Attacks on AES",
Bernstein, D., "Cache Timing Attacks on AES", April 2004. April 2004.
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are [Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are
Practical", Proc. 12th USENIX Security Symposium, 2003. Practical", Proc. 12th USENIX Security Symposium,
2003.
[I-D.allman-dkim-ssp] [DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM)
Allman, E., "DKIM Sender Signing Policy", Signatures", Work in Progress, August 2006.
draft-allman-dkim-ssp-01 (work in progress), October 2005.
[I-D.ietf-dkim-base] [DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in
Allman, E., "DomainKeys Identified Mail Signatures Progress, August 2006.
(DKIM)", draft-ietf-dkim-base-00 (work in progress),
February 2006.
[Kocher96] [Kocher96] Kocher, P., "Timing Attacks on Implementations of
Kocher, P., "Timing Attacks on Implementations of Diffie- Diffie-Hellman, RSA, and other Cryptosystems",
Hellman, RSA, and other Cryptosystems", Advances in Advances in Cryptology, pages 104-113, 1996.
Cryptology, pages 104-113, 1996.
[Kocher99] [Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power
Kocher, P., Joffe, J., and B. Yun, "Differential Power
Analysis: Leaking Secrets", Crypto '99, pages 388-397, Analysis: Leaking Secrets", Crypto '99, pages 388-397,
1999. 1999.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
STD 53, RFC 1939, May 1996. 3", STD 53, RFC 1939, May 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
April 2001. RFC 2821, April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
4rev1", RFC 3501, March 2003. VERSION 4rev1", RFC 3501, March 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
Rose, "DNS Security Introduction and Requirements", S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[US-CERT-DNS] [US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat
US-CERT, "The Continuing Denial of Service Threat Posed by Posed by DNS Recursion".
DNS Recursion".
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36: [UTR36] Davis, M. and M. Suignard, "Unicode Technical Report
Unicode Security Considerations", UTR 36, July 2005. #36: Unicode Security Considerations", UTR 36,
July 2005.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony
Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon
Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla, Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla,
Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim
mailing list for valuable suggestions and constructive criticism of mailing list for valuable suggestions and constructive criticism of
earlier versions of this draft. earlier versions of this document.
Appendix B. Edit History
{{{ RFC Editor: Please delete this section prior to publication. }}}
Changes since draft-fenton-dkim-threats-00 draft:
o Changed beginning of introduction to make it consistent with -base
draft.
o Clarified reasons for focus on externally-located bad actors.
o Elaborated on reasons for effectiveness of address book attacks.
o Described attack time windows with respect to replay attacks.
o Added discussion of attacks using look-alike domains.
o Added section on key management attacks.
Changes since draft-fenton-dkim-threats-01 draft:
o Reorganized description of bad actors.
o Greatly expanded description of attacks against DKIM and SSP.
o Added "derived requirements" section.
Changes since draft-fenton-dkim-threats-02 draft:
o Added description of reflection attack, verification probe attack,
and abuse of third-party signatures.
o Expanded description of key delegation attacks and look-alike
domain names.
o Numerous changes suggested by ietf-dkim mailing list participants.
Changes since draft-ietf-dkim-threats-00 draft:
o Added description of key publication by higher level domain
attack.
o Added description of falsification of SSP replies.
o Added section on other threats and description of packet
amplification attacks via DNS.
Changes since draft-ietf-dkim-threats-01 draft:
o Reworded document structure introduction.
o Less normative wording for mitigation of theft of delegated
private key and body length limit abuse.
o Added description of reply variant of chosen message replay.
o Terminology changes to avoid ambiguous use of the word "sender"
suggested by D. Crocker..
o Additional description of hash collision attacks provided by P.
Hoffman.
o Replaced section on side channel attacks with text provided by E.
Rescorla.
o Numerous minor edits and clarifications.
Changes since draft-ietf-dkim-threats-02 draft:
o Numerous editorial changes proposed by R. Housley.
o Improved context for description of compromise of key server.
Author's Address Author's Address
Jim Fenton Jim Fenton
Cisco Systems, Inc. Cisco Systems, Inc.
MS SJ-24/2 MS SJ-9/2
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Phone: +1 408 526 5914 Phone: +1 408 526 5914
Email: fenton@cisco.com EMail: fenton@cisco.com
URI:
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 31, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 107 change blocks. 
378 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/