only pay attention to) the display name portion of the address. This
inconsistency leads to an attack where the attacker uses a From
header field such as:
From: "Dudley DoRight" <whiplash@example.org>
In this example, the attacker, whiplash@example.org, can sign the
message and still convince some recipients that the message is from
Dudley DoRight, who is presumably a trusted individual. Coupled with
the use of a throw-away domain or email address, it may be difficult
to hold the attacker accountable for using another’s display name.
This is an attack that must be dealt with in the recipient’s MUA.
One approach is to require that the signer’s address specification
(and not just the display name) be visible to the recipient.
4.1.16. Compromised System within Originator’s Network
In many cases, MTAs may be configured to accept and sign messages
that originate within the topological boundaries of the originator’s
network (i.e., within a firewall). The increasing use of compromised
systems to send email presents a problem for such policies, because
the attacker, using a compromised system as a proxy, can generate
signed mail at will.
Several approaches exist for mitigating this attack. The use of
authenticated submission, even within the network boundaries, can be
used to limit the addresses for which the attacker may obtain a
signature. It may also help locate the compromised system that is
the source of the messages more quickly. Content analysis of
outbound mail to identify undesirable and malicious content, as well
as monitoring of the volume of messages being sent by users, may also
prevent arbitrary messages from being signed and sent.
4.1.17. Verification Probe Attack
As noted above, bad actors (attackers) can sign messages on behalf of
domains they control. Since they may also control the key service
(e.g., the authoritative DNS name servers for the _domainkey
subdomain), it is possible for them to observe public key lookups,
and their source, when messages are verified.
One such attack, which we will refer to as a "verification probe", is
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
each instance of the message would typically use a different
selector. The attacker could then monitor key service requests and
determine which selectors had been accessed, and correspondingly
which addressees used DKIM verification. This could be used to
target future mailings at recipients who do not use DKIM
verification, on the premise that these addressees are more likely to
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 that 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 Practices
The following is a summary of postulated attacks against signing
practices:
+---------------------------------------------+--------+------------+
| Attack Name | Impact | Likelihood |
+---------------------------------------------+--------+------------+
| Look-alike domain names | High | High |
| Internationalized domain name abuse | High | High |
| Denial-of-service attack against signing | Medium | Medium |
| practices | | |
| Use of multiple From addresses | Low | Medium |
| Abuse of third-party signatures | Medium | High |
| Falsification of Sender Signing Practices | Medium | Medium |
| replies | | |
+---------------------------------------------+--------+------------+
4.2.1. Look-Alike Domain Names
Attackers may attempt to circumvent signing practices of a domain by
using a domain name that is close to, but not the same as, the domain
with signing practices. For instance, "example.com" might be
replaced by "examp1e.com". If the message is not to be signed, DKIM
does not require that the domain used actually exist (although other
mechanisms may make this a requirement). Services exist to monitor
domain registrations to identify potential domain name abuse, but
naturally do not identify the use of unregistered domain names.
A related attack is possible when the MUA does not render the domain
name in an easily recognizable format. If, for example, a Chinese
domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the
unfamiliarity of that representation may enable other domains to more
easily be mis-recognized as the expected domain.
Users that are unfamiliar with internet naming conventions may also
mis-recognize certain names. For example, users may confuse
online.example.com with online-example.com, the latter of which may
have been registered by an attacker.
4.2.2. Internationalized Domain Name Abuse
Internationalized domain names present a special case of the look-
alike domain name attack described above. Due to similarities in the
appearance of many Unicode characters, domains (particularly those
drawing characters from different groups) may be created that are
visually indistinguishable from other, possibly high-value domains.
This is discussed in detail in Unicode Technical Report 36 [UTR36].
Surveillance of domain registration records may point out some of
these, but there are many such similarities. As in the look-alike
domain attack above, this technique may also be used to circumvent
sender signing practices of other domains.
4.2.3. Denial-of-Service Attack against Signing Practices
Just as the publication of public keys by a domain can be impacted by
an attacker, so can the publication of Sender Signing Practices (SSP)
by a domain. In the case of SSP, the transmission of large amounts
of unsigned mail purporting to come from the domain can result in a
heavy transaction load requesting the SSP record. More general DoS
attacks against the servers providing the SSP records are possible as
well. This is of particular concern since the default signing
practices are "we don’t sign everything", which means that SSP
failures result in the verifier’s failure to heed more stringent
signing practices.
As with defense against DoS attacks for key servers, the best defense
against this attack is to provide redundant servers, preferably on
geographically-separate parts of the Internet. Caching again helps a
great deal, and signing practices should rarely change, so TTL values
can be relatively large.
4.2.4. Use of Multiple From Addresses
Although this usage is never seen by most recipients, RFC 2822
[RFC2822] permits the From address to contain multiple address
specifications. The lookup of Sender Signing Practices is based on
the From address, so if addresses from multiple domains are in the
From address, the question arises which signing practices to use. A
rule (say, "use the first address") could be specified, but then an
attacker could put a throwaway address prior to that of a high-value
domain. It is also possible for SSP to look at all addresses, and
choose the most restrictive rule. This is an area in need of further
study.
4.2.5. Abuse of Third-Party Signatures
In a number of situations, including mailing lists, event
invitations, and "send this article to a friend" services, the DKIM
signature on a message may not come from the originating address
domain. For this reason, "third-party" signatures, those attached by
the mailing list, invitation service, or news service, frequently
need to be regarded as having some validity. Since this effectively
makes it possible for any domain to sign any message, a sending
domain may publish sender signing practices stating that it does not
use such services, and accordingly that verifiers should view such
signatures with suspicion.
However, the restrictions placed on a domain by publishing "no
third-party" signing practices effectively disallows many existing
uses of email. For the majority of domains that are unable to adopt
these practices, an attacker may with some degree of success sign
messages purporting to come from the domain. For this reason,
accreditation and reputation services, as well as locally-maintained
whitelists and blacklists, will need to play a significant role in
evaluating messages that have been signed by third parties.
4.2.6. Falsification of Sender Signing Practices Replies
In an analogous manner to the falsification of key service replies
described in Section 4.1.12, replies to sender signing practices
queries can also be falsified. One such attack would be to weaken
the signing practices 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
that 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
Recently, there has been an increase in denial-of-service attacks
involving the transmission of spoofed UDP DNS requests to openly-
accessible domain name servers [US-CERT-DNS]. 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 that uses large DNS records, and a DNS-based
solution to this problem will likely be required.
5. Derived Requirements
This section lists requirements for DKIM not explicitly stated in the
above discussion. These requirements include:
The store for key and SSP records must be capable of utilizing
multiple geographically-dispersed servers.
Key and SSP records must be cacheable, either by the verifier
requesting them or by other infrastructure.
The cache time-to-live for key records must be specifiable on a
per-record basis.
The signature algorithm identifier in the message must be one of
the ones listed in a key record for the identified domain.
The algorithm(s) used for message signatures need to be secure
against expected cryptographic developments several years in the
future.
6. Security Considerations
This document describes the security threat environment in which
DomainKeys Identified Mail (DKIM) is expected to provide some
benefit, and it presents a number of attacks relevant to its
deployment.
7. 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.
[DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", Work in Progress, August 2006.
[DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in
Progress, August 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", STD 53, RFC 1939, May 1996.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
S. Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[US-CERT-DNS] 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. Acknowledgements
The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony
Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon
Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla,
Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim
mailing list for valuable suggestions and constructive criticism of
earlier versions of this document.
Author’s Address
Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5914
EMail: fenton@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).