draft-ietf-dkim-threats-02.txt   draft-ietf-dkim-threats-03.txt 
DKIM Working Group J. Fenton DKIM Working Group J. Fenton
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: October 6, 2006 April 4, 2006 Expires: November 27, 2006 May 26, 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
draft-ietf-dkim-threats-02 draft-ietf-dkim-threats-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 6, 2006. This Internet-Draft will expire on November 27, 2006.
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology and Model . . . . . . . . . . . . . . . . . . 4 1.1. Terminology and Model . . . . . . . . . . . . . . . . . . 4
1.2. Document Structure . . . . . . . . . . . . . . . . . . . . 6 1.2. Document Structure . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Externally-located Bad Actors . . . . . . . . . . . . 8 2.3.1. Externally-located Bad Actors . . . . . . . . . . . . 9
2.3.2. Within Claimed Originator's Administrative Unit . . . 9 2.3.2. Within Claimed Originator's Administrative Unit . . . 9
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 . . . . . . . . . . . . . . . . . . . 10
3.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 10 3.1. Use of Arbitrary Identities . . . . . . . . . . . . . . . 10
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 . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 12
3.2.4. Reflection Attacks . . . . . . . . . . . . . . . . . . 12 3.2.4. Reflection Attacks . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . 13
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 . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 15
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 . . . . . . 17
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 . . . . . . . . . . . . . . . . 18
4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 18 4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 18
4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 18 4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 19
4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 19 4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 19
4.1.12. Falsification of Key Service Replies . . . . . . . . . 19 4.1.12. Falsification of Key Service Replies . . . . . . . . . 20
4.1.13. Publication of Malformed Key Records and/or 4.1.13. Publication of Malformed Key Records and/or
Signatures . . . . . . . . . . . . . . . . . . . . . . 20 Signatures . . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . 21 4.1.16. Compromised System Within Originator's Network . . . . 22
4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 22 4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 22
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 Policy . . . . . . . . . . 23
4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 23 4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 23
4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 23 4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 24
4.2.3. Denial-of-Service Attack Against Signing Policy . . . 24 4.2.3. Denial-of-Service Attack Against Signing Policy . . . 24
4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 24 4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 24
4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 24 4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 25
4.2.6. Falsification of Sender Signing Policy Replies . . . . 25 4.2.6. Falsification of Sender Signing Policy Replies . . . . 25
4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 25 4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 25 4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 26
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 26 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Informative References . . . . . . . . . . . . . . . . . . . . 26 8. Informative References . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Edit History . . . . . . . . . . . . . . . . . . . . 28 Appendix B. Edit History . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 31
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) [I-D.ietf-dkim-base] defines a The DomainKeys Identified Mail (DKIM) protocol is being specified by
mechanism by which email messages can be cryptographically signed, the IETF DKIM Working Group. The DKIM protocol defines a mechanism
permitting a signing domain to claim responsibility for the use of a by which email messages can be cryptographically signed, permitting a
given email address. Message recipients can verify the signature by signing domain to claim responsibility for the use of a given email
querying the signer's domain directly to retrieve the appropriate address. Message recipients can verify the signature by querying the
public key, and thereby confirm that the message was attested to by a signer's domain directly to retrieve the appropriate public key, and
party in possession of the private key for the signing domain. thereby confirm that the message was attested to by a party in
possession of the private key for the signing domain.
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 this effort. By applying a mechanisms is outside the scope of the IETF DKIM Working Group
signature, a good player enables a verifier to associate a positive effort. By applying a signature, a good player enables a verifier to
reputation with the message, in hopes that it will receive associate a positive reputation with the message, in hopes that it
preferential treatment by the recipient. will receive preferential treatment by the recipient.
This effort is not intended to address threats associated with This effort is not intended to address threats associated with
message confidentiality nor does it intend to provide a long-term message confidentiality nor does it intend to provide a long-term
archival signature. archival signature.
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
skipping to change at page 6, line 27 skipping to change at page 6, line 26
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 or High: Affects the verification of messages from an entire domain
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 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 basis High: All email users should expect this attack on a frequent
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
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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
messages on behalf of third parties. messages on behalf of third parties.
The most sophisticated and financially-motivated senders of messages The most sophisticated and financially-motivated senders of messages
are those who stand to receive substantial financial benefit, such as are those who stand to receive substantial financial benefit, such as
from an email-based fraud scheme. These attackers can be expected to from an email-based fraud scheme. These attackers can be expected to
employ all of the above mechanisms and additionally may attack the employ all of the above mechanisms and additionally may attack the
Internet infrastructure itself, e.g., DNS cache-poisoning attacks; IP Internet infrastructure itself, including DNS cache-poisoning attacks
routing attacks via compromised network routing elements. and IP routing attacks.
2.2. Capabilities 2.2. Capabilities
In general, the bad actors described above should be expected to have In general, the bad actors described above should be expected to have
access to the following: access to the following:
1. An extensive corpus of messages from domains they might wish to 1. An extensive corpus of messages from domains they might wish to
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
skipping to change at page 8, line 9 skipping to change at page 8, line 9
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 which might be used to attempt a denial of
service attack service attack
5. Resend messages which may have been previously signed by the 5. Resend messages which 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
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, or to cause falsification of DNS-based key or policy routing, or to cause falsification of DNS-based key or policy
advertisements. advertisements.
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 "wiretap" some existing traffic, perhaps from a 4. Ability to eavesdrop on existing traffic, perhaps from a wireless
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.
2.3. Location 2.3. Location
Bad actors or their proxies can be located anywhere in the Internet. Bad actors or their proxies can be located anywhere in the Internet.
Certain attacks are possible primarily within the administrative unit Certain attacks are possible primarily within the administrative unit
of the claimed originator and/or recipient domain have capabilities of the claimed originator and/or recipient domain have capabilities
beyond those elsewhere, as described in the below sections. Bad beyond those elsewhere, as described in the below sections. Bad
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
proxies, externally-located bad actors may gain some of the
capabilities of being located within the claimed originator's or
recipient's administrative unit. This emphasizes the importance of
appropriate security measures, such as authenticated submission of
messages, even within administrative units.
2.3.1. Externally-located Bad Actors 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
skipping to change at page 11, line 15 skipping to change at page 11, line 24
controlled by a bad actor, the bad actor could sign messages from controlled by a bad actor, the bad actor could sign messages from
bigbank.example2.com which might also mislead some recipients. To bigbank.example2.com which might also mislead some recipients. To
the extent that these domains are controlled by bad actors, DKIM is the extent that these domains are controlled by bad actors, DKIM is
not effective against these attacks, although it could support the not effective against these attacks, although it could support the
ability of reputation and/or accreditation systems to aid the user in ability of reputation and/or accreditation systems to aid the user in
identifying them. 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)[I-D.allman-dkim-ssp]. Practices (SSP), which will be specified by the IETF DKIM Working
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 which 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
skipping to change at page 12, line 42 skipping to change at page 13, line 4
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 Policy, Sender Signing Practices or SSP, as here as Sender Signing Practices or SSP) can be expected to be the
described in [I-D.ietf-dkim-base] ) can be expected to be the target target of attacks.
of attacks.
4.1. Attacks Against Message Signatures 4.1. Attacks Against Message Signatures
Summary of postulated attacks against DKIM signatures: 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 |
skipping to change at page 14, line 28 skipping to change at page 14, line 31
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
process itself. This threat can be mitigated through the use of process itself. This threat can be mitigated through the use of
standard precautions against the theft of private keys and the customary precautions against the theft of private keys and the
falsification of public keys in transit. For example, the exposure falsification of public keys in transit. For example, the exposure
to theft can be minimized if the delegate generates the keypair to be to theft can be minimized if the delegate generates the keypair to be
used, and sends the public key to the domain owner. The exposure to used, and sends the public key to the domain owner. The exposure to
falsification (substitution of a different public key) can be reduced falsification (substitution of a different public key) can be reduced
if this transmission is signed by the delegate and verified by the if this transmission is signed by the delegate and verified by the
domain owner. domain owner.
4.1.3. Private Key Recovery via Side Channel Attack 4.1.3. Private Key Recovery via Side Channel Attack
All popular digital signature algorithms are subject to a variety of All popular digital signature algorithms are subject to a variety of
skipping to change at page 15, line 40 skipping to change at page 15, line 43
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 him/herself or
an accomplice. They then "replay" the signed message by sending it, an accomplice. They then "replay" the signed message by sending it,
using different envelope addresses, to a (typically large) number of using different envelope addresses, to a (typically large) number of
other recipients. 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 this problem is for the attacker in this case). One approach to solving this problem is for
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
be seen whether this will be the model with signed mail as well, or be seen whether this will be the model with signed mail as well, or
whether a higher level of trust will be required to obtain an email whether a higher level of trust will be required to obtain an email
signature. signature.
A variation on this attack involves the attacker sending a message A variation on this attack involves the attacker sending a message
with the intent of obtaining a signed reply containing their original with the intent of obtaining a signed reply containing their original
message. The reply might come from an innocent user or might be an message. The reply might come from an innocent user or might be an
skipping to change at page 19, line 32 skipping to change at page 19, line 36
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
provides the attacker with the additional capability to remove provides the attacker with the additional capability to remove
legitimate keys from publication, thereby denying the domain the legitimate keys from publication, thereby denying the domain the
ability for the signatures on its mail to verify correctly. ability for the signatures on its mail to verify correctly.
The host which is the primary key server, such as a DNS master server In order to limit the ability to sign a message to entities
for the domain, might be compromised. Another approach might be to authorized by the owner of a signing domain, a relationship must be
change the delegation of key servers at the next higher domain level. established between the signing address and the location from which a
public key is obtained to verify the message. DKIM does this by
publishing either the public key or a reference to it within the DNS
hierarchy of the signing domain. The verifier derives the location
from which to retrieve the public key from the signing address or
domain. The security of the verification process is therefore
dependent on the security of the DNS hierarchy for the signing
domain.
An attacker might successfully compromise the host which is the
primary key server for the signing domain, such as the domain's DNS
master server. Another approach might be to compromise a higher-
level DNS server and change the delegation of name servers for the
signing domain to others under the control of the attacker.
This attack can be mitigated somewhat by independent monitoring to 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.
4.1.12. Falsification of Key Service Replies 4.1.12. Falsification of Key Service Replies
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
skipping to change at page 20, line 21 skipping to change at page 20, line 38
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 the public-key encryption/ specifically the hash algorithm and digital signature generation and
decryption 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
which has considerably lowered the time required to create two which has considerably lowered the time required to create two
messages with the same hash value. This trend can be expected to messages 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
incorporates that signature in the bad message. This scenario is not incorporates that signature in the bad message. This scenario is not
common, but could happen, for example, at a site that does content common, but could happen, for example, at a site that does content
analysis on messages before signing them. analysis on messages before signing them.
Current known attacks against SHA-1 make this attack extremely
difficult to mount, but as attacks improve and computing power
becomes more readily available, such an attack could become
achievable.
The message signature system must be designed to support multiple 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, rather than 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 Due to the fact that the signer and verifier of email do not, in
general, communicate directly, negotiation of the algorithms used for general, communicate directly, negotiation of the algorithms used for
signing cannot occur. In other words, a signer has no way of knowing signing cannot occur. In other words, a signer has no way of knowing
which algorithm(s) a verifier supports, nor (due to mail forwarding) which algorithm(s) a verifier supports, nor (due to mail forwarding)
where the verifier is. For this reason, it is expected that once where the verifier is. For this reason, it is expected that once
message signing is widely deployed, algorithm change will occur message signing is widely deployed, algorithm change will occur
slowly, and legacy algorithms will need to be supported for a slowly, and legacy algorithms will need to be supported for a
skipping to change at page 21, line 26 skipping to change at page 21, line 47
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 bring the attacker to account for the use of another's display to hold the attacker accountable for using another's display name.
name.
This is an attack which must be dealt with in the recipient's MUA. This is an attack which 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
which 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
used to limit the addresses for which the attacker may obtain a used to limit the addresses for which the attacker may obtain a
signature. It may also help locate the compromised system that is signature. It may also help locate the compromised system that is
the source of the messages more quickly. Content analysis of the source of the messages more quickly. Content analysis of
skipping to change at page 23, line 13 skipping to change at page 23, line 24
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 Policy
Summary of postulated attacks against signing policy: Summary of postulated attacks against signing policy:
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
| 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 | Medium | | Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium | | Denial-of-service attack against signing | Medium | Medium |
| policy | | | | policy | | |
| 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 Policy | Medium | Medium |
| replies | | | | replies | | |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names 4.2.1. Look-Alike Domain Names
skipping to change at page 25, line 17 skipping to change at page 25, line 30
e-mail. For the majority of domains that are unable to adopt these e-mail. For the majority of domains that are unable to adopt these
practices, an attacker may with some degree of success sign messages practices, an attacker may with some degree of success sign messages
purporting to come from the domain. For this reason, accreditation purporting to come from the domain. For this reason, accreditation
and reputation services, as well as locally-maintained whitelists and and reputation services, as well as locally-maintained whitelists and
blacklists, will need to play a significant role in evaluating blacklists, will need to play a significant role in evaluating
messages that have been signed by third parties. messages that have been signed by third parties.
4.2.6. Falsification of Sender Signing Policy Replies 4.2.6. Falsification of Sender Signing Policy Replies
In an analogous manner to the falsification of key service replies In an analogous manner to the falsification of key service replies
described above, replies to sender signing policy queries can also be described in Section 4.1.12, replies to sender signing policy queries
falsified. One such attack would be to weaken the signing policy to can also be falsified. One such attack would be to weaken the
make unsigned messages allegedly from a given domain appear less signing policy to make unsigned messages allegedly from a given
suspicious. Another attack on a victim domain that is not signing domain appear less suspicious. Another attack on a victim domain
messages could attempt to make the domain's messages look more that is not signing messages could attempt to make the domain's
suspicious, in order to interfere with the victim's ability to send messages look more suspicious, in order to interfere with the
mail. 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 which are enabled by deployment of DKIM. A summary of these
postulated attacks is as follows: postulated attacks is as follows:
skipping to change at page 26, line 22 skipping to change at page 26, line 35
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.
Key and SSP records must be cacheable, either by the verifier Key and SSP records must be cacheable, either by the verifier
requesting them or by other infrastructure. requesting them or by other infrastructure.
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(s) used by the signing domain must be The signature algorithm identifier in the message must be one of
specified independently of the message being verified, such as in the ones listed in a key record for the identified domain.
the key record.
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. IANA Considerations
{{{ RFC Editor: Please delete this section prior to publication. }}}
This document defines no items requiring IANA assignment. This document defines no items requiring IANA assignment.
7. Security Considerations 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 presents a number of attacks relevant to its deployment.
8. Informative References 8. Informative References
[Bernstein04] [Bernstein04]
Bernstein, D., "Cache Timing Attacks on AES", April 2004. Bernstein, D., "Cache Timing Attacks on AES", April 2004.
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are [Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are
skipping to change at page 27, line 50 skipping to change at page 28, line 15
DNS Recursion". DNS Recursion".
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36: [UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36:
Unicode Security Considerations", UTR 36, July 2005. 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, and numerous others on the ietf-dkim mailing list for Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim
valuable suggestions and constructive criticism of earlier versions mailing list for valuable suggestions and constructive criticism of
of this draft. earlier versions of this draft.
Appendix B. Edit History Appendix B. Edit History
{{{ RFC Editor: Please delete this section prior to publication. }}}
Changes since draft-fenton-dkim-threats-00 draft: Changes since draft-fenton-dkim-threats-00 draft:
o Changed beginning of introduction to make it consistent with -base o Changed beginning of introduction to make it consistent with -base
draft. draft.
o Clarified reasons for focus on externally-located bad actors. o Clarified reasons for focus on externally-located bad actors.
o Elaborated on reasons for effectiveness of address book attacks. o Elaborated on reasons for effectiveness of address book attacks.
o Described attack time windows with respect to replay attacks. o Described attack time windows with respect to replay attacks.
skipping to change at page 30, line 5 skipping to change at page 29, line 40
suggested by D. Crocker.. suggested by D. Crocker..
o Additional description of hash collision attacks provided by P. o Additional description of hash collision attacks provided by P.
Hoffman. Hoffman.
o Replaced section on side channel attacks with text provided by E. o Replaced section on side channel attacks with text provided by E.
Rescorla. Rescorla.
o Numerous minor edits and clarifications. 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-24/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
 End of changes. 37 change blocks. 
62 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/