draft-ietf-dkim-threats-01.txt   draft-ietf-dkim-threats-02.txt 
DKIM Working Group J. Fenton DKIM Working Group J. Fenton
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: September 6, 2006 March 5, 2006 Expires: October 6, 2006 April 4, 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
draft-ietf-dkim-threats-01 draft-ietf-dkim-threats-02
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 September 6, 2006. This Internet-Draft will expire on October 6, 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 28 skipping to change at page 2, line 28
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 . . . . . . 16 4.1.6. Denial-of-Service Attack Against Verifier . . . . . . 17
4.1.7. Denial-of-Service Attack Against Key Service . . . . . 16 4.1.7. Denial-of-Service Attack Against Key Service . . . . . 17
4.1.8. Canonicalization Abuse . . . . . . . . . . . . . . . . 17 4.1.8. Canonicalization Abuse . . . . . . . . . . . . . . . . 18
4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 17 4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 18
4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 18 4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 18
4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 18 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 . . . . . . . . . 19
4.1.13. Publication of Malformed Key Records and/or 4.1.13. Publication of Malformed Key Records and/or
Signatures . . . . . . . . . . . . . . . . . . . . . . 19 Signatures . . . . . . . . . . . . . . . . . . . . . . 20
4.1.14. Cryptographic Weaknesses in Signature Generation . . . 19 4.1.14. Cryptographic Weaknesses in Signature Generation . . . 20
4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 20 4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 21
4.1.16. Compromised System Within Originator's Network . . . . 20 4.1.16. Compromised System Within Originator's Network . . . . 21
4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 21 4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 22
4.1.18. Key Publication by Higher Level Domain . . . . . . . . 21 4.1.18. Key Publication by Higher Level Domain . . . . . . . . 22
4.2. Attacks Against Message Signing Policy . . . . . . . . . . 22 4.2. Attacks Against Message Signing Policy . . . . . . . . . . 23
4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 22 4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 23
4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 22 4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 23
4.2.3. Denial-of-Service Attack Against Signing Policy . . . 23 4.2.3. Denial-of-Service Attack Against Signing Policy . . . 24
4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 23 4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 24
4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 23 4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 24
4.2.6. Falsification of Sender Signing Policy Replies . . . . 24 4.2.6. Falsification of Sender Signing Policy Replies . . . . 25
4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 24 4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 25
4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 24 4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 25
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 25 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Informative References . . . . . . . . . . . . . . . . . . . . 25 8. Informative References . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26 Appendix B. Edit History . . . . . . . . . . . . . . . . . . . . 28
Appendix C. Edit History . . . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) [I-D.ietf-dkim-base] defines a DomainKeys Identified Mail (DKIM) [I-D.ietf-dkim-base] defines a
mechanism by which email messages can be cryptographically signed, mechanism by which email messages can be cryptographically signed,
permitting a signing domain to claim responsibility for the use of a permitting a signing domain to claim responsibility for the use of a
given email address. Message recipients can verify the signature by given email address. Message recipients can verify the signature by
querying the signer's domain directly to retrieve the appropriate querying the signer's domain directly to retrieve the appropriate
public key, and thereby confirm that the message was attested to by a public key, and thereby confirm that the message was attested to by a
party in possession of the private key for the signing domain. party in possession of the private key for the signing domain.
skipping to change at page 4, line 30 skipping to change at page 4, line 30
signature, a good player enables a verifier to associate a positive signature, a good player enables a verifier to associate a positive
reputation with the message, in hopes that it will receive reputation with the message, in hopes that it will receive
preferential treatment by the recipient. 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
Definitions of some terms used in this document may be found in An administrative unit (AU) is the portion of the path of an email
Appendix A. message that is under common administration. The originator and
recipient typically develop trust relationships with the
administrative units that send and receive their email, respectively,
to perform the signing and verification of their messages.
The origin address is the address on an email message, typically the
RFC 2822 From: address, which is associated with the alleged author
of the message and is displayed by the recipient's 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) |
| | | |
+---------------------------------+ +---------------------------------+
| - Message (Domain, Key) | - Message (Domain, Key)
| |
[Internet] [Internet]
| |
V V
+---------------------------------+ +---------------------------------+
+-----------+ | SIGNATURE VERIFICATION | +-----------+ | SIGNATURE VERIFICATION |
| | | (Relaying or Delivering AU) | | | | (Relaying or Delivering AU) |
| KEY | | | | KEY | | |
| QUERY +...>| Verify (Message, Domain, Key) | | QUERY +--->| Verify (Message, Domain, Key) |
| | | | | | | |
+-----------+ +----------------+----------------+ +-----------+ +----------------+----------------+
| - Verified Domain | - Verified Domain
+-----------+ V - [Report] +-----------+ V - [Report]
| SENDER | +----------------+----------------+ | SENDER | +----------------+----------------+
| SIGNING | | | | SIGNING | | |
| PRACTICES +...>| SIGNER EVALUATION | | PRACTICES +--->| SIGNER EVALUATION |
| QUERY | | | | QUERY | | |
| | +---------------------------------+ | | +---------------------------------+
+-----------+ +-----------+
DKIM operates entirely on the content of the message, as defined in DKIM operates entirely on the content (body and selected header
RFC 2822 [RFC2822]. The transmission of messages via SMTP, defined fields) of the message, as defined in RFC 2822 [RFC2822]. The
in RFC 2821 [RFC2821], and such elements as the envelope-from and transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
envelope-to addresses and the HELO domain are not relevant to DKIM such elements as the envelope-from and envelope-to addresses and the
verification. This is an intentional decision made to allow HELO domain are not relevant to DKIM verification. This is an
verification of messages via protocols other than SMTP, such as POP intentional decision made to allow verification of messages via
[RFC1939] and IMAP [RFC3501] which an MUA acting as a verifier might protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
use. which an MUA acting as a verifier might use.
The Sender Signing Practices Query referred to in the diagram above The Sender Signing Practices Query referred to in the diagram above
is a means by which the verifier can query the alleged author's is a means by which the verifier can query the alleged author's
domain to determine their practices for signing messages, which in domain to determine their practices for signing messages, which in
turn may influence their evaluation of the message. If, for example, turn may influence their evaluation of the message. If, for example,
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 begins by describing problems that The remainder of this document describes the problems that DKIM might
DKIM might be expected to address, and the extent that it is be expected to address, and the extent to which it may be successful
successful in doing so. These are described in terms of who the bad in so doing. These are described in terms of the potential bad
actors are, their capabilities and location in the network, and what actors, their capabilities and location in the network, and in terms
the bad acts are that they might wish to commit. of the bad 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
skipping to change at page 8, line 32 skipping to change at page 8, line 32
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 "wiretap" some existing traffic, perhaps from a
wireless network. wireless 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 sender 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").
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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 mail submission agents
that are configured to authenticate the sender. 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
skipping to change at page 10, line 20 skipping to change at page 10, line 20
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 which 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 which aim to
obscure the identity of the actual sender. 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.
skipping to change at page 11, line 12 skipping to change at page 11, line 12
Similar types of attacks using internationalized domain names have Similar types of attacks using internationalized domain names have
been hypothesized where it could be very difficult to see character been hypothesized where it could be very difficult to see character
differences in popular typefaces. Similarly, if example2.com was differences in popular typefaces. Similarly, if example2.com was
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
there is an expectation that such messages will, in fact, be signed.
The primary means for establishing this is the use of Sender Signing
Practices (SSP)[I-D.allman-dkim-ssp].
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 sender'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 send 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.
3.2.2. Identity-Related Fraud 3.2.2. Identity-Related Fraud
Bad acts related to email-based fraud often, but not always, involve Bad acts related to email-based fraud often, but not always, involve
the transmission of messages using specific origin addresses of other the transmission of messages using specific origin addresses of other
entities as part of the fraud scheme. The use of a specific address entities as part of the fraud scheme. The use of a specific address
of origin sometimes contributes to the success of the fraud by of origin sometimes contributes to the success of the fraud by
helping convince the recipient that the message was actually sent by helping convince the recipient that the message was actually sent by
the alleged sender. the alleged author.
To the extent that the success of the fraud depends on or is enhanced To the extent that the success of the fraud depends on or is enhanced
by the use of a specific origin address, the bad actor may have by the use of a specific origin address, the bad actor may have
significant financial motivation and resources to circumvent any significant financial motivation and resources to circumvent any
measures taken to protect specific addresses from unauthorized use. measures taken to protect specific addresses from unauthorized use.
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
skipping to change at page 12, line 24 skipping to change at page 12, line 26
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
(RFC2821 envelope-from address) on the message. In this case, the (RFC2821 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 return address on DKIM does not, in general, attempt to validate the RFC2821.mailfrom
messages, either directly (noting that the envelope-from address is return address on messages, either directly (noting that the mailfrom
an element of the SMTP protocol, and not the message content on which address is an element of the SMTP protocol, and not the message
DKIM operates), or via the optional Return-Path header field. content on which DKIM operates), or via the optional Return-Path
Furthermore, as is noted in section 4.4 of RFC 2821 [RFC2821], it is header field. Furthermore, as is noted in section 4.4 of RFC 2821
common and useful practice for a message's return path not to [RFC2821], it is common and useful practice for a message's return
correspond to the message sender. For these reasons, DKIM is not path not to correspond to the origin address. For these reasons,
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 Policy, Sender Signing Practices or SSP, as
described in [I-D.ietf-dkim-base] ) can be expected to be the target described in [I-D.ietf-dkim-base] ) can be expected to be the target
skipping to change at page 13, line 14 skipping to change at page 13, line 14
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 |
| Private key recovery via side-channel | High | Low | | Private key recovery via side channel | High | Low |
| attack | | | | 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 | High | Medium |
| service | | | | 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 |
skipping to change at page 14, line 7 skipping to change at page 14, line 7
Keys which are valid for all addresses in a domain typically reside Keys which are valid for all addresses in a domain typically reside
in MTAs which should be located in well-protected sites, such as data in MTAs which 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 which 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 access to 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
process itself. Standard precautions need to be used when handling process itself. This threat can be mitigated through the use of
delegated keys to minimize their exposure to theft. In particular, standard precautions against the theft of private keys and the
the delegate should generate the keypair to be used, and send the falsification of public keys in transit. For example, the exposure
public key to the domain owner. This transmission should be signed to theft can be minimized if the delegate generates the keypair to be
in order to minimize the possibility of an attacker substituting a used, and sends the public key to the domain owner. The exposure to
different public key. falsification (substitution of a different public key) can be reduced
if this transmission is signed by the delegate and verified by the
domain owner.
4.1.3. Private Key Recovery via Side-Channel Attack 4.1.3. Private Key Recovery via Side Channel Attack
Side-channel attacks are techniques whereby the private key is All popular digital signature algorithms are subject to a variety of
recovered by observing characteristics of the signing process, such side channel attacks. The most well-known of these are timing
as the time required, power consumed, and other externally-observable channels [Kocher96], power analysis [Kocher99], and cache timing
factors. It requires both the ability to submit messages for signing analysis [Bernstein04]. Most of these attacks require either
as well as the ability to accurately measure observable factor being physical access to the machine or the ability to run processes
used. directly on the target machine. Defending against these attacks is
out of scope for DKIM.
An MTA probably has are enough variables (system load, clock However, remote timing analysis (at least on local area networks) is
resolution, queuing delays, co-location with other equipment, etc.) known to be feasible [Boneh03], particularly in server-type platforms
to prevent useful observable factors from being measured accurately where the attacker can inject traffic which will immediately subject
enough to be useful for a side-channel attack. Furthermore, while to the cryptographic operation in question. With enough samples,
some domains, e.g., consumer ISPs, would allow an attacker to submit these techniques can be used to extract private keys even in the face
messages for signature, with many other domains this is difficult. of modest amounts of noise in the timing measurements.
Other mechanisms, such as mailing lists hosted by the domain, might
be paths by which an attacker might submit messages for signature, The three commonly proposed countermeasures against timing analysis
and should also be considered as possible vectors for side-channel are:
attacks.
1. Make the operation run in constant time. This turns out in
practice to be rather difficult.
2. Make the time independent of the input data. This can be
difficult but see [Boneh03] for more details.
3. Use blinding. This is generally considered the best current
practice countermeasure, and while not proved generally secure is
a countermeasure against known timing attacks. It adds about
2-10% to the cost of the operation and is implemented in many
common cryptographic libraries. Unfortunately, Digital Signature
Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have
standard methods though some defenses may exist.
Note that adding random delays to the operation is only a partial
countermeasure. Because the noise is generally uniformly
distributed, a large enough number of samples can be used to average
it out and extract an accurate timing signal.
4.1.4. Chosen Message Replay 4.1.4. Chosen Message Replay
Chosen Message Replay (CMR) 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 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 this problem is for the
domain to only sign email for clients that have passed a vetting 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
with the intent of obtaining a signed reply containing their original
message. The reply might come from an innocent user or might be an
automatic response such as a "user unknown" bounce message. In some
cases, this signed reply message might accomplish the attacker's
objectives if replayed. This variation on chosen message replay can
be mitigated by limiting the extent to which the original content is
quoted in automatic replies, and by the use of complementary
mechanisms such as egress content filtering.
Revocation of the signature or the associated key is a potential Revocation of the signature or the associated key is a potential
countermeasure. However, the rapid pace at which the message might countermeasure. However, the rapid pace at which the message might
be replayed (especially with an army of "zombie" computers), compared be replayed (especially with an army of "zombie" computers), compared
with the time required to detect the attack and implement the with the time required to detect the attack and implement the
revocation, is likely to be problematic. A related problem is the revocation, is likely to be problematic. A related problem is the
likelihood that domains will use a small number of signing keys for a 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.
skipping to change at page 16, line 7 skipping to change at page 16, line 37
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
Signed Message Replay (SMR) refers to the retransmission of already- Signed message replay refers to the retransmission of already-signed
signed messages to additional recipients beyond those intended by the messages to additional recipients beyond those intended by the author
sender. The attacker arranges to receive a message from the victim, or the original poster of the message. The attacker arranges to
and then retransmits it intact but with different envelope addresses. receive a message from the victim, and then retransmits it intact but
This might be done, for example, to make it look like a legitimate with different envelope addresses. This might be done, for example,
sender of messages is sending a large amount of spam. When to make it look like a legitimate sender of messages is sending a
reputation services are deployed, this could damage the originator's large amount of spam. When reputation services are deployed, this
reputation. could damage the author's reputation or that of the author's domain.
A larger number of domains are potential victims of SMR than of CMR, A larger number of domains are potential victims of signed message
because the former does not require the ability for the attacker to replay than chosen message replay because the former does not require
send messages from the victim domain. However, the capabilities of the ability for the attacker to send messages from the victim domain.
the attacker are lower. Unless coupled with another attack such as However, the capabilities of the attacker are lower. Unless coupled
body length limit abuse, it isn't possible for the attacker to use with another attack such as body length limit abuse, it isn't
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 which 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 SMR. The use of body length the signature, engage in a form of signed message replay. The use of
limits and other mechanisms to enhance the survivability of messages body length limits and other mechanisms to enhance the survivability
effectively enhances the ability to do so. The only things that of messages effectively enhances the ability to do so. The only
distinguish this case from undesirable forms of SMR is the intent of things that distinguish this case from undesirable forms of signed
the replayer, which cannot be determined by the network. message replay is the intent of the replayer, which cannot be
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 compute resources to sign and verify a signature,
it takes negligible compute resources to generate an invalid it takes negligible compute resources to generate an invalid
signature. An attacker could therefore construct a "make work" signature. An attacker could therefore construct a "make work"
attack against a verifier, by sending a large number of incorrectly- attack against a verifier, by sending a large number of incorrectly-
signed messages to a given verifier, perhaps with multiple signatures signed messages to a given verifier, perhaps with multiple signatures
each. The motivation might be to make it too expensive to verify each. The motivation might be to make it too expensive to verify
messages. messages.
skipping to change at page 18, line 14 skipping to change at page 18, line 47
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
opportunity for the attacker to add anything. opportunity for the attacker to add anything.
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. Recipients need to use means to, at a minimum, actual content. Receiving MUAs can mitigate this threat by, at a
identify 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 which 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 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 time-to-live value may be specified for each record, as it can
with DNS). In some cases, such as the recovery following a stolen with DNS). In some cases, such as the recovery following a stolen
private key belonging to one of the domain's MTAs, the possibility of private key belonging to one of the domain's MTAs, the possibility of
theft and the time required to revoke the key authorization must be theft and 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 17 skipping to change at page 19, line 50
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
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. Fortunately, the not like to create a dependency on its deployment. In the case of a
vulnerabilities created by this attack are both localized and of cache poisoning attack, the vulnerabilities created by this attack
limited duration, although records with relatively long TTL may be are both localized and of limited duration, although records with
created with cache poisoning. relatively long TTL may be 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
skipping to change at page 19, line 44 skipping to change at page 20, line 29
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 the public-key encryption/
decryption operations, may over time be subject to mathematical decryption 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
collision attack. Hash collision attacks in message signing systems
involve the same person creating two different messages that have the
same hash value, where only one of the two messages would normally be
signed. The attack is based on the second message inheriting the
signature of the first. For DKIM, this means that a sender might
create a "good" message and a "bad" message, where some filter at the
signing party's site would sign the good message but not the bad
message. The attacker gets the good message signed, and then
incorporates that signature in the bad message. This scenario is not
common, but could happen, for example, at a site that does content
analysis on messages before signing them.
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, rather than 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
skipping to change at page 20, line 17 skipping to change at page 21, line 15
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
considerable period. Algorithms used for message signatures considerable period. Algorithms used for message signatures
therefore need to be secure against expected cryptographic therefore need to be secure against expected cryptographic
developments several years into the future. developments several years into 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, which 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 an 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 bring the attacker to account for the use of another's display
name. name.
skipping to change at page 24, line 43 skipping to change at page 25, line 43
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
There has recently been observed [US-CERT-DNS] an increase in denial- Recently [US-CERT-DNS], an increase in denial-of-service attacks
of-service attacks involving the transmission of spoofed UDP DNS involving the transmission of spoofed UDP DNS requests to openly-
requests to openly-accessible domain name servers. To the extent accessible domain name servers. To the extent that the response from
that the response from the name server is larger than the request, the name server is larger than the request, the name server functions
the name server functions as an amplifier for such an attack. 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 which 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 is an attempt to capture a set of requirements for DKIM This section lists requirements for DKIM not explicitly stated in the
from 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.
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.
skipping to change at page 25, line 42 skipping to change at page 26, line 42
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]
Bernstein, D., "Cache Timing Attacks on AES", April 2004.
[Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are
Practical", Proc. 12th USENIX Security Symposium, 2003.
[I-D.allman-dkim-ssp] [I-D.allman-dkim-ssp]
Allman, E., "DKIM Sender Signing Policy", Allman, E., "DKIM Sender Signing Policy",
draft-allman-dkim-ssp-01 (work in progress), October 2005. draft-allman-dkim-ssp-01 (work in progress), October 2005.
[I-D.ietf-dkim-base] [I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail Signatures Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-00 (work in progress), (DKIM)", draft-ietf-dkim-base-00 (work in progress),
February 2006. February 2006.
[Kocher96]
Kocher, P., "Timing Attacks on Implementations of Diffie-
Hellman, RSA, and other Cryptosystems", Advances in
Cryptology, pages 104-113, 1996.
[Kocher99]
Kocher, P., Joffe, J., and B. Yun, "Differential Power
Analysis: Leaking Secrets", Crypto '99, pages 388-397,
1999.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. 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 - VERSION
skipping to change at page 26, line 29 skipping to change at page 27, line 45
Rose, "DNS Security Introduction and Requirements", 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 Posed by US-CERT, "The Continuing Denial of Service Threat 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 #36:
Unicode Security Considerations", UTR 36, July 2005. Unicode Security Considerations", UTR 36, July 2005.
Appendix A. Glossary Appendix A. Acknowledgements
Administrative Unit (AU) - The portion of the path of an email
message that is under common administration. The originator and
recipient typically develop trust relationships with the
administrative units that send and receive their email, respectively,
to perform the signing and verification of their messages.
Origin address - The address on an email message, typically the RFC
2822 From: address, which is associated with the alleged author of
the message and is displayed by the recipient's MUA as the source of
the message.
Appendix B. 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, and numerous Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla,
others on the ietf-dkim mailing list for valuable suggestions and Paul Hoffman, and numerous others on the ietf-dkim mailing list for
constructive criticism of earlier versions of this draft. valuable suggestions and constructive criticism of earlier versions
of this draft.
Appendix C. Edit History Appendix B. Edit History
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.
skipping to change at page 28, line 5 skipping to change at page 29, line 5
Changes since draft-ietf-dkim-threats-00 draft: Changes since draft-ietf-dkim-threats-00 draft:
o Added description of key publication by higher level domain o Added description of key publication by higher level domain
attack. attack.
o Added description of falsification of SSP replies. o Added description of falsification of SSP replies.
o Added section on other threats and description of packet o Added section on other threats and description of packet
amplification attacks via DNS. 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.
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. 46 change blocks. 
144 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/