DKIM Working Group                                             J. Fenton
Internet-Draft                                       Cisco Systems, Inc.
Expires:  September 6, 2006                                March 5, 2006

    Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This document provides an analysis of some threats against Internet
   mail that are intended to be addressed by signature-based mail
   authentication, in particular DomainKeys Identified Mail.  It
   discusses the nature and location of the bad actors, what their
   capabilities are, and what they intend to accomplish via their

Fenton                  Expires September 6, 2006               [Page 1]

Internet-Draft            DKIM Threat Analysis                March 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology and Model  . . . . . . . . . . . . . . . . . .  4
     1.2.  Document Structure . . . . . . . . . . . . . . . . . . . .  6
   2.  The Bad Actors . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Characteristics  . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Capabilities . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Location . . . . . . . . . . . . . . . . . . . . . . . . .  8
       2.3.1.  Externally-located Bad Actors  . . . . . . . . . . . .  8
       2.3.2.  Within Claimed Originator's Administrative Unit  . . .  9
       2.3.3.  Within Recipient's Administrative Unit . . . . . . . .  9
   3.  Representative Bad Acts  . . . . . . . . . . . . . . . . . . . 10
     3.1.  Use of Arbitrary Identities  . . . . . . . . . . . . . . . 10
     3.2.  Use of Specific Identities . . . . . . . . . . . . . . . . 10
       3.2.1.  Exploitation of Social Relationships . . . . . . . . . 11
       3.2.2.  Identity-Related Fraud . . . . . . . . . . . . . . . . 11
       3.2.3.  Reputation Attacks . . . . . . . . . . . . . . . . . . 12
       3.2.4.  Reflection Attacks . . . . . . . . . . . . . . . . . . 12
   4.  Attacks on Message Signing . . . . . . . . . . . . . . . . . . 12
     4.1.  Attacks Against Message Signatures . . . . . . . . . . . . 13
       4.1.1.  Theft of Private Key for Domain  . . . . . . . . . . . 13
       4.1.2.  Theft of Delegated Private Key . . . . . . . . . . . . 14
       4.1.3.  Private Key Recovery via Side-Channel Attack . . . . . 14
       4.1.4.  Chosen Message Replay  . . . . . . . . . . . . . . . . 15
       4.1.5.  Signed Message Replay  . . . . . . . . . . . . . . . . 16
       4.1.6.  Denial-of-Service Attack Against Verifier  . . . . . . 16
       4.1.7.  Denial-of-Service Attack Against Key Service . . . . . 16
       4.1.8.  Canonicalization Abuse . . . . . . . . . . . . . . . . 17
       4.1.9.  Body Length Limit Abuse  . . . . . . . . . . . . . . . 17
       4.1.10. Use of Revoked Key . . . . . . . . . . . . . . . . . . 18
       4.1.11. Compromise of Key Server . . . . . . . . . . . . . . . 18
       4.1.12. Falsification of Key Service Replies . . . . . . . . . 19
       4.1.13. Publication of Malformed Key Records and/or
               Signatures . . . . . . . . . . . . . . . . . . . . . . 19
       4.1.14. Cryptographic Weaknesses in Signature Generation . . . 19
       4.1.15. Display Name Abuse . . . . . . . . . . . . . . . . . . 20
       4.1.16. Compromised System Within Originator's Network . . . . 20
       4.1.17. Verification Probe Attack  . . . . . . . . . . . . . . 21
       4.1.18. Key Publication by Higher Level Domain . . . . . . . . 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.3.  Denial-of-Service Attack Against Signing Policy  . . . 23
       4.2.4.  Use of Multiple From Addresses . . . . . . . . . . . . 23
       4.2.5.  Abuse of Third-Party Signatures  . . . . . . . . . . . 23
       4.2.6.  Falsification of Sender Signing Policy Replies . . . . 24
     4.3.  Other Attacks  . . . . . . . . . . . . . . . . . . . . . . 24

Fenton                  Expires September 6, 2006               [Page 2]

Internet-Draft            DKIM Threat Analysis                March 2006

       4.3.1.  Packet Amplification Attacks via DNS . . . . . . . . . 24
   5.  Derived Requirements . . . . . . . . . . . . . . . . . . . . . 25
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 25
   Appendix A.  Glossary  . . . . . . . . . . . . . . . . . . . . . . 26
   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 26
   Appendix C.  Edit History  . . . . . . . . . . . . . . . . . . . . 27
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 29

Fenton                  Expires September 6, 2006               [Page 3]

Internet-Draft            DKIM Threat Analysis                March 2006

1.  Introduction

   DomainKeys Identified Mail (DKIM) [I-D.ietf-dkim-base] defines a
   mechanism by which email messages can be cryptographically signed,
   permitting a signing domain to claim responsibility for the use of a
   given email address.  Message recipients can verify the signature by
   querying the signer's domain directly to retrieve the appropriate
   public key, and thereby confirm that the message was attested to by a
   party in possession of the private key for the signing domain.

   Once the attesting party or parties have been established, the
   recipient may evaluate the message in the context of additional
   information such as locally-maintained whitelists, shared reputation
   services, and/or third-party accreditation.  The description of these
   mechanisms is outside the scope of this effort.  By applying a
   signature, a good player enables a verifier to associate a positive
   reputation with the message, in hopes that it will receive
   preferential treatment by the recipient.

   This effort is not intended to address threats associated with
   message confidentiality nor does it intend to provide a long-term
   archival signature.

