draft-ietf-dkim-threats-00.txt   draft-ietf-dkim-threats-01.txt 
DKIM Working Group J. Fenton DKIM Working Group J. Fenton
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: July 24, 2006 January 20, 2006 Expires: September 6, 2006 March 5, 2006
Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
draft-ietf-dkim-threats-00 draft-ietf-dkim-threats-01
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 July 24, 2006. This Internet-Draft will expire on September 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 44 skipping to change at page 2, line 44
4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 17 4.1.9. Body Length Limit Abuse . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . 19
4.1.14. Cryptographic Weaknesses in Signature Generation . . . 19 4.1.14. Cryptographic Weaknesses in Signature Generation . . . 19
4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 20 4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 20
4.1.16. Compromised System Within Originator's Network . . . . 20 4.1.16. Compromised System Within Originator's Network . . . . 20
4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 21 4.1.17. Verification Probe Attack . . . . . . . . . . . . . . 21
4.2. Attacks Against Message Signing Policy . . . . . . . . . . 21 4.1.18. Key Publication by Higher Level Domain . . . . . . . . 21
4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 21 4.2. Attacks Against Message Signing Policy . . . . . . . . . . 22
4.2.1. Look-Alike Domain Names . . . . . . . . . . . . . . . 22
4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 22 4.2.2. Internationalized Domain Name Abuse . . . . . . . . . 22
4.2.3. Denial-of-Service Attack Against Signing Policy . . . 22 4.2.3. Denial-of-Service Attack Against Signing Policy . . . 23
4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 22 4.2.4. Use of Multiple From Addresses . . . . . . . . . . . . 23
4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 23 4.2.5. Abuse of Third-Party Signatures . . . . . . . . . . . 23
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 23 4.2.6. Falsification of Sender Signing Policy Replies . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 4.3. Other Attacks . . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 4.3.1. Packet Amplification Attacks via DNS . . . . . . . . . 24
8. Informative References . . . . . . . . . . . . . . . . . . . . 24 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
Appendix C. Edit History . . . . . . . . . . . . . . . . . . . . 25 8. Informative References . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Glossary . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26
Appendix C. Edit History . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
DomainKeys Identified Mail (DKIM) [I-D.allman-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.
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
skipping to change at page 12, line 41 skipping to change at page 12, line 41
effective against reflection attacks. 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.allman-dkim-base] ) 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 13, line 34 skipping to change at page 13, line 34
| Compromise of key server | High | Low | | Compromise of key server | High | Low |
| Falsification of key service replies | Medium | Medium | | Falsification of key service replies | Medium | Medium |
| Publication of malformed key records and/or | High | Low | | Publication of malformed key records and/or | High | Low |
| signatures | | | | signatures | | |
| Cryptographic weaknesses in signature | High | Low | | Cryptographic weaknesses in signature | High | Low |
| generation | | | | generation | | |
| Display name abuse | Medium | High | | Display name abuse | Medium | High |
| Compromised system within originator's | High | Medium | | Compromised system within originator's | High | Medium |
| network | | | | network | | |
| Verification probe attack | Medium | Medium | | Verification probe attack | Medium | Medium |
| Key publication by higher level domain | High | Low |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
4.1.1. Theft of Private Key for Domain 4.1.1. Theft of Private Key for Domain
Message signing technologies such as DKIM are vulnerable to theft of Message signing technologies such as DKIM are vulnerable to theft of
the private keys used to sign messages. This includes "out-of-band" the private keys used to sign messages. This includes "out-of-band"
means for this theft, such as burglary, bribery, extortion, and the means for this theft, such as burglary, bribery, extortion, and the
like, as well as electronic means for such theft, such as a like, as well as electronic means for such theft, such as a
compromise of network and host security around the place where a compromise of network and host security around the place where a
private key is stored. private key is stored.
skipping to change at page 21, line 24 skipping to change at page 21, line 24
to send a message with a DKIM signature to each of many addresses in to send a message with a DKIM signature to each of many addresses in
a mailing list. The messages need not contain valid signatures, and a mailing list. The messages need not contain valid signatures, and
each instance of the message would typically use a different each instance of the message would typically use a different
selector. The attacker could then monitor key service requests and selector. The attacker could then monitor key service requests and
determine which selectors had been accessed, and correspondingly determine which selectors had been accessed, and correspondingly
which addressees used DKIM verification. This could be used to which addressees used DKIM verification. This could be used to
target future mailings at recipients who do not use DKIM target future mailings at recipients who do not use DKIM
verification, on the premise that these addressees are more likely to verification, on the premise that these addressees are more likely to
act on the message contents. act on the message contents.
4.1.18. Key Publication by Higher Level Domain
In order to support the ability of a domain to sign for subdomains
under its administrative control, DKIM permits the domain of a
signature (d= tag) to be any higher-level domain than the signature's
address (i= or equivalent). However, since there is no mechanism for
determining common administrative control of a subdomain, it is
possible for a parent to publish keys which are valid for any domain
below them in the DNS hierarchy. In other words, mail from the
domain example.anytown.ny.us could be signed using keys published by
anytown.ny.us, ny.us, or us, in addition to the domain itself.
Operation of a domain always requires a trust relationship with
higher level domains. Higher level domains already have ultimate
power over their subdomains: they could change the name server
delegation for the domain or disenfranchise it entirely. So it is
unlikely that a higher level domain would intentionally compromise a
subdomain in this manner. However, if higher level domains send mail
on their own behalf, they may wish to publish keys at their own
level. Higher level domains must employ special care in the
delegation of keys they publish to ensure that any of their
subdomains are not compromised by misuse of such keys.
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 | Medium |
| 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 |
| replies | | |
+---------------------------------------------+--------+------------+ +---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names 4.2.1. Look-Alike Domain Names
Attackers may attempt to circumvent signing policy of a domain by Attackers may attempt to circumvent signing policy of a domain by
using a domain name which is close to, but not the same as the domain using a domain name which is close to, but not the same as the domain
with a signing policy. For instance, "example.com" might be replaced with a signing policy. For instance, "example.com" might be replaced
by "examp1e.com". If the message is not to be signed, DKIM does not by "examp1e.com". If the message is not to be signed, DKIM does not
require that the domain used actually exist (although other require that the domain used actually exist (although other
mechanisms may make this a requirement). Services exist to monitor mechanisms may make this a requirement). Services exist to monitor
skipping to change at page 23, line 30 skipping to change at page 24, line 14
However, the restrictions placed on a domain by publishing "no third- However, the restrictions placed on a domain by publishing "no third-
party" signing practices effectively disallows many existing uses of party" signing practices effectively disallows many existing uses of
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
In an analogous manner to the falsification of key service replies
described above, replies to sender signing policy queries can also be
falsified. One such attack would be to weaken the signing policy to
make unsigned messages allegedly from a given domain appear less
suspicious. Another attack on a victim domain that is not signing
messages could attempt to make the domain's messages look more
suspicious, in order to interfere with the victim's ability to send
mail.
As with the falsification of key service replies, DNSSEC is the
preferred means of mitigating this attack. Even in the absence of
DNSSEC, vulnerabilities due to cache poisoning are localized.
4.3. Other Attacks
This section describes attacks against other internet infrastructure
which are enabled by deployment of DKIM. A summary of these
postulated attacks is as follows:
+--------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+--------------------------------------+--------+------------+
| Packet amplification attacks via DNS | N/A | Medium |
+--------------------------------------+--------+------------+
4.3.1. Packet Amplification Attacks via DNS
There has recently been observed [US-CERT-DNS] an increase in denial-
of-service attacks involving the transmission of spoofed UDP DNS
requests to openly-accessible domain name servers. To the extent
that the response from the name server is larger than the request,
the name server functions as an amplifier for such an attack.
DKIM contributes indirectly to this attack by requiring the
publication of fairly large DNS records for distributing public keys.
The names of these records are also well known, since the record
names can be determined by examining properly-signed messages. This
attack does not have an impact on DKIM itself. DKIM, however, is not
the only application which uses large DNS records, and a DNS-based
solution to this problem will likely be required.
5. Derived Requirements 5. Derived Requirements
This section, as yet incomplete, is an attempt to capture a set of This section is an attempt to capture a set of requirements for DKIM
requirements for DKIM from the above discussion. These requirements from the above discussion. These requirements include:
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 24, line 18 skipping to change at page 25, 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
[I-D.allman-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)",
draft-allman-dkim-base-01 (work in progress),
October 2005.
[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]
Allman, E., "DomainKeys Identified Mail Signatures
(DKIM)", draft-ietf-dkim-base-00 (work in progress),
February 2006.
[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
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[UTR36] Davis, M. and M. Suignard, "Unicode Security [US-CERT-DNS]
Considerations", UTR 36, July 2005. US-CERT, "The Continuing Denial of Service Threat Posed by
DNS Recursion".
[UTR36] Davis, M. and M. Suignard, "Unicode Technical Report #36:
Unicode Security Considerations", UTR 36, July 2005.
Appendix A. Glossary Appendix A. Glossary
Administrative Unit (AU) - The portion of the path of an email Administrative Unit (AU) - The portion of the path of an email
message that is under common administration. The originator and message that is under common administration. The originator and
recipient typically develop trust relationships with the recipient typically develop trust relationships with the
administrative units that send and receive their email, respectively, administrative units that send and receive their email, respectively,
to perform the signing and verification of their messages. to perform the signing and verification of their messages.
Origin address - The address on an email message, typically the RFC Origin address - The address on an email message, typically the RFC
2822 From: address, which is associated with the alleged author of 2822 From: address, which is associated with the alleged author of
the message and is displayed by the recipient's MUA as the source of the message and is displayed by the recipient's MUA as the source of
the message. the message.
More definitions to be added.
Appendix B. Acknowledgements 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, and numerous
others on the ietf-dkim mailing list for valuable suggestions and others on the ietf-dkim mailing list for valuable suggestions and
constructive criticism of earlier versions of this draft. constructive criticism of earlier versions of this draft.
Appendix C. Edit History Appendix C. Edit History
skipping to change at page 27, line 5 skipping to change at page 27, line 40
Changes since draft-fenton-dkim-threats-02 draft: Changes since draft-fenton-dkim-threats-02 draft:
o Added description of reflection attack, verification probe attack, o Added description of reflection attack, verification probe attack,
and abuse of third-party signatures. and abuse of third-party signatures.
o Expanded description of key delegation attacks and look-alike o Expanded description of key delegation attacks and look-alike
domain names. domain names.
o Numerous changes suggested by ietf-dkim mailing list participants. o Numerous changes suggested by ietf-dkim mailing list participants.
Changes since draft-ietf-dkim-threats-00 draft:
o Added description of key publication by higher level domain
attack.
o Added description of falsification of SSP replies.
o Added section on other threats and description of packet
amplification attacks via DNS.
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. 18 change blocks. 
31 lines changed or deleted 115 lines changed or added

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