doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc4686.txt b/doc/rfc/rfc4686.txt
new file mode 100644
index 0000000..fb9ee5e
--- /dev/null
+++ b/doc/rfc/rfc4686.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          J. Fenton
+Request for Comments: 4686                           Cisco Systems, Inc.
+Category: Informational                                   September 2006
+
+
+    Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   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
+   attacks.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                      [Page 1]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology and Model ......................................3
+      1.2. Document Structure .........................................5
+   2. The Bad Actors ..................................................6
+      2.1. Characteristics ............................................6
+      2.2. Capabilities ...............................................6
+      2.3. Location ...................................................8
+           2.3.1. Externally-Located Bad Actors .......................8
+           2.3.2. Within Claimed Originator's Administrative Unit .....8
+           2.3.3. Within Recipient's Administrative Unit ..............9
+   3. Representative Bad Acts .........................................9
+      3.1. Use of Arbitrary Identities ................................9
+      3.2. Use of Specific Identities ................................10
+           3.2.1. Exploitation of Social Relationships ...............10
+           3.2.2. Identity-Related Fraud .............................11
+           3.2.3. Reputation Attacks .................................11
+           3.2.4. Reflection Attacks .................................11
+   4. Attacks on Message Signing .....................................12
+      4.1. Attacks against Message Signatures ........................12
+           4.1.1. Theft of Private Key for Domain ....................13
+           4.1.2. Theft of Delegated Private Key .....................13
+           4.1.3. Private Key Recovery via Side Channel Attack .......14
+           4.1.4. Chosen Message Replay ..............................14
+           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 .......17
+           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 ..20
+           4.1.15. Display Name Abuse ................................21
+           4.1.16. Compromised System within Originator's Network ....21
+           4.1.17. Verification Probe Attack .........................21
+           4.1.18. Key Publication by Higher-Level Domain ............22
+      4.2. Attacks against Message Signing Practices .................23
+           4.2.1. Look-Alike Domain Names ............................23
+           4.2.2. Internationalized Domain Name Abuse ................23
+           4.2.3. Denial-of-Service Attack against Signing
+                  Practices ..........................................24
+           4.2.4. Use of Multiple From Addresses .....................24
+           4.2.5. Abuse of Third-Party Signatures ....................24
+           4.2.6. Falsification of Sender Signing Practices Replies ..25
+
+
+
+Fenton                       Informational                      [Page 2]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+      4.3. Other Attacks .............................................25
+           4.3.1. Packet Amplification Attacks via DNS ...............25
+   5. Derived Requirements ...........................................26
+   6. Security Considerations ........................................26
+   7. Informative References .........................................27
+   Appendix A. Acknowledgements ......................................28
+
+1.  Introduction
+
+   The DomainKeys Identified Mail (DKIM) protocol is being specified by
+   the IETF DKIM Working Group.  The DKIM protocol 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.  This document
+   addresses threats relative to two works in progress by the DKIM
+   Working Group, the DKIM signature specification [DKIM-BASE] and DKIM
+   Sender Signing Practices [DKIM-SSP].
+
+   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 the IETF DKIM Working Group
+   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
+
+   An administrative unit (AU) is 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.
+
+   The origin address is the address on an email message, typically the
+   RFC 2822 From: address, which is associated with the alleged author
+   of the message and is displayed by the recipient's Mail User Agent
+   (MUA) as the source of the message.
+
+
+
+
+
+Fenton                       Informational                      [Page 3]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   The following diagram illustrates a typical usage flowchart for DKIM:
+
+                      +---------------------------------+
+                      |       SIGNATURE CREATION        |
+                      |  (Originating or Relaying AU)   |
+                      |                                 |
+                      |   Sign (Message, Domain, Key)   |
+                      |                                 |
+                      +---------------------------------+
+                                       | - Message (Domain, Key)
+                                       |
+                                   [Internet]
+                                       |
+                                       V
+                      +---------------------------------+
+     +-----------+    |     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 (body and selected header
+   fields) 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 use.
+
+   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
+   necessarily to be expected.
+
+
+
+
+Fenton                       Informational                      [Page 4]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+1.2.  Document Structure
+
+   The remainder of this document describes the problems that DKIM might
+   be expected to address, and the extent to which it may be successful
+   in so doing.  These are described in terms of the potential bad
+   actors, their capabilities and location in the network, and the bad
+   acts 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:
+
+   Impact:
+
+      High:  Affects the verification of messages from an entire domain
+         or multiple domains
+
+      Medium:  Affects the verification of messages from specific users,
+         Mail Transfer Agents (MTAs), and/or bounded time periods
+
+      Low:  Affects the verification of isolated individual messages
+         only
+
+   Likelihood:
+
+      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
+
+
+
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                      [Page 5]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+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
+   capabilities.
+
+   At the low end of the spectrum are bad actors who may simply send
+   email, perhaps using one of many commercially available tools, that
+   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, including DNS cache-poisoning attacks
+   and IP routing attacks.
+
+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
+       impersonate
+
+   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 Message Submission Agents (MSAs) at
+       multiple locations in the Internet
+
+
+
+
+Fenton                       Informational                      [Page 6]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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 that might be used to attempt a denial-of-service
+       attack
+
+   5.  Resend messages that may have been previously signed by the
+       domain
+
+   6.  Transmit messages using any envelope information desired
+
+   7.  Act as an authorized submitter for messages from a compromised
+       computer
+
+   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
+       domain.
+
+   2.  Limited influence over portions of DNS using mechanisms such as
+       cache poisoning.  This might be used to influence message routing
+       or to falsify advertisements of DNS-based keys or signing
+       practices.
+
+   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
+       attacks.
+
+   4.  Ability to eavesdrop on 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 author and
+   recipient, if that attack is useful.
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                      [Page 7]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+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").
+
+   It should also be noted that with the use of "zombies" and other
+   proxies, externally-located bad actors may gain some of the
+   capabilities of being located within the claimed originator's or
+   recipient's administrative unit.  This emphasizes the importance of
+   appropriate security measures, such as authenticated submission of
+   messages, even within administrative units.
+
+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
+   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
+   DKIM.
+
+   External bad actors are usually attempting to exploit the "any to
+   any" nature of email that 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 that
+   legitimately send or resend 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 Message Submission Agents
+   that are configured to authenticate the author.
+
+
+
+
+Fenton                       Informational                      [Page 8]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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 that 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
+   successfully.
+
+   As in the originator case, these bad actors can be dealt with by
+   controlling the submission of messages within the administrative
+   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 that 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 that aim to
+   obscure the identity of the actual author.  In some cases, the actual
+   sender might be the bad actor, or in other cases might be a third-
+   party under the control of the bad actor (e.g., a compromised
+   computer).
+
+   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
+
+
+
+Fenton                       Informational                      [Page 9]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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 that 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 "examp1e.com" (note the "one"
+   between the p and e), they might be able to convince some recipients
+   that a message from admin@examp1e.com is really from
+   admin@example.com.  Similar types of attacks using internationalized
+   domain names have been hypothesized where it could be very difficult
+   to see character differences in popular typefaces.  Similarly, if
+   example2.com was controlled by a bad actor, the bad actor could sign
+   messages from bigbank.example2.com, 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.
+
+   DKIM is effective against the use of specific identities only when
+   there is an expectation that such messages will, in fact, be signed.
+   The primary means for establishing this is the use of Sender Signing
+   Practices (SSP), which will be specified by the IETF DKIM Working
+   Group.
+
+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
+   that mail themselves to addresses in the infected host's address
+   book.  In this case, however, the author's address may not be
+   falsified, so DKIM would not be effective in defending against this
+   act.
+
+
+
+
+Fenton                       Informational                     [Page 10]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   It is also possible for address books to be harvested and used by an
+   attacker to post 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 author.
+
+   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.
+
+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
+   reliable.
+
+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 (RFC
+   2821 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 RFC2821.mailfrom
+   return address on messages, either directly (noting that the mailfrom
+
+
+
+Fenton                       Informational                     [Page 11]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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 origin address.  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 Practices or SSP) can be expected to be the
+   target of attacks.
+
+4.1.  Attacks against Message Signatures
+
+   The following is a 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 attack|  High  |     Low    |
+   | 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 service|  High  |   Medium   |
+   | 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    |
+   +---------------------------------------------+--------+------------+
+
+
+
+
+Fenton                       Informational                     [Page 12]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+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 that are valid for all addresses in a domain typically reside in
+   MTAs that 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,
+   are not practical to use.  Other mechanisms, such as the use of
+   dedicated hardware devices that contain the private key and perform
+   the cryptographic signature operation, would be very effective in
+   denying export of 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.  This threat can be mitigated through the use of
+   customary precautions against the theft of private keys and the
+   falsification of public keys in transit.  For example, the exposure
+   to theft can be minimized if the delegate generates the keypair to be
+   used, and sends the public key to the domain owner.  The exposure to
+   falsification (substitution of a different public key) can be reduced
+   if this transmission is signed by the delegate and verified by the
+   domain owner.
+
+
+
+
+Fenton                       Informational                     [Page 13]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.1.3.  Private Key Recovery via Side Channel Attack
+
+   All popular digital signature algorithms are subject to a variety of
+   side channel attacks.  The most well-known of these are timing
+   channels [Kocher96], power analysis [Kocher99], and cache timing
+   analysis [Bernstein04].  Most of these attacks require either
+   physical access to the machine or the ability to run processes
+   directly on the target machine.  Defending against these attacks is
+   out of scope for DKIM.
+
+   However, remote timing analysis (at least on local area networks) is
+   known to be feasible [Boneh03], particularly in server-type platforms
+   where the attacker can inject traffic that will immediately be
+   subject to the cryptographic operation in question.  With enough
+   samples, these techniques can be used to extract private keys even in
+   the face of modest amounts of noise in the timing measurements.
+
+   The three commonly proposed countermeasures against timing analysis
+   are:
+
+   1.  Make the operation run in constant time.  This turns out in
+       practice to be rather difficult.
+
+   2.  Make the time independent of the input data.  This can be
+       difficult, but see [Boneh03] for more details.
+
+   3.  Use blinding.  This is generally considered the best current
+       practice countermeasure, and while not proved generally secure is
+       a countermeasure against known timing attacks.  It adds about
+       2-10% to the cost of the operation and is implemented in many
+       common cryptographic libraries.  Unfortunately, Digital Signature
+       Algorithm (DSA) and Elliptic Curve DSA (ECDSA) do not have
+       standard methods though some defenses may exist.
+
+   Note that adding random delays to the operation is only a partial
+   countermeasure.  Because the noise is generally uniformly
+   distributed, a large enough number of samples can be used to average
+   it out and extract an accurate timing signal.
+
+4.1.4.  Chosen Message Replay
+
+   Chosen message replay 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
+   himself/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.
+
+
+
+
+Fenton                       Informational                     [Page 14]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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 solving 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
+   signature.
+
+   A variation on this attack involves the attacker sending a message
+   with the intent of obtaining a signed reply containing their original
+   message.  The reply might come from an innocent user or might be an
+   automatic response such as a "user unknown" bounce message.  In some
+   cases, this signed reply message might accomplish the attacker's
+   objectives if replayed.  This variation on chosen message replay can
+   be mitigated by limiting the extent to which the original content is
+   quoted in automatic replies, and by the use of complementary
+   mechanisms such as egress content filtering.
+
+   Revocation of the signature or the associated key is a potential
+   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                       Informational                     [Page 15]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.1.5.  Signed Message Replay
+
+   Signed message replay refers to the retransmission of already-signed
+   messages to additional recipients beyond those intended by the author
+   or the original poster of the message.  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 author's reputation or that of the author's domain.
+
+   A larger number of domains are potential victims of signed message
+   replay than chosen message replay 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 that do not modify the content
+   of the message and signed header fields and hence do not invalidate
+   the signature, engage in a form of signed message replay.  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 signed
+   message replay 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 computing resources to sign and verify a
+   signature, it takes negligible computing 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 messages.
+
+   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 under way.
+
+
+
+
+
+
+Fenton                       Informational                     [Page 16]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.1.7.  Denial-of-Service Attack against Key Service
+
+   An attacker might also attempt to degrade the availability of an
+   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 that 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 that 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 that would have
+   permitted attackers, in some cases, to alter the meaning of a
+   message.
+
+   Message signatures that 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 of 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 that add a
+   trailer, perhaps identifying the list, at the end of messages.
+
+
+
+
+
+
+Fenton                       Informational                     [Page 17]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   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.
+
+   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.  Receiving MUAs can mitigate this threat by, at a
+   minimum, identifying 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 that 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 (TTL) for keys not under the domain
+   administrator's direct control (assuming, of course, that control of
+   the TTL 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 effort 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.
+
+
+
+
+Fenton                       Informational                     [Page 18]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   In order to limit the ability to sign a message to entities
+   authorized by the owner of a signing domain, a relationship must be
+   established between the signing address and the location from which a
+   public key is obtained to verify the message.  DKIM does this by
+   publishing either the public key or a reference to it within the DNS
+   hierarchy of the signing domain.  The verifier derives the location
+   from which to retrieve the public key from the signing address or
+   domain.  The security of the verification process is therefore
+   dependent on the security of the DNS hierarchy for the signing
+   domain.
+
+   An attacker might successfully compromise the host that is the
+   primary key server for the signing domain, such as the domain's DNS
+   master server.  Another approach might be to compromise a higher-
+   level DNS server and change the delegation of name servers for the
+   signing domain to others under the control of the attacker.
+
+   This attack can be mitigated somewhat by independent monitoring to
+   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.  In the case of a
+   cache poisoning attack, the vulnerabilities created by this attack
+   are both localized and of limited duration, although records with
+   relatively long TTL may persist beyond the attack itself.
+
+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.
+
+
+
+
+
+Fenton                       Informational                     [Page 19]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.1.14.  Cryptographic Weaknesses in Signature Generation
+
+   The cryptographic algorithms used to generate mail signatures,
+   specifically the hash algorithm and digital signature generation and
+   verification 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 that
+   has considerably lowered the time required to create two messages
+   with the same hash value.  This trend can be expected to continue.
+
+   One consequence of a weakness in the hash algorithm is a hash
+   collision attack.  Hash collision attacks in message signing systems
+   involve the same person creating two different messages that have the
+   same hash value, where only one of the two messages would normally be
+   signed.  The attack is based on the second message inheriting the
+   signature of the first.  For DKIM, this means that a sender might
+   create a "good" message and a "bad" message, where some filter at the
+   signing party's site would sign the good message but not the bad
+   message.  The attacker gets the good message signed, and then
+   incorporates that signature in the bad message.  This scenario is not
+   common, but could happen, for example, at a site that does content
+   analysis on messages before signing them.
+
+   Current known attacks against SHA-1 make this attack extremely
+   difficult to mount, but as attacks improve and computing power
+   becomes more readily available, such an attack could become
+   achievable.
+
+   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, and not only in the
+   signature itself, to ensure that an attacker is not able to create
+   signatures using algorithms weaker than the domain wishes to permit.
+
+   Because the signer and verifier of email do not, in 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 or (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.
+
+
+
+
+
+
+Fenton                       Informational                     [Page 20]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.1.15.  Display Name Abuse
+
+   Message signatures only relate to the address-specification portion
+   of an email address, while 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 a From
+   header field such as:
+
+   From: "Dudley DoRight" <whiplash@example.org>
+
+   In this example, the attacker, whiplash@example.org, can sign the
+   message and still convince some recipients that the message is from
+   Dudley DoRight, who is presumably a trusted individual.  Coupled with
+   the use of a throw-away domain or email address, it may be difficult
+   to hold the attacker accountable for using another's display name.
+
+   This is an attack that must be dealt with in the recipient's MUA.
+   One approach is to require that the signer's address specification
+   (and not just the display name) be visible to the recipient.
+
+4.1.16.  Compromised System within Originator's Network
+
+   In many cases, MTAs may be configured to accept and sign messages
+   that originate within the topological boundaries of the originator's
+   network (i.e., within a firewall).  The increasing use of compromised
+   systems to send email presents a problem for such policies, because
+   the attacker, using a compromised system as a proxy, can generate
+   signed mail at will.
+
+   Several approaches exist for mitigating this attack.  The use of
+   authenticated submission, even within the network boundaries, can be
+   used to limit the addresses for which the attacker may obtain a
+   signature.  It may also help locate the compromised system that is
+   the source of the messages more quickly.  Content analysis of
+   outbound mail to identify undesirable and malicious content, as well
+   as monitoring of the volume of messages being sent by users, may also
+   prevent arbitrary messages from being signed and sent.
+
+4.1.17.  Verification Probe Attack
+
+   As noted above, bad actors (attackers) can sign messages on behalf of
+   domains they control.  Since they may also control the key service
+   (e.g., the authoritative DNS name servers for the _domainkey
+   subdomain), it is possible for them to observe public key lookups,
+   and their source, when messages are verified.
+
+
+
+
+
+
+Fenton                       Informational                     [Page 21]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   One such attack, which we will refer to as a "verification probe", is
+   to send a message with a DKIM signature to each of many addresses in
+   a mailing list.  The messages need not contain valid signatures, and
+   each instance of the message would typically use a different
+   selector.  The attacker could then monitor key service requests and
+   determine which selectors had been accessed, and correspondingly
+   which addressees used DKIM verification.  This could be used to
+   target future mailings at recipients who do not use DKIM
+   verification, on the premise that these addressees are more likely to
+   act on the message contents.
+
+4.1.18.  Key Publication by Higher-Level Domain
+
+   In order to support the ability of a domain to sign for subdomains
+   under its administrative control, DKIM permits the domain of a
+   signature (d= tag) to be any higher-level domain than the signature's
+   address (i= or equivalent).  However, since there is no mechanism for
+   determining common administrative control of a subdomain, it is
+   possible for a parent to publish keys that are valid for any domain
+   below them in the DNS hierarchy.  In other words, mail from the
+   domain example.anytown.ny.us could be signed using keys published by
+   anytown.ny.us, ny.us, or us, in addition to the domain itself.
+
+   Operation of a domain always requires a trust relationship with
+   higher-level domains.  Higher-level domains already have ultimate
+   power over their subdomains:  they could change the name server
+   delegation for the domain or disenfranchise it entirely.  So it is
+   unlikely that a higher-level domain would intentionally compromise a
+   subdomain in this manner.  However, if higher-level domains send mail
+   on their own behalf, they may wish to publish keys at their own
+   level.  Higher-level domains must employ special care in the
+   delegation of keys they publish to ensure that any of their
+   subdomains are not compromised by misuse of such keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                     [Page 22]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+4.2.  Attacks against Message Signing Practices
+
+   The following is a summary of postulated attacks against signing
+   practices:
+
+   +---------------------------------------------+--------+------------+
+   | Attack Name                                 | Impact | Likelihood |
+   +---------------------------------------------+--------+------------+
+   | Look-alike domain names                     |  High  |    High    |
+   | Internationalized domain name abuse         |  High  |    High    |
+   | Denial-of-service attack against signing    | Medium |   Medium   |
+   | practices                                   |        |            |
+   | Use of multiple From addresses              |   Low  |   Medium   |
+   | Abuse of third-party signatures             | Medium |    High    |
+   | Falsification of Sender Signing Practices   | Medium |   Medium   |
+   | replies                                     |        |            |
+   +---------------------------------------------+--------+------------+
+
+4.2.1.  Look-Alike Domain Names
+
+   Attackers may attempt to circumvent signing practices of a domain by
+   using a domain name that is close to, but not the same as, the domain
+   with signing practices.  For instance, "example.com" might be
+   replaced by "examp1e.com".  If the message is not to be signed, DKIM
+   does not require that the domain used actually exist (although other
+   mechanisms may make this a requirement).  Services exist to monitor
+   domain registrations to identify potential domain name abuse, but
+   naturally do not identify the use of unregistered domain names.
+
+   A related attack is possible when the MUA does not render the domain
+   name in an easily recognizable format.  If, for example, a Chinese
+   domain name is rendered in "punycode" as xn--cjsp26b3obxw7f.com, the
+   unfamiliarity of that representation may enable other domains to more
+   easily be mis-recognized as the expected domain.
+
+   Users that are unfamiliar with internet naming conventions may also
+   mis-recognize certain names.  For example, users may confuse
+   online.example.com with online-example.com, the latter of which may
+   have been registered by an attacker.
+
+4.2.2.  Internationalized Domain Name Abuse
+
+   Internationalized domain names present a special case of the look-
+   alike domain name attack described above.  Due to similarities in the
+   appearance of many Unicode characters, domains (particularly those
+   drawing characters from different groups) may be created that are
+   visually indistinguishable from other, possibly high-value domains.
+   This is discussed in detail in Unicode Technical Report 36 [UTR36].
+
+
+
+Fenton                       Informational                     [Page 23]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   Surveillance of domain registration records may point out some of
+   these, but there are many such similarities.  As in the look-alike
+   domain attack above, this technique may also be used to circumvent
+   sender signing practices of other domains.
+
+4.2.3.  Denial-of-Service Attack against Signing Practices
+
+   Just as the publication of public keys by a domain can be impacted by
+   an attacker, so can the publication of Sender Signing Practices (SSP)
+   by a domain.  In the case of SSP, the transmission of large amounts
+   of unsigned mail purporting to come from the domain can result in a
+   heavy transaction load requesting the SSP record.  More general DoS
+   attacks against the servers providing the SSP records are possible as
+   well.  This is of particular concern since the default signing
+   practices are "we don't sign everything", which means that SSP
+   failures result in the verifier's failure to heed more stringent
+   signing practices.
+
+   As with defense against DoS attacks for key servers, the best defense
+   against this attack is to provide redundant servers, preferably on
+   geographically-separate parts of the Internet.  Caching again helps a
+   great deal, and signing practices should rarely change, so TTL values
+   can be relatively large.
+
+4.2.4.  Use of Multiple From Addresses
+
+   Although this usage is never seen by most recipients, RFC 2822
+   [RFC2822] permits the From address to contain multiple address
+   specifications.  The lookup of Sender Signing Practices is based on
+   the From address, so if addresses from multiple domains are in the
+   From address, the question arises which signing practices to use.  A
+   rule (say, "use the first address") could be specified, but then an
+   attacker could put a throwaway address prior to that of a high-value
+   domain.  It is also possible for SSP to look at all addresses, and
+   choose the most restrictive rule.  This is an area in need of further
+   study.
+
+4.2.5.  Abuse of Third-Party Signatures
+
+   In a number of situations, including mailing lists, event
+   invitations, and "send this article to a friend" services, the DKIM
+   signature on a message may not come from the originating address
+   domain.  For this reason, "third-party" signatures, those attached by
+   the mailing list, invitation service, or news service, frequently
+   need to be regarded as having some validity.  Since this effectively
+   makes it possible for any domain to sign any message, a sending
+
+
+
+
+
+Fenton                       Informational                     [Page 24]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   domain may publish sender signing practices stating that it does not
+   use such services, and accordingly that verifiers should view such
+   signatures with suspicion.
+
+   However, the restrictions placed on a domain by publishing "no
+   third-party" signing practices effectively disallows many existing
+   uses of email.  For the majority of domains that are unable to adopt
+   these practices, an attacker may with some degree of success sign
+   messages purporting to come from the domain.  For this reason,
+   accreditation and reputation services, as well as locally-maintained
+   whitelists and blacklists, will need to play a significant role in
+   evaluating messages that have been signed by third parties.
+
+4.2.6.  Falsification of Sender Signing Practices Replies
+
+   In an analogous manner to the falsification of key service replies
+   described in Section 4.1.12, replies to sender signing practices
+   queries can also be falsified.  One such attack would be to weaken
+   the signing practices to make unsigned messages allegedly from a
+   given domain appear less suspicious.  Another attack on a victim
+   domain that is not signing messages could attempt to make the
+   domain's messages look more suspicious, in order to interfere with
+   the victim's ability to send mail.
+
+   As with the falsification of key service replies, DNSSEC is the
+   preferred means of mitigating this attack.  Even in the absence of
+   DNSSEC, vulnerabilities due to cache poisoning are localized.
+
+4.3.  Other Attacks
+
+   This section describes attacks against other Internet infrastructure
+   that are enabled by deployment of DKIM.  A summary of these
+   postulated attacks is as follows:
+
+      +--------------------------------------+--------+------------+
+      | Attack Name                          | Impact | Likelihood |
+      +--------------------------------------+--------+------------+
+      | Packet amplification attacks via DNS |   N/A  |   Medium   |
+      +--------------------------------------+--------+------------+
+
+4.3.1.  Packet Amplification Attacks via DNS
+
+   Recently, there has been an increase in denial-of-service attacks
+   involving the transmission of spoofed UDP DNS requests to openly-
+   accessible domain name servers [US-CERT-DNS].  To the extent that the
+   response from the name server is larger than the request, the name
+   server functions as an amplifier for such an attack.
+
+
+
+
+Fenton                       Informational                     [Page 25]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+   DKIM contributes indirectly to this attack by requiring the
+   publication of fairly large DNS records for distributing public keys.
+   The names of these records are also well known, since the record
+   names can be determined by examining properly-signed messages.  This
+   attack does not have an impact on DKIM itself.  DKIM, however, is not
+   the only application that uses large DNS records, and a DNS-based
+   solution to this problem will likely be required.
+
+5.  Derived Requirements
+
+   This section lists requirements for DKIM not explicitly stated in the
+   above discussion.  These requirements include:
+
+      The store for key and SSP records must be capable of utilizing
+      multiple geographically-dispersed servers.
+
+      Key and SSP records must be cacheable, either by the verifier
+      requesting them or by other infrastructure.
+
+      The cache time-to-live for key records must be specifiable on a
+      per-record basis.
+
+      The signature algorithm identifier in the message must be one of
+      the ones listed in a key record for the identified domain.
+
+      The algorithm(s) used for message signatures need to be secure
+      against expected cryptographic developments several years in the
+      future.
+
+6.  Security Considerations
+
+   This document describes the security threat environment in which
+   DomainKeys Identified Mail (DKIM) is expected to provide some
+   benefit, and it presents a number of attacks relevant to its
+   deployment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                     [Page 26]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+7.  Informative References
+
+   [Bernstein04]  Bernstein, D., "Cache Timing Attacks on AES",
+                  April 2004.
+
+   [Boneh03]      Boneh, D. and D. Brumley, "Remote Timing Attacks are
+                  Practical", Proc. 12th USENIX Security Symposium,
+                  2003.
+
+   [DKIM-BASE]    Allman, E., "DomainKeys Identified Mail (DKIM)
+                  Signatures", Work in Progress, August 2006.
+
+   [DKIM-SSP]     Allman, E., "DKIM Sender Signing Practices", Work in
+                  Progress, August 2006.
+
+   [Kocher96]     Kocher, P., "Timing Attacks on Implementations of
+                  Diffie-Hellman, RSA, and other Cryptosystems",
+                  Advances in Cryptology, pages 104-113, 1996.
+
+   [Kocher99]     Kocher, P., Joffe, J., and B. Yun, "Differential Power
+                  Analysis: Leaking Secrets", Crypto '99, pages 388-397,
+                  1999.
+
+   [RFC1939]      Myers, J. and M. Rose, "Post Office Protocol - Version
+                  3", STD 53, RFC 1939, May 1996.
+
+   [RFC2821]      Klensin, J., "Simple Mail Transfer Protocol",
+                  RFC 2821, April 2001.
+
+   [RFC2822]      Resnick, P., "Internet Message Format", RFC 2822,
+                  April 2001.
+
+   [RFC3501]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                  VERSION 4rev1", RFC 3501, March 2003.
+
+   [RFC4033]      Arends, R., Austein, R., Larson, M., Massey, D., and
+                  S. Rose, "DNS Security Introduction and Requirements",
+                  RFC 4033, March 2005.
+
+   [US-CERT-DNS]  US-CERT, "The Continuing Denial of Service Threat
+                  Posed by DNS Recursion".
+
+   [UTR36]        Davis, M. and M. Suignard, "Unicode Technical Report
+                  #36: Unicode Security Considerations", UTR 36,
+                  July 2005.
+
+
+
+
+
+
+Fenton                       Informational                     [Page 27]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+Appendix A.  Acknowledgements
+
+   The author wishes to thank Phillip Hallam-Baker, Eliot Lear, Tony
+   Finch, Dave Crocker, Barry Leiba, Arvel Hathcock, Eric Allman, Jon
+   Callas, Stephen Farrell, Doug Otis, Frank Ellermann, Eric Rescorla,
+   Paul Hoffman, Hector Santos, and numerous others on the ietf-dkim
+   mailing list for valuable suggestions and constructive criticism of
+   earlier versions of this document.
+
+Author's Address
+
+   Jim Fenton
+   Cisco Systems, Inc.
+   MS SJ-9/2
+   170 W. Tasman Drive
+   San Jose, CA  95134-1706
+   USA
+
+   Phone:  +1 408 526 5914
+   EMail:  fenton@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fenton                       Informational                     [Page 28]
+
+RFC 4686                  DKIM Threat Analysis            September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Fenton                       Informational                     [Page 29]
+