1.1.  Terminology and Model

   Definitions of some terms used in this document may be found in
   Appendix A.

Fenton                  Expires September 6, 2006               [Page 4]

Internet-Draft            DKIM Threat Analysis                March 2006

   The following diagram illustrates a typical usage flowchart for DKIM:

                      |       SIGNATURE CREATION        |
                      |  (Originating or Relaying AU)   |
                      |                                 |
                      |   Sign (Message, Domain, Key)   |
                      |                                 |
                                       | - Message (Domain, Key)
     +-----------+    |     SIGNATURE VERIFICATION      |
     |           |    |  (Relaying or Delivering AU)    |
     |    KEY    |    |                                 |
     |   QUERY   +...>|  Verify (Message, Domain, Key)  |
     |           |    |                                 |
     +-----------+    +----------------+----------------+
                                       |  - Verified Domain
     +-----------+                     V  - [Report]
     |  SENDER   |    +----------------+----------------+
     |  SIGNING  |    |                                 |
     | PRACTICES +...>|        SIGNER EVALUATION        |
     |   QUERY   |    |                                 |
     |           |    +---------------------------------+

   DKIM operates entirely on the content of the message, as defined in
   RFC 2822 [RFC2822].  The transmission of messages via SMTP, defined
   in RFC 2821 [RFC2821], and such elements as the envelope-from and
   envelope-to addresses and the HELO domain are not relevant to DKIM
   verification.  This is an intentional decision made to allow
   verification of messages via protocols other than SMTP, such as POP
   [RFC1939] and IMAP [RFC3501] which an MUA acting as a verifier might

   The Sender Signing Practices Query referred to in the diagram above
   is a means by which the verifier can query the alleged author's
   domain to determine their practices for signing messages, which in
   turn may influence their evaluation of the message.  If, for example,
   a message arrives without any valid signatures, and the alleged
   author's domain advertises that they sign all messages, the verifier
   might handle that message differently than if a signature was not

Fenton                  Expires September 6, 2006               [Page 5]

Internet-Draft            DKIM Threat Analysis                March 2006

   necessarily to be expected.

1.2.  Document Structure

   The remainder of this document begins by describing problems that
   DKIM might be expected to address, and the extent that it is
   successful in doing so.  These are described in terms of who the bad
   actors are, their capabilities and location in the network, and what
   the bad acts are that they might wish to commit.

   This is followed by a description of postulated attacks on DKIM
   message signing and on the use of Sender Signing Practices to assist
   in the treatment of unsigned messages.  A list of derived
   requirements is also presented which is intended to guide the DKIM
   design and review process.

   The sections dealing with attacks on DKIM each begin with a table
   summarizing the postulated attacks in each category along with their
   expected impact and likelihood.  The following definitions were used
   as rough criteria for scoring the attacks:


   High: Affects the verification of messages from an entire domain or
      multiple domains

   Medium: Affects the verification of messages from specific users,
      MTAs, and/or bounded time periods

   Low: Affects the verification of isolated individual messages only


   High: All email users should expect this attack on a frequent basis

   Medium: Email users should expect this attack occasionally;
      frequently for a few users

   Low: Attack is expected to be rare and/or very infrequent

2.  The Bad Actors

2.1.  Characteristics

   The problem space being addressed by DKIM is characterized by a wide
   range of attackers in terms of motivation, sophistication, and

Fenton                  Expires September 6, 2006               [Page 6]

Internet-Draft            DKIM Threat Analysis                March 2006

   At the low end of the spectrum are bad actors who may simply send
   email, perhaps using one of many commercially available tools, which
   the recipient does not want to receive.  These tools typically allow
   one to falsify the origin address of messages, and may, in the
   future, be capable of generating message signatures as well.

   At the next tier are what would be considered "professional" senders
   of unwanted email.  These attackers would deploy specific
   infrastructure, including Mail Transfer Agents (MTAs), registered
   domains and networks of compromised computers ("zombies") to send
   messages, and in some cases to harvest addresses to which to send.
   These senders often operate as commercial enterprises and send
   messages on behalf of third parties.

   The most sophisticated and financially-motivated senders of messages
   are those who stand to receive substantial financial benefit, such as
   from an email-based fraud scheme.  These attackers can be expected to
   employ all of the above mechanisms and additionally may attack the
   Internet infrastructure itself, e.g., DNS cache-poisoning attacks; IP
   routing attacks via compromised network routing elements.

2.2.  Capabilities

   In general, the bad actors described above should be expected to have
   access to the following:

   1.  An extensive corpus of messages from domains they might wish to

   2.  Knowledge of the business aims and model for domains they might
       wish to impersonate

   3.  Access to public keys and associated authorization records
       associated with the domain

   and the ability to do at least some of the following:

   1.  Submit messages to MTAs and MSAs at multiple locations in the

   2.  Construct arbitrary message header fields, including those
       claiming to be mailing lists, resenders, and other mail agents

   3.  Sign messages on behalf of domains under their control

   4.  Generate substantial numbers of either unsigned or apparently-
       signed messages which might be used to attempt a denial of
       service attack

