7Network Working Group J. Fenton
8Request for Comments: 4686 Cisco Systems, Inc.
9Category: Informational September 2006
12 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
22 Copyright (C) The Internet Society (2006).
26 This document provides an analysis of some threats against Internet
27 mail that are intended to be addressed by signature-based mail
28 authentication, in particular DomainKeys Identified Mail. It
29 discusses the nature and location of the bad actors, what their
30 capabilities are, and what they intend to accomplish via their
58Fenton Informational [Page 1]
60RFC 4686 DKIM Threat Analysis September 2006
65 1. Introduction ....................................................3
66 1.1. Terminology and Model ......................................3
67 1.2. Document Structure .........................................5
68 2. The Bad Actors ..................................................6
69 2.1. Characteristics ............................................6
70 2.2. Capabilities ...............................................6
71 2.3. Location ...................................................8
72 2.3.1. Externally-Located Bad Actors .......................8
73 2.3.2. Within Claimed Originator's Administrative Unit .....8
74 2.3.3. Within Recipient's Administrative Unit ..............9
75 3. Representative Bad Acts .........................................9
76 3.1. Use of Arbitrary Identities ................................9
77 3.2. Use of Specific Identities ................................10
78 3.2.1. Exploitation of Social Relationships ...............10
79 3.2.2. Identity-Related Fraud .............................11
80 3.2.3. Reputation Attacks .................................11
81 3.2.4. Reflection Attacks .................................11
82 4. Attacks on Message Signing .....................................12
83 4.1. Attacks against Message Signatures ........................12
84 4.1.1. Theft of Private Key for Domain ....................13
85 4.1.2. Theft of Delegated Private Key .....................13
86 4.1.3. Private Key Recovery via Side Channel Attack .......14
87 4.1.4. Chosen Message Replay ..............................14
88 4.1.5. Signed Message Replay ..............................16
89 4.1.6. Denial-of-Service Attack against Verifier ..........16
90 4.1.7. Denial-of-Service Attack against Key Service .......17
91 4.1.8. Canonicalization Abuse .............................17
92 4.1.9. Body Length Limit Abuse ............................17
93 4.1.10. Use of Revoked Key ................................18
94 4.1.11. Compromise of Key Server ..........................18
95 4.1.12. Falsification of Key Service Replies ..............19
96 4.1.13. Publication of Malformed Key Records
97 and/or Signatures .................................19
98 4.1.14. Cryptographic Weaknesses in Signature Generation ..20
99 4.1.15. Display Name Abuse ................................21
100 4.1.16. Compromised System within Originator's Network ....21
101 4.1.17. Verification Probe Attack .........................21
102 4.1.18. Key Publication by Higher-Level Domain ............22
103 4.2. Attacks against Message Signing Practices .................23
104 4.2.1. Look-Alike Domain Names ............................23
105 4.2.2. Internationalized Domain Name Abuse ................23
106 4.2.3. Denial-of-Service Attack against Signing
107 Practices ..........................................24
108 4.2.4. Use of Multiple From Addresses .....................24
109 4.2.5. Abuse of Third-Party Signatures ....................24
110 4.2.6. Falsification of Sender Signing Practices Replies ..25
114Fenton Informational [Page 2]
116RFC 4686 DKIM Threat Analysis September 2006
119 4.3. Other Attacks .............................................25
120 4.3.1. Packet Amplification Attacks via DNS ...............25
121 5. Derived Requirements ...........................................26
122 6. Security Considerations ........................................26
123 7. Informative References .........................................27
124 Appendix A. Acknowledgements ......................................28
128 The DomainKeys Identified Mail (DKIM) protocol is being specified by
129 the IETF DKIM Working Group. The DKIM protocol defines a mechanism
130 by which email messages can be cryptographically signed, permitting a
131 signing domain to claim responsibility for the use of a given email
132 address. Message recipients can verify the signature by querying the
133 signer's domain directly to retrieve the appropriate public key, and
134 thereby confirm that the message was attested to by a party in
135 possession of the private key for the signing domain. This document
136 addresses threats relative to two works in progress by the DKIM
137 Working Group, the DKIM signature specification [DKIM-BASE] and DKIM
138 Sender Signing Practices [DKIM-SSP].
140 Once the attesting party or parties have been established, the
141 recipient may evaluate the message in the context of additional
142 information such as locally-maintained whitelists, shared reputation
143 services, and/or third-party accreditation. The description of these
144 mechanisms is outside the scope of the IETF DKIM Working Group
145 effort. By applying a signature, a good player enables a verifier to
146 associate a positive reputation with the message, in hopes that it
147 will receive preferential treatment by the recipient.
149 This effort is not intended to address threats associated with
150 message confidentiality nor does it intend to provide a long-term
1531.1. Terminology and Model
155 An administrative unit (AU) is the portion of the path of an email
156 message that is under common administration. The originator and
157 recipient typically develop trust relationships with the
158 administrative units that send and receive their email, respectively,
159 to perform the signing and verification of their messages.
161 The origin address is the address on an email message, typically the
162 RFC 2822 From: address, which is associated with the alleged author
163 of the message and is displayed by the recipient's Mail User Agent
164 (MUA) as the source of the message.
170Fenton Informational [Page 3]
172RFC 4686 DKIM Threat Analysis September 2006
175 The following diagram illustrates a typical usage flowchart for DKIM:
177 +---------------------------------+
178 | SIGNATURE CREATION |
179 | (Originating or Relaying AU) |
181 | Sign (Message, Domain, Key) |
183 +---------------------------------+
184 | - Message (Domain, Key)
189 +---------------------------------+
190 +-----------+ | SIGNATURE VERIFICATION |
191 | | | (Relaying or Delivering AU) |
193 | QUERY +--->| Verify (Message, Domain, Key) |
195 +-----------+ +----------------+----------------+
197 +-----------+ V - [Report]
198 | SENDER | +----------------+----------------+
200 | PRACTICES +--->| SIGNER EVALUATION |
202 | | +---------------------------------+
205 DKIM operates entirely on the content (body and selected header
206 fields) of the message, as defined in RFC 2822 [RFC2822]. The
207 transmission of messages via SMTP, defined in RFC 2821 [RFC2821], and
208 such elements as the envelope-from and envelope-to addresses and the
209 HELO domain are not relevant to DKIM verification. This is an
210 intentional decision made to allow verification of messages via
211 protocols other than SMTP, such as POP [RFC1939] and IMAP [RFC3501]
212 which an MUA acting as a verifier might use.
214 The Sender Signing Practices Query referred to in the diagram above
215 is a means by which the verifier can query the alleged author's
216 domain to determine their practices for signing messages, which in
217 turn may influence their evaluation of the message. If, for example,
218 a message arrives without any valid signatures, and the alleged
219 author's domain advertises that they sign all messages, the verifier
220 might handle that message differently than if a signature was not
221 necessarily to be expected.
226Fenton Informational [Page 4]
228RFC 4686 DKIM Threat Analysis September 2006
2311.2. Document Structure
233 The remainder of this document describes the problems that DKIM might
234 be expected to address, and the extent to which it may be successful
235 in so doing. These are described in terms of the potential bad
236 actors, their capabilities and location in the network, and the bad
237 acts that they might wish to commit.
239 This is followed by a description of postulated attacks on DKIM
240 message signing and on the use of Sender Signing Practices to assist
241 in the treatment of unsigned messages. A list of derived
242 requirements is also presented, which is intended to guide the DKIM
243 design and review process.
245 The sections dealing with attacks on DKIM each begin with a table
246 summarizing the postulated attacks in each category along with their
247 expected impact and likelihood. The following definitions were used
248 as rough criteria for scoring the attacks:
252 High: Affects the verification of messages from an entire domain
255 Medium: Affects the verification of messages from specific users,
256 Mail Transfer Agents (MTAs), and/or bounded time periods
258 Low: Affects the verification of isolated individual messages
263 High: All email users should expect this attack on a frequent
266 Medium: Email users should expect this attack occasionally;
267 frequently for a few users
269 Low: Attack is expected to be rare and/or very infrequent
282Fenton Informational [Page 5]
284RFC 4686 DKIM Threat Analysis September 2006
291 The problem space being addressed by DKIM is characterized by a wide
292 range of attackers in terms of motivation, sophistication, and
295 At the low end of the spectrum are bad actors who may simply send
296 email, perhaps using one of many commercially available tools, that
297 the recipient does not want to receive. These tools typically allow
298 one to falsify the origin address of messages, and may, in the
299 future, be capable of generating message signatures as well.
301 At the next tier are what would be considered "professional" senders
302 of unwanted email. These attackers would deploy specific
303 infrastructure, including Mail Transfer Agents (MTAs), registered
304 domains and networks of compromised computers ("zombies") to send
305 messages, and in some cases to harvest addresses to which to send.
306 These senders often operate as commercial enterprises and send
307 messages on behalf of third parties.
309 The most sophisticated and financially-motivated senders of messages
310 are those who stand to receive substantial financial benefit, such as
311 from an email-based fraud scheme. These attackers can be expected to
312 employ all of the above mechanisms and additionally may attack the
313 Internet infrastructure itself, including DNS cache-poisoning attacks
314 and IP routing attacks.
318 In general, the bad actors described above should be expected to have
319 access to the following:
321 1. An extensive corpus of messages from domains they might wish to
324 2. Knowledge of the business aims and model for domains they might
327 3. Access to public keys and associated authorization records
328 associated with the domain
330 and the ability to do at least some of the following:
332 1. Submit messages to MTAs and Message Submission Agents (MSAs) at
333 multiple locations in the Internet
338Fenton Informational [Page 6]
340RFC 4686 DKIM Threat Analysis September 2006
343 2. Construct arbitrary message header fields, including those
344 claiming to be mailing lists, resenders, and other mail agents
346 3. Sign messages on behalf of domains under their control
348 4. Generate substantial numbers of either unsigned or apparently-
349 signed messages that might be used to attempt a denial-of-service
352 5. Resend messages that may have been previously signed by the
355 6. Transmit messages using any envelope information desired
357 7. Act as an authorized submitter for messages from a compromised
360 As noted above, certain classes of bad actors may have substantial
361 financial motivation for their activities, and therefore should be
362 expected to have more capabilities at their disposal. These include:
364 1. Manipulation of IP routing. This could be used to submit
365 messages from specific IP addresses or difficult-to-trace
366 addresses, or to cause diversion of messages to a specific
369 2. Limited influence over portions of DNS using mechanisms such as
370 cache poisoning. This might be used to influence message routing
371 or to falsify advertisements of DNS-based keys or signing
374 3. Access to significant computing resources, for example, through
375 the conscription of worm-infected "zombie" computers. This could
376 allow the bad actor to perform various types of brute-force
379 4. Ability to eavesdrop on existing traffic, perhaps from a wireless
382 Either of the first two of these mechanisms could be used to allow
383 the bad actor to function as a man-in-the-middle between author and
384 recipient, if that attack is useful.
394Fenton Informational [Page 7]
396RFC 4686 DKIM Threat Analysis September 2006
401 Bad actors or their proxies can be located anywhere in the Internet.
402 Certain attacks are possible primarily within the administrative unit
403 of the claimed originator and/or recipient domain have capabilities
404 beyond those elsewhere, as described in the below sections. Bad
405 actors can also collude by acting from multiple locations (a
406 "distributed bad actor").
408 It should also be noted that with the use of "zombies" and other
409 proxies, externally-located bad actors may gain some of the
410 capabilities of being located within the claimed originator's or
411 recipient's administrative unit. This emphasizes the importance of
412 appropriate security measures, such as authenticated submission of
413 messages, even within administrative units.
4152.3.1. Externally-Located Bad Actors
417 DKIM focuses primarily on bad actors located outside of the
418 administrative units of the claimed originator and the recipient.
419 These administrative units frequently correspond to the protected
420 portions of the network adjacent to the originator and recipient. It
421 is in this area that the trust relationships required for
422 authenticated message submission do not exist and do not scale
423 adequately to be practical. Conversely, within these administrative
424 units, there are other mechanisms such as authenticated message
425 submission that are easier to deploy and more likely to be used than
428 External bad actors are usually attempting to exploit the "any to
429 any" nature of email that motivates most recipient MTAs to accept
430 messages from anywhere for delivery to their local domain. They may
431 generate messages without signatures, with incorrect signatures, or
432 with correct signatures from domains with little traceability. They
433 may also pose as mailing lists, greeting cards, or other agents that
434 legitimately send or resend messages on behalf of others.
4362.3.2. Within Claimed Originator's Administrative Unit
438 Bad actors in the form of rogue or unauthorized users or malware-
439 infected computers can exist within the administrative unit
440 corresponding to a message's origin address. Since the submission of
441 messages in this area generally occurs prior to the application of a
442 message signature, DKIM is not directly effective against these bad
443 actors. Defense against these bad actors is dependent upon other
444 means, such as proper use of firewalls, and Message Submission Agents
445 that are configured to authenticate the author.
450Fenton Informational [Page 8]
452RFC 4686 DKIM Threat Analysis September 2006
455 In the special case where the administrative unit is non-contiguous
456 (e.g., a company that communicates between branches over the external
457 Internet), DKIM signatures can be used to distinguish between
458 legitimate externally-originated messages and attempts to spoof
459 addresses in the local domain.
4612.3.3. Within Recipient's Administrative Unit
463 Bad actors may also exist within the administrative unit of the
464 message recipient. These bad actors may attempt to exploit the trust
465 relationships that exist within the unit. Since messages will
466 typically only have undergone DKIM verification at the administrative
467 unit boundary, DKIM is not effective against messages submitted in
470 For example, the bad actor may attempt to spoof a header field
471 indicating the results of verification. This header field would
472 normally be added by the verifier, which would also detect spoofed
473 header fields on messages it was attempting to verify. This could be
474 used to falsely indicate that the message was authenticated
477 As in the originator case, these bad actors can be dealt with by
478 controlling the submission of messages within the administrative
479 unit. Since DKIM permits verification to occur anywhere within the
480 recipient's administrative unit, these threats can also be minimized
481 by moving verification closer to the recipient, such as at the Mail
482 Delivery Agent (MDA), or on the recipient's MUA itself.
4843. Representative Bad Acts
486 One of the most fundamental bad acts being attempted is the delivery
487 of messages that are not intended to have been sent by the alleged
488 originating domain. As described above, these messages might merely
489 be unwanted by the recipient, or might be part of a confidence scheme
490 or a delivery vector for malware.
4923.1. Use of Arbitrary Identities
494 This class of bad acts includes the sending of messages that aim to
495 obscure the identity of the actual author. In some cases, the actual
496 sender might be the bad actor, or in other cases might be a third-
497 party under the control of the bad actor (e.g., a compromised
500 Particularly when coupled with sender signing practices that indicate
501 the domain owner signs all messages, DKIM can be effective in
502 mitigating against the abuse of addresses not controlled by bad
506Fenton Informational [Page 9]
508RFC 4686 DKIM Threat Analysis September 2006
511 actors. DKIM is not effective against the use of addresses
512 controlled by bad actors. In other words, the presence of a valid
513 DKIM signature does not guarantee that the signer is not a bad actor.
514 It also does not guarantee the accountability of the signer, since
515 DKIM does not attempt to identify the signer individually, but rather
516 identifies the domain that they control. Accreditation and
517 reputation systems and locally-maintained whitelists and blacklists
518 can be used to enhance the accountability of DKIM-verified addresses
519 and/or the likelihood that signed messages are desirable.
5213.2. Use of Specific Identities
523 A second major class of bad acts involves the assertion of specific
526 Note that some bad acts involving specific identities can sometimes
527 be accomplished, although perhaps less effectively, with similar
528 looking identities that mislead some recipients. For example, if the
529 bad actor is able to control the domain "examp1e.com" (note the "one"
530 between the p and e), they might be able to convince some recipients
531 that a message from admin@examp1e.com is really from
532 admin@example.com. Similar types of attacks using internationalized
533 domain names have been hypothesized where it could be very difficult
534 to see character differences in popular typefaces. Similarly, if
535 example2.com was controlled by a bad actor, the bad actor could sign
536 messages from bigbank.example2.com, which might also mislead some
537 recipients. To the extent that these domains are controlled by bad
538 actors, DKIM is not effective against these attacks, although it
539 could support the ability of reputation and/or accreditation systems
540 to aid the user in identifying them.
542 DKIM is effective against the use of specific identities only when
543 there is an expectation that such messages will, in fact, be signed.
544 The primary means for establishing this is the use of Sender Signing
545 Practices (SSP), which will be specified by the IETF DKIM Working
5483.2.1. Exploitation of Social Relationships
550 One reason for asserting a specific origin address is to encourage a
551 recipient to read and act on particular email messages by appearing
552 to be an acquaintance or previous correspondent that the recipient
553 might trust. This tactic has been used by email-propagated malware
554 that mail themselves to addresses in the infected host's address
555 book. In this case, however, the author's address may not be
556 falsified, so DKIM would not be effective in defending against this
562Fenton Informational [Page 10]
564RFC 4686 DKIM Threat Analysis September 2006
567 It is also possible for address books to be harvested and used by an
568 attacker to post messages from elsewhere. DKIM could be effective in
569 mitigating these acts by limiting the scope of origin addresses for
570 which a valid signature can be obtained when sending the messages
571 from other locations.
5733.2.2. Identity-Related Fraud
575 Bad acts related to email-based fraud often, but not always, involve
576 the transmission of messages using specific origin addresses of other
577 entities as part of the fraud scheme. The use of a specific address
578 of origin sometimes contributes to the success of the fraud by
579 helping convince the recipient that the message was actually sent by
582 To the extent that the success of the fraud depends on or is enhanced
583 by the use of a specific origin address, the bad actor may have
584 significant financial motivation and resources to circumvent any
585 measures taken to protect specific addresses from unauthorized use.
587 When signatures are verified by or for the recipient, DKIM is
588 effective in defending against the fraudulent use of origin addresses
589 on signed messages. When the published sender signing practices of
590 the origin address indicate that all messages from that address
591 should be signed, DKIM further mitigates against the attempted
592 fraudulent use of the origin address on unsigned messages.
5943.2.3. Reputation Attacks
596 Another motivation for using a specific origin address in a message
597 is to harm the reputation of another, commonly referred to as a
598 "joe-job". For example, a commercial entity might wish to harm the
599 reputation of a competitor, perhaps by sending unsolicited bulk email
600 on behalf of that competitor. It is for this reason that reputation
601 systems must be based on an identity that is, in practice, fairly
6043.2.4. Reflection Attacks
606 A commonly-used tactic by some bad actors is the indirect
607 transmission of messages by intentionally mis-addressing the message
608 and causing it to be "bounced", or sent to the return address (RFC
609 2821 envelope-from address) on the message. In this case, the
610 specific identity asserted in the email is that of the actual target
611 of the message, to whom the message is "returned".
613 DKIM does not, in general, attempt to validate the RFC2821.mailfrom
614 return address on messages, either directly (noting that the mailfrom
618Fenton Informational [Page 11]
620RFC 4686 DKIM Threat Analysis September 2006
623 address is an element of the SMTP protocol, and not the message
624 content on which DKIM operates), or via the optional Return-Path
625 header field. Furthermore, as is noted in Section 4.4 of RFC 2821
626 [RFC2821], it is common and useful practice for a message's return
627 path not to correspond to the origin address. For these reasons,
628 DKIM is not effective against reflection attacks.
6304. Attacks on Message Signing
632 Bad actors can be expected to exploit all of the limitations of
633 message authentication systems. They are also likely to be motivated
634 to degrade the usefulness of message authentication systems in order
635 to hinder their deployment. Both the signature mechanism itself and
636 declarations made regarding use of message signatures (referred to
637 here as Sender Signing Practices or SSP) can be expected to be the
6404.1. Attacks against Message Signatures
642 The following is a summary of postulated attacks against DKIM
645 +---------------------------------------------+--------+------------+
646 | Attack Name | Impact | Likelihood |
647 +---------------------------------------------+--------+------------+
648 | Theft of private key for domain | High | Low |
649 | Theft of delegated private key | Medium | Medium |
650 | Private key recovery via side channel attack| High | Low |
651 | Chosen message replay | Low | M/H |
652 | Signed message replay | Low | High |
653 | Denial-of-service attack against verifier | High | Medium |
654 | Denial-of-service attack against key service| High | Medium |
655 | Canonicalization abuse | Low | Medium |
656 | Body length limit abuse | Medium | Medium |
657 | Use of revoked key | Medium | Low |
658 | Compromise of key server | High | Low |
659 | Falsification of key service replies | Medium | Medium |
660 | Publication of malformed key records and/or | High | Low |
662 | Cryptographic weaknesses in signature | High | Low |
664 | Display name abuse | Medium | High |
665 | Compromised system within originator's | High | Medium |
667 | Verification probe attack | Medium | Medium |
668 | Key publication by higher-level domain | High | Low |
669 +---------------------------------------------+--------+------------+
674Fenton Informational [Page 12]
676RFC 4686 DKIM Threat Analysis September 2006
6794.1.1. Theft of Private Key for Domain
681 Message signing technologies such as DKIM are vulnerable to theft of
682 the private keys used to sign messages. This includes "out-of-band"
683 means for this theft, such as burglary, bribery, extortion, and the
684 like, as well as electronic means for such theft, such as a
685 compromise of network and host security around the place where a
686 private key is stored.
688 Keys that are valid for all addresses in a domain typically reside in
689 MTAs that should be located in well-protected sites, such as data
690 centers. Various means should be employed for minimizing access to
691 private keys, such as non-existence of commands for displaying their
692 value, although ultimately memory dumps and the like will probably
693 contain the keys. Due to the unattended nature of MTAs, some
694 countermeasures, such as the use of a pass phrase to "unlock" a key,
695 are not practical to use. Other mechanisms, such as the use of
696 dedicated hardware devices that contain the private key and perform
697 the cryptographic signature operation, would be very effective in
698 denying export of the private key to those without physical access to
699 the device. Such devices would almost certainly make the theft of
700 the key visible, so that appropriate action (revocation of the
701 corresponding public key) can be taken should that happen.
7034.1.2. Theft of Delegated Private Key
705 There are several circumstances where a domain owner will want to
706 delegate the ability to sign messages for the domain to an individual
707 user or a third party associated with an outsourced activity such as
708 a corporate benefits administrator or a marketing campaign. Since
709 these keys may exist on less well-protected devices than the domain's
710 own MTAs, they will in many cases be more susceptible to compromise.
712 In order to mitigate this exposure, keys used to sign such messages
713 can be restricted by the domain owner to be valid for signing
714 messages only on behalf of specific addresses in the domain. This
715 maintains protection for the majority of addresses in the domain.
717 A related threat is the exploitation of weaknesses in the delegation
718 process itself. This threat can be mitigated through the use of
719 customary precautions against the theft of private keys and the
720 falsification of public keys in transit. For example, the exposure
721 to theft can be minimized if the delegate generates the keypair to be
722 used, and sends the public key to the domain owner. The exposure to
723 falsification (substitution of a different public key) can be reduced
724 if this transmission is signed by the delegate and verified by the
730Fenton Informational [Page 13]
732RFC 4686 DKIM Threat Analysis September 2006
7354.1.3. Private Key Recovery via Side Channel Attack
737 All popular digital signature algorithms are subject to a variety of
738 side channel attacks. The most well-known of these are timing
739 channels [Kocher96], power analysis [Kocher99], and cache timing
740 analysis [Bernstein04]. Most of these attacks require either
741 physical access to the machine or the ability to run processes
742 directly on the target machine. Defending against these attacks is
743 out of scope for DKIM.
745 However, remote timing analysis (at least on local area networks) is
746 known to be feasible [Boneh03], particularly in server-type platforms
747 where the attacker can inject traffic that will immediately be
748 subject to the cryptographic operation in question. With enough
749 samples, these techniques can be used to extract private keys even in
750 the face of modest amounts of noise in the timing measurements.
752 The three commonly proposed countermeasures against timing analysis
755 1. Make the operation run in constant time. This turns out in
756 practice to be rather difficult.
758 2. Make the time independent of the input data. This can be
759 difficult, but see [Boneh03] for more details.
761 3. Use blinding. This is generally considered the best current
762 practice countermeasure, and while not proved generally secure is
763 a countermeasure against known timing attacks. It adds about
764 2-10% to the cost of the operation and is implemented in many
765 common cryptographic libraries. Unfortunately, Digital Signature
766 Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have
767 standard methods though some defenses may exist.
769 Note that adding random delays to the operation is only a partial
770 countermeasure. Because the noise is generally uniformly
771 distributed, a large enough number of samples can be used to average
772 it out and extract an accurate timing signal.
7744.1.4. Chosen Message Replay
776 Chosen message replay refers to the scenario where the attacker
777 creates a message and obtains a signature for it by sending it
778 through an MTA authorized by the originating domain to
779 himself/herself or an accomplice. They then "replay" the signed
780 message by sending it, using different envelope addresses, to a
781 (typically large) number of other recipients.
786Fenton Informational [Page 14]
788RFC 4686 DKIM Threat Analysis September 2006
791 Due to the requirement to get an attacker-generated message signed,
792 chosen message replay would most commonly be experienced by consumer
793 ISPs or others offering email accounts to clients, particularly where
794 there is little or no accountability to the account holder (the
795 attacker in this case). One approach to solving this problem is for
796 the domain to only sign email for clients that have passed a vetting
797 process to provide traceability to the message originator in the
798 event of abuse. At present, the low cost of email accounts (zero)
799 does not make it practical for any vetting to occur. It remains to
800 be seen whether this will be the model with signed mail as well, or
801 whether a higher level of trust will be required to obtain an email
804 A variation on this attack involves the attacker sending a message
805 with the intent of obtaining a signed reply containing their original
806 message. The reply might come from an innocent user or might be an
807 automatic response such as a "user unknown" bounce message. In some
808 cases, this signed reply message might accomplish the attacker's
809 objectives if replayed. This variation on chosen message replay can
810 be mitigated by limiting the extent to which the original content is
811 quoted in automatic replies, and by the use of complementary
812 mechanisms such as egress content filtering.
814 Revocation of the signature or the associated key is a potential
815 countermeasure. However, the rapid pace at which the message might
816 be replayed (especially with an army of "zombie" computers), compared
817 with the time required to detect the attack and implement the
818 revocation, is likely to be problematic. A related problem is the
819 likelihood that domains will use a small number of signing keys for a
820 large number of customers, which is beneficial from a caching
821 standpoint but is likely to result in a great deal of collateral
822 damage (in the form of signature verification failures) should a key
825 Signature revocation addresses the collateral damage problem at the
826 expense of significant scaling requirements. At the extreme,
827 verifiers could be required to check for revocation of each signature
828 verified, which would result in very significant transaction rates.
829 An alternative, "revocation identifiers", has been proposed, which
830 would permit revocation on an intermediate level of granularity,
831 perhaps on a per-account basis. Messages containing these
832 identifiers would result in a query to a revocation database, which
833 might be represented in DNS.
835 Further study is needed to determine if the benefits from revocation
836 (given the potential speed of a replay attack) outweigh the
837 transactional cost of querying a revocation database.
842Fenton Informational [Page 15]
844RFC 4686 DKIM Threat Analysis September 2006
8474.1.5. Signed Message Replay
849 Signed message replay refers to the retransmission of already-signed
850 messages to additional recipients beyond those intended by the author
851 or the original poster of the message. The attacker arranges to
852 receive a message from the victim, and then retransmits it intact but
853 with different envelope addresses. This might be done, for example,
854 to make it look like a legitimate sender of messages is sending a
855 large amount of spam. When reputation services are deployed, this
856 could damage the author's reputation or that of the author's domain.
858 A larger number of domains are potential victims of signed message
859 replay than chosen message replay because the former does not require
860 the ability for the attacker to send messages from the victim domain.
861 However, the capabilities of the attacker are lower. Unless coupled
862 with another attack such as body length limit abuse, it isn't
863 possible for the attacker to use this, for example, for advertising.
865 Many mailing lists, especially those that do not modify the content
866 of the message and signed header fields and hence do not invalidate
867 the signature, engage in a form of signed message replay. The use of
868 body length limits and other mechanisms to enhance the survivability
869 of messages effectively enhances the ability to do so. The only
870 things that distinguish this case from undesirable forms of signed
871 message replay is the intent of the replayer, which cannot be
872 determined by the network.
8744.1.6. Denial-of-Service Attack against Verifier
876 While it takes some computing resources to sign and verify a
877 signature, it takes negligible computing resources to generate an
878 invalid signature. An attacker could therefore construct a "make
879 work" attack against a verifier, by sending a large number of
880 incorrectly-signed messages to a given verifier, perhaps with
881 multiple signatures each. The motivation might be to make it too
882 expensive to verify messages.
884 While this attack is feasible, it can be greatly mitigated by the
885 manner in which the verifier operates. For example, it might decide
886 to accept only a certain number of signatures per message, limit the
887 maximum key size it will accept (to prevent outrageously large
888 signatures from causing unneeded work), and verify signatures in a
889 particular order. The verifier could also maintain state
890 representing the current signature verification failure rate and
891 adopt a defensive posture when attacks may be under way.
898Fenton Informational [Page 16]
900RFC 4686 DKIM Threat Analysis September 2006
9034.1.7. Denial-of-Service Attack against Key Service
905 An attacker might also attempt to degrade the availability of an
906 originator's key service, in order to cause that originator's
907 messages to be unverifiable. One way to do this might be to quickly
908 send a large number of messages with signatures that reference a
909 particular key, thereby creating a heavy load on the key server.
910 Other types of DoS attacks on the key server or the network
911 infrastructure serving it are also possible.
913 The best defense against this attack is to provide redundant key
914 servers, preferably on geographically-separate parts of the Internet.
915 Caching also helps a great deal, by decreasing the load on
916 authoritative key servers when there are many simultaneous key
917 requests. The use of a key service protocol that minimizes the
918 transactional cost of key lookups is also beneficial. It is noted
919 that the Domain Name System has all these characteristics.
9214.1.8. Canonicalization Abuse
923 Canonicalization algorithms represent a tradeoff between the survival
924 of the validity of a message signature and the desire not to allow
925 the message to be altered inappropriately. In the past,
926 canonicalization algorithms have been proposed that would have
927 permitted attackers, in some cases, to alter the meaning of a
930 Message signatures that support multiple canonicalization algorithms
931 give the signer the ability to decide the relative importance of
932 signature survivability and immutability of the signed content. If
933 an unexpected vulnerability appears in a canonicalization algorithm
934 in general use, new algorithms can be deployed, although it will be a
935 slow process because the signer can never be sure which algorithm(s)
936 the verifier supports. For this reason, canonicalization algorithms,
937 like cryptographic algorithms, should undergo a wide and careful
9404.1.9. Body Length Limit Abuse
942 A body length limit is an optional indication from the signer of how
943 much content has been signed. The verifier can either ignore the
944 limit, verify the specified portion of the message, or truncate the
945 message to the specified portion and verify it. The motivation for
946 this feature is the behavior of many mailing lists that add a
947 trailer, perhaps identifying the list, at the end of messages.
954Fenton Informational [Page 17]
956RFC 4686 DKIM Threat Analysis September 2006
959 When body length limits are used, there is the potential for an
960 attacker to add content to the message. It has been shown that this
961 content, although at the end, can cover desirable content, especially
962 in the case of HTML messages.
964 If the body length isn't specified, or if the verifier decides to
965 ignore the limit, body length limits are moot. If the verifier or
966 recipient truncates the message at the signed content, there is no
967 opportunity for the attacker to add anything.
969 If the verifier observes body length limits when present, there is
970 the potential that an attacker can make undesired content visible to
971 the recipient. The size of the appended content makes little
972 difference, because it can simply be a URL reference pointing to the
973 actual content. Receiving MUAs can mitigate this threat by, at a
974 minimum, identifying the unsigned content in the message.
9764.1.10. Use of Revoked Key
978 The benefits obtained by caching of key records opens the possibility
979 that keys that have been revoked may be used for some period of time
980 after their revocation. The best examples of this occur when a
981 holder of a key delegated by the domain administrator must be
982 unexpectedly deauthorized from sending mail on behalf of one or more
983 addresses in the domain.
985 The caching of key records is normally short-lived, on the order of
986 hours to days. In many cases, this threat can be mitigated simply by
987 setting a short time-to-live (TTL) for keys not under the domain
988 administrator's direct control (assuming, of course, that control of
989 the TTL value may be specified for each record, as it can with DNS).
990 In some cases, such as the recovery following a stolen private key
991 belonging to one of the domain's MTAs, the possibility of theft and
992 the effort required to revoke the key authorization must be
993 considered when choosing a TTL. The chosen TTL must be long enough
994 to mitigate denial-of-service attacks and provide reasonable
995 transaction efficiency, and no longer.
9974.1.11. Compromise of Key Server
999 Rather than by attempting to obtain a private key, an attacker might
1000 instead focus efforts on the server used to publish public keys for a
1001 domain. As in the key theft case, the motive might be to allow the
1002 attacker to sign messages on behalf of the domain. This attack
1003 provides the attacker with the additional capability to remove
1004 legitimate keys from publication, thereby denying the domain the
1005 ability for the signatures on its mail to verify correctly.
1010Fenton Informational [Page 18]
1012RFC 4686 DKIM Threat Analysis September 2006
1015 In order to limit the ability to sign a message to entities
1016 authorized by the owner of a signing domain, a relationship must be
1017 established between the signing address and the location from which a
1018 public key is obtained to verify the message. DKIM does this by
1019 publishing either the public key or a reference to it within the DNS
1020 hierarchy of the signing domain. The verifier derives the location
1021 from which to retrieve the public key from the signing address or
1022 domain. The security of the verification process is therefore
1023 dependent on the security of the DNS hierarchy for the signing
1026 An attacker might successfully compromise the host that is the
1027 primary key server for the signing domain, such as the domain's DNS
1028 master server. Another approach might be to compromise a higher-
1029 level DNS server and change the delegation of name servers for the
1030 signing domain to others under the control of the attacker.
1032 This attack can be mitigated somewhat by independent monitoring to
1033 audit the key service. Such auditing of the key service should occur
1034 by means of zone transfers rather than queries to the zone's primary
1035 server, so that the addition of records to the zone can be detected.
10374.1.12. Falsification of Key Service Replies
1039 Replies from the key service may also be spoofed by a suitably
1040 positioned attacker. For DNS, one such way to do this is "cache
1041 poisoning", in which the attacker provides unnecessary (and
1042 incorrect) additional information in DNS replies, which is cached.
1044 DNSSEC [RFC4033] is the preferred means of mitigating this threat,
1045 but the current uptake rate for DNSSEC is slow enough that one would
1046 not like to create a dependency on its deployment. In the case of a
1047 cache poisoning attack, the vulnerabilities created by this attack
1048 are both localized and of limited duration, although records with
1049 relatively long TTL may persist beyond the attack itself.
10514.1.13. Publication of Malformed Key Records and/or Signatures
1053 In this attack, the attacker publishes suitably crafted key records
1054 or sends mail with intentionally malformed signatures, in an attempt
1055 to confuse the verifier and perhaps disable verification altogether.
1056 This attack is really a characteristic of an implementation
1057 vulnerability, a buffer overflow or lack of bounds checking, for
1058 example, rather than a vulnerability of the signature mechanism
1059 itself. This threat is best mitigated by careful implementation and
1060 creation of test suites that challenge the verification process.
1066Fenton Informational [Page 19]
1068RFC 4686 DKIM Threat Analysis September 2006
10714.1.14. Cryptographic Weaknesses in Signature Generation
1073 The cryptographic algorithms used to generate mail signatures,
1074 specifically the hash algorithm and digital signature generation and
1075 verification operations, may over time be subject to mathematical
1076 techniques that degrade their security. At this writing, the SHA-1
1077 hash algorithm is the subject of extensive mathematical analysis that
1078 has considerably lowered the time required to create two messages
1079 with the same hash value. This trend can be expected to continue.
1081 One consequence of a weakness in the hash algorithm is a hash
1082 collision attack. Hash collision attacks in message signing systems
1083 involve the same person creating two different messages that have the
1084 same hash value, where only one of the two messages would normally be
1085 signed. The attack is based on the second message inheriting the
1086 signature of the first. For DKIM, this means that a sender might
1087 create a "good" message and a "bad" message, where some filter at the
1088 signing party's site would sign the good message but not the bad
1089 message. The attacker gets the good message signed, and then
1090 incorporates that signature in the bad message. This scenario is not
1091 common, but could happen, for example, at a site that does content
1092 analysis on messages before signing them.
1094 Current known attacks against SHA-1 make this attack extremely
1095 difficult to mount, but as attacks improve and computing power
1096 becomes more readily available, such an attack could become
1099 The message signature system must be designed to support multiple
1100 signature and hash algorithms, and the signing domain must be able to
1101 specify which algorithms it uses to sign messages. The choice of
1102 algorithms must be published in key records, and not only in the
1103 signature itself, to ensure that an attacker is not able to create
1104 signatures using algorithms weaker than the domain wishes to permit.
1106 Because the signer and verifier of email do not, in general,
1107 communicate directly, negotiation of the algorithms used for signing
1108 cannot occur. In other words, a signer has no way of knowing which
1109 algorithm(s) a verifier supports or (due to mail forwarding) where
1110 the verifier is. For this reason, it is expected that once message
1111 signing is widely deployed, algorithm change will occur slowly, and
1112 legacy algorithms will need to be supported for a considerable
1113 period. Algorithms used for message signatures therefore need to be
1114 secure against expected cryptographic developments several years into
1122Fenton Informational [Page 20]
1124RFC 4686 DKIM Threat Analysis September 2006
11274.1.15. Display Name Abuse
1129 Message signatures only relate to the address-specification portion
1130 of an email address, while some MUAs only display (or some recipients
1131 only pay attention to) the display name portion of the address. This
1132 inconsistency leads to an attack where the attacker uses a From
1133 header field such as:
1135 From: "Dudley DoRight" <whiplash@example.org>
1137 In this example, the attacker, whiplash@example.org, can sign the
1138 message and still convince some recipients that the message is from
1139 Dudley DoRight, who is presumably a trusted individual. Coupled with
1140 the use of a throw-away domain or email address, it may be difficult
1141 to hold the attacker accountable for using another's display name.
1143 This is an attack that must be dealt with in the recipient's MUA.
1144 One approach is to require that the signer's address specification
1145 (and not just the display name) be visible to the recipient.
11474.1.16. Compromised System within Originator's Network
1149 In many cases, MTAs may be configured to accept and sign messages
1150 that originate within the topological boundaries of the originator's
1151 network (i.e., within a firewall). The increasing use of compromised
1152 systems to send email presents a problem for such policies, because
1153 the attacker, using a compromised system as a proxy, can generate
1154 signed mail at will.
1156 Several approaches exist for mitigating this attack. The use of
1157 authenticated submission, even within the network boundaries, can be
1158 used to limit the addresses for which the attacker may obtain a
1159 signature. It may also help locate the compromised system that is
1160 the source of the messages more quickly. Content analysis of
1161 outbound mail to identify undesirable and malicious content, as well
1162 as monitoring of the volume of messages being sent by users, may also
1163 prevent arbitrary messages from being signed and sent.
11654.1.17. Verification Probe Attack
1167 As noted above, bad actors (attackers) can sign messages on behalf of
1168 domains they control. Since they may also control the key service
1169 (e.g., the authoritative DNS name servers for the _domainkey
1170 subdomain), it is possible for them to observe public key lookups,
1171 and their source, when messages are verified.
1178Fenton Informational [Page 21]
1180RFC 4686 DKIM Threat Analysis September 2006
1183 One such attack, which we will refer to as a "verification probe", is
1184 to send a message with a DKIM signature to each of many addresses in
1185 a mailing list. The messages need not contain valid signatures, and
1186 each instance of the message would typically use a different
1187 selector. The attacker could then monitor key service requests and
1188 determine which selectors had been accessed, and correspondingly
1189 which addressees used DKIM verification. This could be used to
1190 target future mailings at recipients who do not use DKIM
1191 verification, on the premise that these addressees are more likely to
1192 act on the message contents.
11944.1.18. Key Publication by Higher-Level Domain
1196 In order to support the ability of a domain to sign for subdomains
1197 under its administrative control, DKIM permits the domain of a
1198 signature (d= tag) to be any higher-level domain than the signature's
1199 address (i= or equivalent). However, since there is no mechanism for
1200 determining common administrative control of a subdomain, it is
1201 possible for a parent to publish keys that are valid for any domain
1202 below them in the DNS hierarchy. In other words, mail from the
1203 domain example.anytown.ny.us could be signed using keys published by
1204 anytown.ny.us, ny.us, or us, in addition to the domain itself.
1206 Operation of a domain always requires a trust relationship with
1207 higher-level domains. Higher-level domains already have ultimate
1208 power over their subdomains: they could change the name server
1209 delegation for the domain or disenfranchise it entirely. So it is
1210 unlikely that a higher-level domain would intentionally compromise a
1211 subdomain in this manner. However, if higher-level domains send mail
1212 on their own behalf, they may wish to publish keys at their own
1213 level. Higher-level domains must employ special care in the
1214 delegation of keys they publish to ensure that any of their
1215 subdomains are not compromised by misuse of such keys.
1234Fenton Informational [Page 22]
1236RFC 4686 DKIM Threat Analysis September 2006
12394.2. Attacks against Message Signing Practices
1241 The following is a summary of postulated attacks against signing
1244 +---------------------------------------------+--------+------------+
1245 | Attack Name | Impact | Likelihood |
1246 +---------------------------------------------+--------+------------+
1247 | Look-alike domain names | High | High |
1248 | Internationalized domain name abuse | High | High |
1249 | Denial-of-service attack against signing | Medium | Medium |
1251 | Use of multiple From addresses | Low | Medium |
1252 | Abuse of third-party signatures | Medium | High |
1253 | Falsification of Sender Signing Practices | Medium | Medium |
1255 +---------------------------------------------+--------+------------+
12574.2.1. Look-Alike Domain Names
1259 Attackers may attempt to circumvent signing practices of a domain by
1260 using a domain name that is close to, but not the same as, the domain
1261 with signing practices. For instance, "example.com" might be
1262 replaced by "examp1e.com". If the message is not to be signed, DKIM
1263 does not require that the domain used actually exist (although other
1264 mechanisms may make this a requirement). Services exist to monitor
1265 domain registrations to identify potential domain name abuse, but
1266 naturally do not identify the use of unregistered domain names.
1268 A related attack is possible when the MUA does not render the domain
1269 name in an easily recognizable format. If, for example, a Chinese
1270 domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the
1271 unfamiliarity of that representation may enable other domains to more
1272 easily be mis-recognized as the expected domain.
1274 Users that are unfamiliar with internet naming conventions may also
1275 mis-recognize certain names. For example, users may confuse
1276 online.example.com with online-example.com, the latter of which may
1277 have been registered by an attacker.
12794.2.2. Internationalized Domain Name Abuse
1281 Internationalized domain names present a special case of the look-
1282 alike domain name attack described above. Due to similarities in the
1283 appearance of many Unicode characters, domains (particularly those
1284 drawing characters from different groups) may be created that are
1285 visually indistinguishable from other, possibly high-value domains.
1286 This is discussed in detail in Unicode Technical Report 36 [UTR36].
1290Fenton Informational [Page 23]
1292RFC 4686 DKIM Threat Analysis September 2006
1295 Surveillance of domain registration records may point out some of
1296 these, but there are many such similarities. As in the look-alike
1297 domain attack above, this technique may also be used to circumvent
1298 sender signing practices of other domains.
13004.2.3. Denial-of-Service Attack against Signing Practices
1302 Just as the publication of public keys by a domain can be impacted by
1303 an attacker, so can the publication of Sender Signing Practices (SSP)
1304 by a domain. In the case of SSP, the transmission of large amounts
1305 of unsigned mail purporting to come from the domain can result in a
1306 heavy transaction load requesting the SSP record. More general DoS
1307 attacks against the servers providing the SSP records are possible as
1308 well. This is of particular concern since the default signing
1309 practices are "we don't sign everything", which means that SSP
1310 failures result in the verifier's failure to heed more stringent
1313 As with defense against DoS attacks for key servers, the best defense
1314 against this attack is to provide redundant servers, preferably on
1315 geographically-separate parts of the Internet. Caching again helps a
1316 great deal, and signing practices should rarely change, so TTL values
1317 can be relatively large.
13194.2.4. Use of Multiple From Addresses
1321 Although this usage is never seen by most recipients, RFC 2822
1322 [RFC2822] permits the From address to contain multiple address
1323 specifications. The lookup of Sender Signing Practices is based on
1324 the From address, so if addresses from multiple domains are in the
1325 From address, the question arises which signing practices to use. A
1326 rule (say, "use the first address") could be specified, but then an
1327 attacker could put a throwaway address prior to that of a high-value
1328 domain. It is also possible for SSP to look at all addresses, and
1329 choose the most restrictive rule. This is an area in need of further
13324.2.5. Abuse of Third-Party Signatures
1334 In a number of situations, including mailing lists, event
1335 invitations, and "send this article to a friend" services, the DKIM
1336 signature on a message may not come from the originating address
1337 domain. For this reason, "third-party" signatures, those attached by
1338 the mailing list, invitation service, or news service, frequently
1339 need to be regarded as having some validity. Since this effectively
1340 makes it possible for any domain to sign any message, a sending
1346Fenton Informational [Page 24]
1348RFC 4686 DKIM Threat Analysis September 2006
1351 domain may publish sender signing practices stating that it does not
1352 use such services, and accordingly that verifiers should view such
1353 signatures with suspicion.
1355 However, the restrictions placed on a domain by publishing "no
1356 third-party" signing practices effectively disallows many existing
1357 uses of email. For the majority of domains that are unable to adopt
1358 these practices, an attacker may with some degree of success sign
1359 messages purporting to come from the domain. For this reason,
1360 accreditation and reputation services, as well as locally-maintained
1361 whitelists and blacklists, will need to play a significant role in
1362 evaluating messages that have been signed by third parties.
13644.2.6. Falsification of Sender Signing Practices Replies
1366 In an analogous manner to the falsification of key service replies
1367 described in Section 4.1.12, replies to sender signing practices
1368 queries can also be falsified. One such attack would be to weaken
1369 the signing practices to make unsigned messages allegedly from a
1370 given domain appear less suspicious. Another attack on a victim
1371 domain that is not signing messages could attempt to make the
1372 domain's messages look more suspicious, in order to interfere with
1373 the victim's ability to send mail.
1375 As with the falsification of key service replies, DNSSEC is the
1376 preferred means of mitigating this attack. Even in the absence of
1377 DNSSEC, vulnerabilities due to cache poisoning are localized.
1381 This section describes attacks against other Internet infrastructure
1382 that are enabled by deployment of DKIM. A summary of these
1383 postulated attacks is as follows:
1385 +--------------------------------------+--------+------------+
1386 | Attack Name | Impact | Likelihood |
1387 +--------------------------------------+--------+------------+
1388 | Packet amplification attacks via DNS | N/A | Medium |
1389 +--------------------------------------+--------+------------+
13914.3.1. Packet Amplification Attacks via DNS
1393 Recently, there has been an increase in denial-of-service attacks
1394 involving the transmission of spoofed UDP DNS requests to openly-
1395 accessible domain name servers [US-CERT-DNS]. To the extent that the
1396 response from the name server is larger than the request, the name
1397 server functions as an amplifier for such an attack.
1402Fenton Informational [Page 25]
1404RFC 4686 DKIM Threat Analysis September 2006
1407 DKIM contributes indirectly to this attack by requiring the
1408 publication of fairly large DNS records for distributing public keys.
1409 The names of these records are also well known, since the record
1410 names can be determined by examining properly-signed messages. This
1411 attack does not have an impact on DKIM itself. DKIM, however, is not
1412 the only application that uses large DNS records, and a DNS-based
1413 solution to this problem will likely be required.
14155. Derived Requirements
1417 This section lists requirements for DKIM not explicitly stated in the
1418 above discussion. These requirements include:
1420 The store for key and SSP records must be capable of utilizing
1421 multiple geographically-dispersed servers.
1423 Key and SSP records must be cacheable, either by the verifier
1424 requesting them or by other infrastructure.
1426 The cache time-to-live for key records must be specifiable on a
1429 The signature algorithm identifier in the message must be one of
1430 the ones listed in a key record for the identified domain.
1432 The algorithm(s) used for message signatures need to be secure
1433 against expected cryptographic developments several years in the
14366. Security Considerations
1438 This document describes the security threat environment in which
1439 DomainKeys Identified Mail (DKIM) is expected to provide some
1440 benefit, and it presents a number of attacks relevant to its
1458Fenton Informational [Page 26]
1460RFC 4686 DKIM Threat Analysis September 2006
14637. Informative References
1465 [Bernstein04] Bernstein, D., "Cache Timing Attacks on AES",
1468 [Boneh03] Boneh, D. and D. Brumley, "Remote Timing Attacks are
1469 Practical", Proc. 12th USENIX Security Symposium,
1472 [DKIM-BASE] Allman, E., "DomainKeys Identified Mail (DKIM)
1473 Signatures", Work in Progress, August 2006.
1475 [DKIM-SSP] Allman, E., "DKIM Sender Signing Practices", Work in
1476 Progress, August 2006.
1478 [Kocher96] Kocher, P., "Timing Attacks on Implementations of
1479 Diffie-Hellman, RSA, and other Cryptosystems",
1480 Advances in Cryptology, pages 104-113, 1996.
1482 [Kocher99] Kocher, P., Joffe, J., and B. Yun, "Differential Power
1483 Analysis: Leaking Secrets", Crypto '99, pages 388-397,
1486 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version
1487 3", STD 53, RFC 1939, May 1996.
1489 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol",
1490 RFC 2821, April 2001.
1492 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
1495 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
1496 VERSION 4rev1", RFC 3501, March 2003.
1498 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
1499 S. Rose, "DNS Security Introduction and Requirements",
1500 RFC 4033, March 2005.
1502 [US-CERT-DNS] US-CERT, "The Continuing Denial of Service Threat
1503 Posed by DNS Recursion".
1505 [UTR36] Davis, M. and M. Suignard, "Unicode Technical Report
1506 #36: Unicode Security Considerations", UTR 36,
1514Fenton Informational [Page 27]
1516RFC 4686 DKIM Threat Analysis September 2006
1519Appendix A. Acknowledgements
1521 The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony
1522 Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon
1523 Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla,
1524 Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim
1525 mailing list for valuable suggestions and constructive criticism of
1526 earlier versions of this document.
1534 San Jose, CA 95134-1706
1537 Phone: +1 408 526 5914
1538 EMail: fenton@cisco.com
1570Fenton Informational [Page 28]
1572RFC 4686 DKIM Threat Analysis September 2006
1575Full Copyright Statement
1577 Copyright (C) The Internet Society (2006).
1579 This document is subject to the rights, licenses and restrictions
1580 contained in BCP 78, and except as set forth therein, the authors
1581 retain all their rights.
1583 This document and the information contained herein are provided on an
1584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1591Intellectual Property
1593 The IETF takes no position regarding the validity or scope of any
1594 Intellectual Property Rights or other rights that might be claimed to
1595 pertain to the implementation or use of the technology described in
1596 this document or the extent to which any license under such rights
1597 might or might not be available; nor does it represent that it has
1598 made any independent effort to identify any such rights. Information
1599 on the procedures with respect to rights in RFC documents can be
1600 found in BCP 78 and BCP 79.
1602 Copies of IPR disclosures made to the IETF Secretariat and any
1603 assurances of licenses to be made available, or the result of an
1604 attempt made to obtain a general license or permission for the use of
1605 such proprietary rights by implementers or users of this
1606 specification can be obtained from the IETF on-line IPR repository at
1607 http://www.ietf.org/ipr.
1609 The IETF invites any interested party to bring to its attention any
1610 copyrights, patents or patent applications, or other proprietary
1611 rights that may cover technology that may be required to implement
1612 this standard. Please address the information to the IETF at
1617 Funding for the RFC Editor function is provided by the IETF
1618 Administrative Support Activity (IASA).
1626Fenton Informational [Page 29]