Fenton                  Expires September 6, 2006               [Page 7]

Internet-Draft            DKIM Threat Analysis                March 2006

   5.  Resend messages which may have been previously signed by the

   6.  Transmit messages using any envelope information desired

   As noted above, certain classes of bad actors may have substantial
   financial motivation for their activities, and therefore should be
   expected to have more capabilities at their disposal.  These include:

   1.  Manipulation of IP routing.  This could be used to submit
       messages from specific IP addresses or difficult-to-trace
       addresses, or to cause diversion of messages to a specific

   2.  Limited influence over portions of DNS using mechanisms such as
       cache poisoning.  This might be used to influence message
       routing, or to cause falsification of DNS-based key or policy

   3.  Access to significant computing resources, for example through
       the conscription of worm-infected "zombie" computers.  This could
       allow the bad actor to perform various types of brute-force

   4.  Ability to "wiretap" some existing traffic, perhaps from a
       wireless network.

   Either of the first two of these mechanisms could be used to allow
   the bad actor to function as a man-in-the-middle between sender and
   recipient, if that attack is useful.

2.3.  Location

   Bad actors or their proxies can be located anywhere in the Internet.
   Certain attacks are possible primarily within the administrative unit
   of the claimed originator and/or recipient domain have capabilities
   beyond those elsewhere, as described in the below sections.  Bad
   actors can also collude by acting from multiple locations (a
   "distributed bad actor").

2.3.1.  Externally-located Bad Actors

   DKIM focuses primarily on bad actors located outside of the
   administrative units of the claimed originator and the recipient.
   These administrative units frequently correspond to the protected
   portions of the network adjacent to the originator and recipient.  It
   is in this area that the trust relationships required for
   authenticated message submission do not exist and do not scale

Fenton                  Expires September 6, 2006               [Page 8]

Internet-Draft            DKIM Threat Analysis                March 2006

   adequately to be practical.  Conversely, within these administrative
   units, there are other mechanisms such as authenticated message
   submission that are easier to deploy and more likely to be used than

   External bad actors are usually attempting to exploit the "any to
   any" nature of email which motivates most recipient MTAs to accept
   messages from anywhere for delivery to their local domain.  They may
   generate messages without signatures, with incorrect signatures, or
   with correct signatures from domains with little traceability.  They
   may also pose as mailing lists, greeting cards, or other agents which
   legitimately send or re-send messages on behalf of others.

2.3.2.  Within Claimed Originator's Administrative Unit

   Bad actors in the form of rogue or unauthorized users or malware-
   infected computers can exist within the administrative unit
   corresponding to a message's origin address.  Since the submission of
   messages in this area generally occurs prior to the application of a
   message signature, DKIM is not directly effective against these bad
   actors.  Defense against these bad actors is dependent upon other
   means, such as proper use of firewalls, and mail submission agents
   that are configured to authenticate the sender.

   In the special case where the administrative unit is non-contiguous
   (e.g., a company that communicates between branches over the external
   Internet), DKIM signatures can be used to distinguish between
   legitimate externally-originated messages and attempts to spoof
   addresses in the local domain.

2.3.3.  Within Recipient's Administrative Unit

   Bad actors may also exist within the administrative unit of the
   message recipient.  These bad actors may attempt to exploit the trust
   relationships which exist within the unit.  Since messages will
   typically only have undergone DKIM verification at the administrative
   unit boundary, DKIM is not effective against messages submitted in
   this area.

   For example, the bad actor may attempt to spoof a header field
   indicating the results of verification.  This header field would
   normally be added by the verifier, which would also detect spoofed
   header fields on messages it was attempting to verify.  This could be
   used to falsely indicate that the message was authenticated

   As in the originator case, these bad actors can be dealt with by
   controlling the submission of messages within the administrative

Fenton                  Expires September 6, 2006               [Page 9]

Internet-Draft            DKIM Threat Analysis                March 2006

   unit.  Since DKIM permits verification to occur anywhere within the
   recipient's administrative unit, these threats can also be minimized
   by moving verification closer to the recipient, such as at the mail
   delivery agent (MDA), or on the recipient's MUA itself.

3.  Representative Bad Acts

   One of the most fundamental bad acts being attempted is the delivery
   of messages which are not intended to have been sent by the alleged
   originating domain.  As described above, these messages might merely
   be unwanted by the recipient, or might be part of a confidence scheme
   or a delivery vector for malware.

3.1.  Use of Arbitrary Identities

   This class of bad acts includes the sending of messages which aim to
   obscure the identity of the actual sender.  In some cases the actual
   sender might be the bad actor, or in other cases might be a third-
   party under the control of the bad actor (e.g., a compromised

   Particularly when coupled with sender signing practices that indicate
   the domain owner signs all messages, DKIM can be effective in
   mitigating against the abuse of addresses not controlled by bad
   actors.  DKIM is not effective against the use of addresses
   controlled by bad actors.  In other words, the presence of a valid
   DKIM signature does not guarantee that the signer is not a bad actor.
   It also does not guarantee the accountability of the signer, since
   DKIM does not attempt to identify the signer individually, but rather
   identifies the domain which they control.  Accreditation and
   reputation systems and locally-maintained whitelists and blacklists
   can be used to enhance the accountability of DKIM-verified addresses
   and/or the likelihood that signed messages are desirable.

3.2.  Use of Specific Identities

   A second major class of bad acts involves the assertion of specific
   identities in email.

   Note that some bad acts involving specific identities can sometimes
   be accomplished, although perhaps less effectively, with similar
   looking identities that mislead some recipients.  For example, if the
   bad actor is able to control the domain "" (note the "one"
   between the p and e), they might be able to convince some recipients
   that a message from is really
   Similar types of attacks using internationalized domain names have
   been hypothesized where it could be very difficult to see character

Fenton                  Expires September 6, 2006              [Page 10]

Internet-Draft            DKIM Threat Analysis                March 2006

   differences in popular typefaces.  Similarly, if was
   controlled by a bad actor, the bad actor could sign messages from which might also mislead some recipients.  To
   the extent that these domains are controlled by bad actors, DKIM is
   not effective against these attacks, although it could support the
   ability of reputation and/or accreditation systems to aid the user in
   identifying them.

3.2.1.  Exploitation of Social Relationships

   One reason for asserting a specific origin address is to encourage a
   recipient to read and act on particular email messages by appearing
   to be an acquaintance or previous correspondent that the recipient
   might trust.  This tactic has been used by email-propagated malware
   which mail themselves to addresses in the infected host's address
   book.  In this case, however, the sender's address may not be
   falsified, so DKIM would not be effective in defending against this

   It is also possible for address books to be harvested and used by an
   attacker to send messages from elsewhere.  DKIM could be effective in
   mitigating these acts by limiting the scope of origin addresses for
   which a valid signature can be obtained when sending the messages
   from other locations.

3.2.2.  Identity-Related Fraud

   Bad acts related to email-based fraud often, but not always, involve
   the transmission of messages using specific origin addresses of other
   entities as part of the fraud scheme.  The use of a specific address
   of origin sometimes contributes to the success of the fraud by
   helping convince the recipient that the message was actually sent by
   the alleged sender.

   To the extent that the success of the fraud depends on or is enhanced
   by the use of a specific origin address, the bad actor may have
   significant financial motivation and resources to circumvent any
   measures taken to protect specific addresses from unauthorized use.

   When signatures are verified by or for the recipient, DKIM is
   effective in defending against the fraudulent use of origin addresses
   on signed messages.  When the published sender signing practices of
   the origin address indicate that all messages from that address
   should be signed, DKIM further mitigates against the attempted
   fraudulent use of the origin address on unsigned messages.

Fenton                  Expires September 6, 2006              [Page 11]

Internet-Draft            DKIM Threat Analysis                March 2006

3.2.3.  Reputation Attacks

   Another motivation for using a specific origin address in a message
   is to harm the reputation of another, commonly referred to as a "joe-
   job".  For example, a commercial entity might wish to harm the
   reputation of a competitor, perhaps by sending unsolicited bulk email
   on behalf of that competitor.  It is for this reason that reputation
   systems must be based on an identity that is, in practice, fairly

3.2.4.  Reflection Attacks

   A commonly-used tactic by some bad actors is the indirect
   transmission of messages by intentionally mis-addressing the message
   and causing it to be "bounced", or sent to the return address
   (RFC2821 envelope-from address) on the message.  In this case, the
   specific identity asserted in the email is that of the actual target
   of the message, to whom the message is "returned".

   DKIM does not, in general, attempt to validate the return address on
   messages, either directly (noting that the envelope-from address is
   an element of the SMTP protocol, and not the message content on which
   DKIM operates), or via the optional Return-Path header field.
   Furthermore, as is noted in section 4.4 of RFC 2821 [RFC2821], it is
   common and useful practice for a message's return path not to
   correspond to the message sender.  For these reasons, DKIM is not
   effective against reflection attacks.

4.  Attacks on Message Signing

   Bad actors can be expected to exploit all of the limitations of
   message authentication systems.  They are also likely to be motivated
   to degrade the usefulness of message authentication systems in order
   to hinder their deployment.  Both the signature mechanism itself and
   declarations made regarding use of message signatures (referred to
   here as Sender Signing Policy, Sender Signing Practices or SSP, as
   described in [I-D.ietf-dkim-base] ) can be expected to be the target
   of attacks.

Fenton                  Expires September 6, 2006              [Page 12]

Internet-Draft            DKIM Threat Analysis                March 2006

4.1.  Attacks Against Message Signatures

          Summary of postulated attacks against DKIM signatures:

   | Attack Name                                 | Impact | Likelihood |
   | Theft of private key for domain             |  High  |     Low    |
   | Theft of delegated private key              | Medium |   Medium   |
   | Private key recovery via side-channel       |  High  |     Low    |
   | attack                                      |        |            |
   | Chosen message replay                       |   Low  |     M/H    |
   | Signed message replay                       |   Low  |    High    |
   | Denial-of-service attack against verifier   |  High  |   Medium   |
   | Denial-of-service attack against key        |  High  |   Medium   |
   | service                                     |        |            |
   | Canonicalization abuse                      |   Low  |   Medium   |
   | Body length limit abuse                     | Medium |   Medium   |
   | Use of revoked key                          | Medium |     Low    |
   | Compromise of key server                    |  High  |     Low    |
   | Falsification of key service replies        | Medium |   Medium   |
   | Publication of malformed key records and/or |  High  |     Low    |
   | signatures                                  |        |            |
   | Cryptographic weaknesses in signature       |  High  |     Low    |
   | generation                                  |        |            |
   | Display name abuse                          | Medium |    High    |
   | Compromised system within originator's      |  High  |   Medium   |
   | network                                     |        |            |
   | Verification probe attack                   | Medium |   Medium   |
   | Key publication by higher level domain      |  High  |     Low    |

4.1.1.  Theft of Private Key for Domain

   Message signing technologies such as DKIM are vulnerable to theft of
   the private keys used to sign messages.  This includes "out-of-band"
   means for this theft, such as burglary, bribery, extortion, and the
   like, as well as electronic means for such theft, such as a
   compromise of network and host security around the place where a
   private key is stored.

   Keys which are valid for all addresses in a domain typically reside
   in MTAs which should be located in well-protected sites, such as data
   centers.  Various means should be employed for minimizing access to
   private keys, such as non-existence of commands for displaying their
   value, although ultimately memory dumps and the like will probably
   contain the keys.  Due to the unattended nature of MTAs, some
   countermeasures, such as the use of a pass phrase to "unlock" a key,

Fenton                  Expires September 6, 2006              [Page 13]

Internet-Draft            DKIM Threat Analysis                March 2006

   are not practical to use.  Other mechanisms, such as the use of
   dedicated hardware devices which contain the private key and perform
   the cryptographic signature operation, would be very effective in
   denying access to the private key to those without physical access to
   the device.  Such devices would almost certainly make the theft of
   the key visible, so that appropriate action (revocation of the
   corresponding public key) can be taken should that happen.

4.1.2.  Theft of Delegated Private Key

   There are several circumstances where a domain owner will want to
   delegate the ability to sign messages for the domain to an individual
   user or a third-party associated with an outsourced activity such as
   a corporate benefits administrator or a marketing campaign.  Since
   these keys may exist on less well-protected devices than the domain's
   own MTAs, they will in many cases be more susceptible to compromise.

   In order to mitigate this exposure, keys used to sign such messages
   can be restricted by the domain owner to be valid for signing
   messages only on behalf of specific addresses in the domain.  This
   maintains protection for the majority of addresses in the domain.

   A related threat is the exploitation of weaknesses in the delegation
   process itself.  Standard precautions need to be used when handling
   delegated keys to minimize their exposure to theft.  In particular,
   the delegate should generate the keypair to be used, and send the
   public key to the domain owner.  This transmission should be signed
   in order to minimize the possibility of an attacker substituting a
   different public key.

4.1.3.  Private Key Recovery via Side-Channel Attack

   Side-channel attacks are techniques whereby the private key is
   recovered by observing characteristics of the signing process, such
   as the time required, power consumed, and other externally-observable
   factors.  It requires both the ability to submit messages for signing
   as well as the ability to accurately measure observable factor being

   An MTA probably has are enough variables (system load, clock
   resolution, queuing delays, co-location with other equipment, etc.)
   to prevent useful observable factors from being measured accurately
   enough to be useful for a side-channel attack.  Furthermore, while
   some domains, e.g., consumer ISPs, would allow an attacker to submit
   messages for signature, with many other domains this is difficult.
   Other mechanisms, such as mailing lists hosted by the domain, might
   be paths by which an attacker might submit messages for signature,
   and should also be considered as possible vectors for side-channel

Fenton                  Expires September 6, 2006              [Page 14]

Internet-Draft            DKIM Threat Analysis                March 2006


4.1.4.  Chosen Message Replay

   Chosen Message Replay (CMR) refers to the scenario where the attacker
   creates a message and obtains a signature for it by sending it
   through an MTA authorized by the originating domain to him/herself or
   an accomplice.  They then "replay" the signed message by sending it,
   using different envelope addresses, to a (typically large) number of
   other recipients.

   Due to the requirement to get an attacker-generated message signed,
   Chosen Message Replay would most commonly be experienced by consumer
   ISPs or others offering email accounts to clients, particularly where
   there is little or no accountability to the account holder (the
   attacker in this case).  One approach to this problem is for the
   domain to only sign email for clients that have passed a vetting
   process to provide traceability to the message originator in the
   event of abuse.  At present, the low cost of email accounts (zero)
   does not make it practical for any vetting to occur.  It remains to
   be seen whether this will be the model with signed mail as well, or
   whether a higher level of trust will be required to obtain an email

   Revocation of the signature or the associated key is a potential
   countermeasure.  However, the rapid pace at which the message might
   be replayed (especially with an army of "zombie" computers), compared
   with the time required to detect the attack and implement the
   revocation, is likely to be problematic.  A related problem is the
   likelihood that domains will use a small number of signing keys for a
   large number of customers, which is beneficial from a caching
   standpoint but is likely to result in a great deal of collateral
   damage (in the form of signature verification failures) should a key
   be revoked suddenly.

   Signature revocation addresses the collateral damage problem at the
   expense of significant scaling requirements.  At the extreme,
   verifiers could be required to check for revocation of each signature
   verified, which would result in very significant transaction rates.
   An alternative, "revocation identifiers", has been proposed which
   would permit revocation on an intermediate level of granularity,
   perhaps on a per-account basis.  Messages containing these
   identifiers would result in a query to a revocation database, which
   might be represented in DNS.

   Further study is needed to determine if the benefits from revocation
   (given the potential speed of a replay attack) outweigh the
   transactional cost of querying a revocation database.

Fenton                  Expires September 6, 2006              [Page 15]

Internet-Draft            DKIM Threat Analysis                March 2006

4.1.5.  Signed Message Replay

   Signed Message Replay (SMR) refers to the retransmission of already-
   signed messages to additional recipients beyond those intended by the
   sender.  The attacker arranges to receive a message from the victim,
   and then retransmits it intact but with different envelope addresses.
   This might be done, for example, to make it look like a legitimate
   sender of messages is sending a large amount of spam.  When
   reputation services are deployed, this could damage the originator's

   A larger number of domains are potential victims of SMR than of CMR,
   because the former does not require the ability for the attacker to
   send messages from the victim domain.  However, the capabilities of
   the attacker are lower.  Unless coupled with another attack such as
   body length limit abuse, it isn't possible for the attacker to use
   this, for example, for advertising.

   Many mailing lists, especially those which do not modify the content
   of the message and signed header fields and hence do not invalidate
   the signature, engage in a form of SMR.  The use of body length
   limits and other mechanisms to enhance the survivability of messages
   effectively enhances the ability to do so.  The only things that
   distinguish this case from undesirable forms of SMR is the intent of
   the replayer, which cannot be determined by the network.

4.1.6.  Denial-of-Service Attack Against Verifier

   While it takes some compute resources to sign and verify a signature,
   it takes negligible compute resources to generate an invalid
   signature.  An attacker could therefore construct a "make work"
   attack against a verifier, by sending a large number of incorrectly-
   signed messages to a given verifier, perhaps with multiple signatures
   each.  The motivation might be to make it too expensive to verify

   While this attack is feasible, it can be greatly mitigated by the
   manner in which the verifier operates.  For example, it might decide
   to accept only a certain number of signatures per message, limit the
   maximum key size it will accept (to prevent outrageously large
   signatures from causing unneeded work), and verify signatures in a
   particular order.  The verifier could also maintain state
   representing the current signature verification failure rate and
   adopt a defensive posture when attacks may be underway.

4.1.7.  Denial-of-Service Attack Against Key Service

   An attacker might also attempt to degrade the availability of an

Fenton                  Expires September 6, 2006              [Page 16]

Internet-Draft            DKIM Threat Analysis                March 2006

   originator's key service, in order to cause that originator's
   messages to be unverifiable.  One way to do this might be to quickly
   send a large number of messages with signatures which reference a
   particular key, thereby creating a heavy load on the key server.
   Other types of DoS attacks on the key server or the network
   infrastructure serving it are also possible.

   The best defense against this attack is to provide redundant key
   servers, preferably on geographically-separate parts of the Internet.
   Caching also helps a great deal, by decreasing the load on
   authoritative key servers when there are many simultaneous key
   requests.  The use of a key service protocol which minimizes the
   transactional cost of key lookups is also beneficial.  It is noted
   that the Domain Name System has all these characteristics.

4.1.8.  Canonicalization Abuse

   Canonicalization algorithms represent a tradeoff between the survival
   of the validity of a message signature and the desire not to allow
   the message to be altered inappropriately.  In the past,
   canonicalization algorithms have been proposed which would have
   permitted attackers, in some cases, to alter the meaning of a

   Message signatures which support multiple canonicalization algorithms
   give the signer the ability to decide the relative importance of
   signature survivability and immutability of the signed content.  If
   an unexpected vulnerability appears in a canonicalization algorithm
   in general use, new algorithms can be deployed, although it will be a
   slow process because the signer can never be sure which algorithm(s)
   the verifier supports.  For this reason, canonicalization algorithms,
   like cryptographic algorithms, should undergo a wide and careful
   review process.

4.1.9.  Body Length Limit Abuse

   A body length limit is an optional indication from the signer how
   much content has been signed.  The verifier can either ignore the
   limit, verify the specified portion of the message, or truncate the
   message to the specified portion and verify it.  The motivation for
   this feature is the behavior of many mailing lists which add a
   trailer, perhaps identifying the list, at the end of messages.

   When body length limits are used, there is the potential for an
   attacker to add content to the message.  It has been shown that this
   content, although at the end, can cover desirable content, especially
   in the case of HTML messages.

Fenton                  Expires September 6, 2006              [Page 17]

Internet-Draft            DKIM Threat Analysis                March 2006

   If the body length isn't specified, or if the verifier decides to
   ignore the limit, body length limits are moot.  If the verifier or
   recipient truncates the message at the signed content, there is no
   opportunity for the attacker to add anything.

   If the verifier observes body length limits when present, there is
   the potential that an attacker can make undesired content visible to
   the recipient.  The size of the appended content makes little
   difference, because it can simply be a URL reference pointing to the
   actual content.  Recipients need to use means to, at a minimum,
   identify the unsigned content in the message.

4.1.10.  Use of Revoked Key

   The benefits obtained by caching of key records opens the possibility
   that keys which have been revoked may be used for some period of time
   after their revocation.  The best examples of this occur when a
   holder of a key delegated by the domain administrator must be
   unexpectedly deauthorized from sending mail on behalf of one or more
   addresses in the domain.

   The caching of key records is normally short-lived, on the order of
   hours to days.  In many cases, this threat can be mitigated simply by
   setting a short time-to-live for keys not under the domain
   administrator's direct control (assuming, of course, that control of
   the time-to-live value may be specified for each record, as it can
   with DNS).  In some cases, such as the recovery following a stolen
   private key belonging to one of the domain's MTAs, the possibility of
   theft and the time required to revoke the key authorization must be
   considered when choosing a TTL.  The chosen TTL must be long enough
   to mitigate denial-of-service attacks and provide reasonable
   transaction efficiency, and no longer.

4.1.11.  Compromise of Key Server

   Rather than by attempting to obtain a private key, an attacker might
   instead focus efforts on the server used to publish public keys for a
   domain.  As in the key theft case, the motive might be to allow the
   attacker to sign messages on behalf of the domain.  This attack
   provides the attacker with the additional capability to remove
   legitimate keys from publication, thereby denying the domain the
   ability for the signatures on its mail to verify correctly.

   The host which is the primary key server, such as a DNS master server
   for the domain, might be compromised.  Another approach might be to
   change the delegation of key servers at the next higher domain level.

   This attack can be mitigated somewhat by independent monitoring to

Fenton                  Expires September 6, 2006              [Page 18]

Internet-Draft            DKIM Threat Analysis                March 2006

   audit the key service.  Such auditing of the key service should occur
   by means of zone transfers rather than queries to the zone's primary
   server, so that the addition of records to the zone can be detected.

4.1.12.  Falsification of Key Service Replies

   Replies from the key service may also be spoofed by a suitably
   positioned attacker.  For DNS, one such way to do this is "cache
   poisoning", in which the attacker provides unnecessary (and
   incorrect) additional information in DNS replies, which is cached.

   DNSSEC [RFC4033] is the preferred means of mitigating this threat,
   but the current uptake rate for DNSSEC is slow enough that one would
   not like to create a dependency on its deployment.  Fortunately, the
   vulnerabilities created by this attack are both localized and of
   limited duration, although records with relatively long TTL may be
   created with cache poisoning.

4.1.13.  Publication of Malformed Key Records and/or Signatures

   In this attack, the attacker publishes suitably crafted key records
   or sends mail with intentionally malformed signatures, in an attempt
   to confuse the verifier and perhaps disable verification altogether.
   This attack is really a characteristic of an implementation
   vulnerability, a buffer overflow or lack of bounds checking, for
   example, rather than a vulnerability of the signature mechanism
   itself.  This threat is best mitigated by careful implementation and
   creation of test suites that challenge the verification process.

4.1.14.  Cryptographic Weaknesses in Signature Generation

   The cryptographic algorithms used to generate mail signatures,
   specifically the hash algorithm and the public-key encryption/
   decryption operations, may over time be subject to mathematical
   techniques that degrade their security.  At this writing, the SHA-1
   hash algorithm is the subject of extensive mathematical analysis
   which has considerably lowered the time required to create two
   messages with the same hash value.  This trend can be expected to

   The message signature system must be designed to support multiple
   signature and hash algorithms, and the signing domain must be able to
   specify which algorithms it uses to sign messages.  The choice of
   algorithms must be published in key records, rather than in the
   signature itself, to ensure that an attacker is not able to create
   signatures using algorithms weaker than the domain wishes to permit.

   Due to the fact that the signer and verifier of email do not, in

Fenton                  Expires September 6, 2006              [Page 19]

Internet-Draft            DKIM Threat Analysis                March 2006

   general, communicate directly, negotiation of the algorithms used for
   signing cannot occur.  In other words, a signer has no way of knowing
   which algorithm(s) a verifier supports, nor (due to mail forwarding)
   where the verifier is.  For this reason, it is expected that once
   message signing is widely deployed, algorithm change will occur
   slowly, and legacy algorithms will need to be supported for a
   considerable period.  Algorithms used for message signatures
   therefore need to be secure against expected cryptographic
   developments several years into the future.

4.1.15.  Display Name Abuse

   Message signatures only relate to the address-specification portion
   of an email address, which some MUAs only display (or some recipients
   only pay attention to) the display name portion of the address.  This
   inconsistency leads to an attack where the attacker uses an From
   header field such as:

   From: "Dudley DoRight" <>

   In this example, the attacker,, 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 bring the attacker to account for the use of another's display

   This is an attack which must be dealt with in the recipient's MUA.
   One approach is to require that the signer's address specification
   (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
   which 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.

Fenton                  Expires September 6, 2006              [Page 20]

Internet-Draft            DKIM Threat Analysis                March 2006

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 which are valid for any domain
   below them in the DNS hierarchy.  In other words, mail from the
   domain could be signed using keys published by,, 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.

Fenton                  Expires September 6, 2006              [Page 21]

Internet-Draft            DKIM Threat Analysis                March 2006

4.2.  Attacks Against Message Signing Policy

           Summary of postulated attacks against signing policy:

   | Attack Name                                 | Impact | Likelihood |
   | Look-alike domain names                     |  High  |    High    |
   | Internationalized domain name abuse         |  High  |   Medium   |
   | Denial-of-service attack against signing    | Medium |   Medium   |
   | policy                                      |        |            |
   | Use of multiple From addresses              |   Low  |   Medium   |
   | Abuse of third-party signatures             | Medium |    High    |
   | Falsification of Sender Signing Policy      | Medium |   Medium   |
   | replies                                     |        |            |

4.2.1.  Look-Alike Domain Names

   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
   with a signing policy.  For instance, "" might be replaced
   by "".  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, 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 with, 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 which are
   visually indistinguishable from other, possibly high-value domains.
   This is discussed in detail in Unicode TR 36 [UTR36].  Surveillance
   of domain registration records may point out some of these, but there

Fenton                  Expires September 6, 2006              [Page 22]

Internet-Draft            DKIM Threat Analysis                March 2006

   are many such similarities.  As in the look-alike domain attack
   above, this technique may also be used to circumvent sender signing
   policy of other domains.

4.2.3.  Denial-of-Service Attack Against Signing Policy

   Just as the publication of public keys by a domain can be impacted by
   an attacker, so can the publication of Sender Signing Policy (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 policy
   is "we don't sign everything", which means that SSP, in effect, fails

   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 policy 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 Policy is based on the
   From address, so if addresses from multiple domains are in the From
   address, the question arises which signing policy 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

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.

Fenton                  Expires September 6, 2006              [Page 23]

Internet-Draft            DKIM Threat Analysis                March 2006

   However, the restrictions placed on a domain by publishing "no third-
   party" signing practices effectively disallows many existing uses of
   e-mail.  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 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

   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

Fenton                  Expires September 6, 2006              [Page 24]

Internet-Draft            DKIM Threat Analysis                March 2006

   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

   This section is an attempt to capture a set of requirements for DKIM
   from 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(s) used by the signing domain must be
      specified independently of the message being verified, such as in
      the key record.

      The algorithm(s) used for message signatures need to be secure
      against expected cryptographic developments several years in the

6.  IANA Considerations

   This document defines no items requiring IANA assignment.

7.  Security Considerations

   This document describes the security threat environment in which
   DomainKeys Identified Mail (DKIM) is expected to provide some
   benefit, and presents a number of attacks relevant to its deployment.

8.  Informative References

              Allman, E., "DKIM Sender Signing Policy",
              draft-allman-dkim-ssp-01 (work in progress), October 2005.

              Allman, E., "DomainKeys Identified Mail Signatures
              (DKIM)", draft-ietf-dkim-base-00 (work in progress),

Fenton                  Expires September 6, 2006              [Page 25]

Internet-Draft            DKIM Threat Analysis                March 2006

              February 2006.

   [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.

              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, "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

   Administrative Unit (AU) - The portion of the path of an email
   message that is under common administration.  The originator and
   recipient typically develop trust relationships with the
   administrative units that send and receive their email, respectively,
   to perform the signing and verification of their messages.

   Origin address - The address on an email message, typically the RFC
   2822 From:  address, which is associated with the alleged author of
   the message and is displayed by the recipient's MUA as the source of
   the message.

Appendix B.  Acknowledgements

   The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony
   Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon
   Callas, Stephen Farrell, Doug Otis, Frank Ellermann, and numerous
   others on the ietf-dkim mailing list for valuable suggestions and
   constructive criticism of earlier versions of this draft.

Fenton                  Expires September 6, 2006              [Page 26]

Internet-Draft            DKIM Threat Analysis                March 2006

Appendix C.  Edit History

   Changes since draft-fenton-dkim-threats-00 draft:

   o  Changed beginning of introduction to make it consistent with -base

   o  Clarified reasons for focus on externally-located bad actors.

   o  Elaborated on reasons for effectiveness of address book attacks.

   o  Described attack time windows with respect to replay attacks.

   o  Added discussion of attacks using look-alike domains.

   o  Added section on key management attacks.

   Changes since draft-fenton-dkim-threats-01 draft:

   o  Reorganized description of bad actors.

   o  Greatly expanded description of attacks against DKIM and SSP.

   o  Added "derived requirements" section.

   Changes since draft-fenton-dkim-threats-02 draft:

   o  Added description of reflection attack, verification probe attack,
      and abuse of third-party signatures.

   o  Expanded description of key delegation attacks and look-alike
      domain names.

   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

   o  Added description of falsification of SSP replies.

   o  Added section on other threats and description of packet
      amplification attacks via DNS.

Fenton                  Expires September 6, 2006              [Page 27]

Internet-Draft            DKIM Threat Analysis                March 2006

Author's Address

   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-24/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706

   Phone:  +1 408 526 5914

Fenton                  Expires September 6, 2006              [Page 28]

Internet-Draft            DKIM Threat Analysis                March 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Fenton                  Expires September 6, 2006              [Page 29]