[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-dkim-threats

pre-workgroup                                                    D. Otis
Internet-Draft                                         Trend Micro, NSSG
Expires: April 27, 2006                                 October 24, 2005


 Review of Threats Associated with Email and DomainKeys Identified Mail
                                 (DKIM)
                       draft-otis-dkim-threats-01

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

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 27, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is intended to provide an alternative perspective to
   the document prepared by Jim Fenton for DomainKeys Identified Mail
   (DKIM), although it borrows from his substantial effort.  This review
   removes emphasis on email-address domains, as DKIM allows signatures
   to be independent of the email-address.  This document also considers
   the impact of adding an opaque-identifier and implementing abusive
   message replay abatement.  This document considers threats against
   Internet mail and threats created when employing a signature-based



Otis                     Expires April 27, 2006                 [Page 1]


Internet-Draft             Email+DKIM threats               October 2005


   method for establishing an accountable domain for a message, in
   particular DKIM.  This document also ranks threat levels, modes of
   access, Bad Actors and their capabilities, and possible motivations
   for various attack scenarios.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Scope of DKIM  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Vulnerabilities  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Security Requirements  . . . . . . . . . . . . . . . . . . . .  7
   5.  Ranking of Bad Actors  . . . . . . . . . . . . . . . . . . . .  7
   6.  Capabilities of Bad Actors . . . . . . . . . . . . . . . . . .  8
     6.1   General capabilities . . . . . . . . . . . . . . . . . . .  8
     6.2   Advanced capabilities  . . . . . . . . . . . . . . . . . .  9
   7.  Bad Actor's Points of Access . . . . . . . . . . . . . . . . .  9
     7.1   Bad Actors with Access in the Administrative Unit  . . . . 10
       7.1.1   Access in the Signing-Domain's Administrative Unit . . 10
       7.1.2   Access in the Recipient's Administrative Unit  . . . . 10
     7.2   Bad Actors with External Access  . . . . . . . . . . . . . 11
   8.  Representative Bad Acts  . . . . . . . . . . . . . . . . . . . 11
     8.1   Use of Arbitrary Identities  . . . . . . . . . . . . . . . 11
     8.2   Use of Specific Identities . . . . . . . . . . . . . . . . 12
       8.2.1   Exploitation of Social Relationships . . . . . . . . . 12
       8.2.2   Identity-Related Fraud . . . . . . . . . . . . . . . . 12
       8.2.3   Reputation Attacks . . . . . . . . . . . . . . . . . . 13
   9.  Attacks on Message Signing . . . . . . . . . . . . . . . . . . 13
     9.1   DoS Attack . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.2   Invalid Signatures . . . . . . . . . . . . . . . . . . . . 14
       9.2.1   Canonicalization and Message Normalization . . . . . . 14
     9.3   Body Length Parameter  . . . . . . . . . . . . . . . . . . 14
     9.4   Multiple Signatures  . . . . . . . . . . . . . . . . . . . 14
     9.5   Use of "throw-away" domains  . . . . . . . . . . . . . . . 15
     9.6   Message Replay Attack  . . . . . . . . . . . . . . . . . . 16
   10.   Threats to Delivery  . . . . . . . . . . . . . . . . . . . . 19
   11.   Urgent Response to Threats for Consumer Protections  . . . . 19
     11.1  Restricted Two-Party Communication . . . . . . . . . . . . 19
     11.2  Unrestricted Multiple-Party Communication  . . . . . . . . 20
     11.3  Opportunistic Protection without Domain-wide Policy
           Assertions . . . . . . . . . . . . . . . . . . . . . . . . 20
   12.   Sender Signing Policy  . . . . . . . . . . . . . . . . . . . 21
   13.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 23
   14.   Security Considerations  . . . . . . . . . . . . . . . . . . 23
   15.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
     15.1  Normative References . . . . . . . . . . . . . . . . . . . 23
     15.2  Informative References . . . . . . . . . . . . . . . . . . 24
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
       Intellectual Property and Copyright Statements . . . . . . . . 25



Otis                     Expires April 27, 2006                 [Page 2]


Internet-Draft             Email+DKIM threats               October 2005


1.  Introduction

   Message signing, as exemplified by DomainKeys Identified Mail (DKIM)
   [I-D.allman-dkim-base], is a mechanism to allow an assertion of an
   accountable domain for an email message in transit.  The assertion is
   made by means of a digital signature included within a header.  This
   signature also validates the integrity of selected headers and
   message body content subsequent to signing the message.  This review
   is based upon the work of Jim Fenton, but differs from the
   perspectives regarding the role of an email-address and how replay,
   intra-domain, and DoS attacks may be handled.

   For example, on the DKIM list Jim suggested Sender-ID's path-
   registration and authorization mechanism could be a possible solution
   for a message replay abuse problem.  Unfortunately path-registration
   imposes upon DKIM problematic limitations that would also be very
   disruptive.  Path-registration would also essentially constrain
   mailbox-addresses to specific providers.  In addition, path-
   registration already exposes email-address domain owners to risks
   where path authorization may form the basis for accrual of unfair
   reputations.  Within shared environments, requisite checks to ensure
   email-address domain exclusivity may not have been made.  Such checks
   may be beyond the control of the email-address domain owner, while
   those who are in control remain unaccounted.

   With DKIM, once an accountable domain has been established for a
   message and where the reputation of this domain can be defended, the
   recipient may assess the reputation accrued by the signing-domain
   when deciding whether to accept the message.  This assessment can be
   made using locally-maintained white-lists, and reputation/
   accreditation services.  By applying a signature, the conduct
   permitted by the signing-domain may be accurately accrued to
   establish a valid reputation.  Good conduct is generally maintained
   when there are expectations that future messages will be accepted by
   the recipient from the signing-domain.

2.  Scope of DKIM

   DKIM verifies the association of a specific domain with a message
   using a signature and a public key.  This mechanism also ensures
   selected headers and body content have not been altered since the
   domain's association.  The DKIM effort is not intended to address
   threats associated with message confidentiality nor provide a
   signature suitable for long-term archival.  The scope of DKIM does
   not include semantics for reputation or accreditation services or
   white-listing practices.  DKIM does not provide a direct method to
   verify the identity of a message's author.  DKIM does not provide
   safe mechanisms for authorizing messages associated with different



Otis                     Expires April 27, 2006                 [Page 3]


Internet-Draft             Email+DKIM threats               October 2005


   domain signatures.

3.  Vulnerabilities

   Email is exposed to several security related threats where
   exploitation of a vulnerability often results in substantial damages.
   The following table provides a general overview of vulnerabilities
   and side-effects created by defensive strategies.

+------------------------+---------------------+------------+----------+
|      Vulnerability     |        Damage       | Prevalence | Severity |
+------------------------+---------------------+------------+----------+
|   Unfair Reputations   |   Loss of Service   |     Low    |  Medium  |
| Collateral IP Blocking |   Loss of Service   |     Low    |  Medium  |
|    Filtering Errors    |   Loss of Service   |     Low    |  Medium  |
|       Junk Folder      |   Loss of Service   |     Low    |  Medium  |
|     Delete w/o DSN     |   Loss of Service   |     Low    |  Medium  |
|           DoS          |   Loss of Service   |     Low    |  Medium  |
|      Name Blocking     |   Loss of Service   |     Low    |   High   |
|    Message Spoofing    |    Defrauded User   |   Medium   |   High   |
|        OS Flaws        |  Compromised System |   Medium   |   High   |
|    Stolen Passwords    | Compromised Account |   Medium   |   High   |
|    Malware Payloads    |  Compromised System |    High    |   High   |
|     Timing Analysis    |   Compromised Key   |     Low    |   High   |
|    Network Exploits    | Compromised Privacy |     Low    |   High   |
+------------------------+---------------------+------------+----------+

   An Unfair Reputation regards assessments made against the email-
   address.  These unfair assessments may occur when the email-address
   domain owner is assumed to control the use of their email-address
   domain.  The email-address domain owner may have been obliged to
   authorize the shared systems of a service provider when registering
   prescribed email paths.  Checks are often not performed by an
   unaccounted provider that should ensure only the owner is able to
   utilize their email-address domain.  The public nature of system
   authorizations and prevalence of compromised systems place the email-
   address domain owners at great risk when reputation is based upon the
   email-address.

   Collateral IP Blocking occurs when email systems are being shared and
   many email-address domains utilize common IP addresses.  When one of
   these email-address domains displays abusive conduct, an IP address
   based reputation service may list the IP address and consequently
   block all other email-address domains sharing the IP address.

   Filtering Errors may occur when erroneously relying on a phrase or
   name.  These errors cause the normal processing of the message to be
   altered.  Abusers often spoof many elements within their message



Otis                     Expires April 27, 2006                 [Page 4]


Internet-Draft             Email+DKIM threats               October 2005


   largely to avoid being filtered and this may increase the filtering
   program's sensitivity to otherwise innocent domains.  This type of
   erroneous sensitivity could be viewed as another type of unfair
   reputation.  The message may be "bounced", placed into the "Junk
   Folder", or deleted without the issuing of a Delivery Status
   Notification (DSN).  With the breakdown of email policy enforcement,
   email filtering has become a common alternative to manual, and also
   highly error-prone, deletion of unwanted email.

   The Junk Folder has become the catch-all repository of questionable
   email.  The increased use of multi-level acceptance criteria also
   increases the portion of email placed into the Junk Folder.  Ideally,
   acceptance criteria would provide a binary go/no-go result.  Stronger
   methods of authentication that singularly identify an accountable
   entity may assist in achieving such a goal.

   Deletion without Delivery Status Notification may occur when messages
   have been accepted but then, perhaps through the use of analytical
   heuristics, the message is subsequently identified as unwanted.  In
   the case of message deletion, the provider does not notify the sender
   since even the bounce-address is typically considered invalid.  This
   mode of operation represents a significant reduction in the integrity
   of email delivery.

   Denial of Service attacks may not be intentional, and could be the
   result of unsolicited bulk email.  An enterprise attempting to run
   their own email service may find their networks unable to deal with
   the vast amount of unwanted email.  Being able to reject unwanted
   email early in the exchange is critical when network resources are
   limited.  Signatures carried within the message will not allow for
   early rejection and thus not offer any DoS protection.  Simply
   dropping the connection may result in a storm of retries.  DoS
   protections based upon a domain, rather than an IP address, can be
   achieved by verifying the EHLO name, as it still permits early
   rejection while also avoiding IP address collateral blocking, see
   [I-D.crocker-csv-intro] and [I-D.crocker-csv-csa].  Domain-based
   assessments derived from the EHLO or a domain signature could utilize
   a name based reputation service, commonly referred to as a Right-
   Hand-Side Black-hole List (RHSBL).  Attacks from unlisted domains
   would be retained together with the IP addresses within a local list.

   Name Blocking may result from unfair reputation accrual.  Such
   accrual could occur when feedback is based upon email-address domains
   held accountable for having authorized a system sending abusive
   email.  The damage would be much worse than that caused by collateral
   IP address blocking.  In the case where the IP address is blocked,
   the email-address domain owner would be able to obtain services
   elsewhere as a remedy.  In the case of Name Blocking, there may not



Otis                     Expires April 27, 2006                 [Page 5]


Internet-Draft             Email+DKIM threats               October 2005


   be any remedy, which represents a serious problem.  This problem may
   become endemic with email-address authorization mechanisms.

   Message Spoofing uses many techniques to mislead either the recipient
   or a message filter.  Often the email-address domain appears random,
   or contains several randomly generated domain labels.  Such randomly
   generated labels may still be valid when a DNS wildcard resource
   record is used.  In the case where some level of authentication is
   asserted by the MUA, the domain used to achieve the authentication
   may rely upon the recipient seeing the "pretty-name" rather than the
   actual email-address.  For various reasons, methods that attempt to
   select a visible header to authorize an email-address domain, still
   may permit hidden headers.  The complexity of the selection
   algorithms may also confuse the average recipient, where any
   indication of the message having been authorized may be exploited.

   Operating System flaws will always exist.  Some operating systems
   offer better secured internal communication and program execution.
   Minimizing the exposure of system services to external access reduces
   the number of exploits possible.  Automated system monitoring is
   often needed to react to attack attempts.  Otherwise, the scale of
   deployment may require overwhelming manual monitoring.

   Stolen Passwords are a common problem.  There are many enterprises
   that use protocols that send passwords in the clear.  With the
   prevalence of wireless networks with weak protections, passwords sent
   in the clear should be considered the same as publishing them.  In
   addition, many of the programs that compromise systems also do
   keyboard and paste buffer logging sent covertly to the criminals
   stealing sensitive information.  Even access to a microphone near the
   keyboard may reveal passwords.  Once access is gained, even with a
   low privilege, many applications automatically assert the password
   when sending or receiving messages.

   Malware Payloads may be carried in items that receive special
   handling.  Examples could be pictures or scripts embedded within a
   message or referenced via URLs.  It could also be attachments added
   to the message, often where the name of the attachment has been
   obfuscated to convince the recipient they can safely invoke the
   operating system's default handling routines.

   Timing Analysis is an attack method that takes advantage of knowing
   the algorithm used for processing the signature.  When the private
   portion of the key is involved in the process, care must be taken to
   ensure the time performing the operation is not revealed.  This
   timing enables techniques that deduce the private key.  Even with
   random latency variations introduced by the network, this variation
   can be significantly reduced by finding the median from additional



Otis                     Expires April 27, 2006                 [Page 6]


Internet-Draft             Email+DKIM threats               October 2005


   measurements.

   Network Exploits are also becoming more common.  These attacks
   exploit various elements of the network infrastructure, often
   misdirecting network traffic.  This may involve falsified
   configuration information, falsified connection redirects or hijacks,
   poisoned domain name servers, and even corrupted routing elements.

4.  Security Requirements

   The use of private keys within the signing MTA server increases the
   level of security required to safely provide the DKIM signing
   services.  External access to non-essential services should be
   prevented using appropriate measures.  The Operating System should
   also be monitored for execution of unauthorized programs and access
   attempts to otherwise protected services.  When the server is running
   within a virtual machine, special care must be exercised with respect
   to timing attacks on private keys where even processing loads may
   reveal sensitive information.  The generation of a signature should
   be staged to mask the actual time expended as a means to protect the
   private key.  As email is often held in queues during processing,
   results may be held for an assured duration to conceal the time
   related to signing.

5.  Ranking of Bad Actors

   The problems confronted by DKIM can be generalized as the result of
   abusive acts by individuals taking advantage of the open nature of
   email.  For the purposes of this document, these abusive individuals
   will be referred to as Bad Actors.  Bad Actors have become more
   sophisticated, and their motivations have become increasingly
   criminal in nature.

   At the low end of severity, Bad Actors may represent unsophisticated
   individuals taking advantage of many commercially available tools.
   These tools may facilitate messages being sent in bulk, or may employ
   criminal strategies that avoid being identified and subsequently
   blocked.  Unsolicited messages sent in bulk often becomes the basis
   used for blocking future exchanges.  As newer methods of
   identification are attempted, often these bulk distribution tools
   represent a significant portion of applications adopting the newer
   protocol extensions.  The adoption of the extensions is often based
   upon another strategy where changing identities becomes a small cost
   for sustaining their nefarious enterprise.

   The next level of severity could be considered a surreptitious
   service provider that specializes in sending unsolicited email.
   These Bad Actors often employ infrastructure specifically designed to



Otis                     Expires April 27, 2006                 [Page 7]


Internet-Draft             Email+DKIM threats               October 2005


   obfuscate their identity.  Their infrastructure may include open-
   proxies, open-relays, and the use of multiple points of access which
   take advantage of asymmetric routing as a means to disguise source IP
   addresses.  Their infrastructure may also be established using
   thousands of compromised systems that may have been leased.

   Another technique used by Bad Actors is to send to low priority
   backup MTAs with the expectation messages will be bounced and the
   intended recipient is contained within the bounce-address.  This
   bounced message technique is another method used to obfuscate the
   source IP address of the message.  Although this IP address is
   typically found in the Received headers, the reputation of this
   Received header IP address is not always checked.  Bad Actors
   offering such services often provide email address lists to their
   clientele that may have been obtained from compromised systems,
   harvested, purchased, or discovered by means of dictionary attacks.

   The highest level of severity would be represented by criminals who
   intend to commit fraud and who are financially-motivated.  These Bad
   Actors are becoming organized and specialized with rapidly growing
   sophistication and threaten not only email, but the network itself.
   These Bad Actors should be expected to employ all of the above
   mechanisms, in addition to attacks on Internet infrastructure, such
   as DNS cache-poisoning attacks, and IP routing attacks via
   compromised network routing elements, and more.

6.  Capabilities of Bad Actors

6.1  General capabilities

   In general, Bad Actors described above should be expected to have
   access to the following:

   1.  An extensive corpus of messages from targeted domains

   2.  Knowledge of the practices used by targeted domains

   3.  Access to public keys and associated authorization records
       published by the targeted domains

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

   1.  Generate substantial numbers of unsigned messages that might
       represent either an intentional or unintentional denial of
       service attack

   2.  Transmit messages using any envelope information desired




Otis                     Expires April 27, 2006                 [Page 8]


Internet-Draft             Email+DKIM threats               October 2005


   3.  Transmit messages using any message headers desired

   4.  Submit messages to MTAs from multiple locations within the
       Internet

   5.  Sign messages on behalf of domains from registrars that protect
       the domain owner's privacy or that have poor vetting practices

   6.  Generate substantial numbers of messages with invalid signatures
       which may be an attempt to create a denial of service attack by
       overwhelming DKIM verification

   7.  Resend messages which may have been previously signed by other
       domains


6.2  Advanced capabilities

   Certain classes of Bad Actors may have substantial financial
   motivation, and therefore could be expected to have more capabilities
   at their disposal.  These include:

   1.  Access to significant computing resources, perhaps through the
       conscription of many compromised systems.  This could allow Bad
       Actors to perform various types of brute-force attacks.

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

   3.  Influence over portions of DNS using mechanisms, such as cache
       poisoning.  This might be used to influence message routing, or
       to falsify DNS-based key or policy advertisements.

   4.  Ability to eavesdrop on some existing traffic, perhaps from a
       wireless network, a cable or DSL modem, or a compromised server
       or router.

   The last three of these mechanisms could permit Bad Actors to
   redirect traffic and masquerade as a desired destination.  Such
   redirection provides a means to deceive the recipient or those
   attempting to send messages, and may be used to obtain access-related
   information among other sensitive data.

7.  Bad Actor's Points of Access

   In the following discussion, the term "Administrative Unit", taken



Otis                     Expires April 27, 2006                 [Page 9]


Internet-Draft             Email+DKIM threats               October 2005


   from [I-D.crocker-email-arch], is used to refer to a portion of the
   email path under common administration.  Recipients usually establish
   mutual authentications with Administrative Units receiving and
   verifying their email using shared secrets and server certificates.
   Administrative Units that perform message signing also usually
   establish mutual authentication using shared secrets and server
   certificates.

7.1  Bad Actors with Access in the Administrative Unit

   Bad Actors can obtain access anywhere in the Internet.  Bad Actors
   that have privileged access within the Administrative Unit of the
   signing-domain or the recipient domain have capabilities beyond those
   elsewhere, as described in following sections.

7.1.1  Access in the Signing-Domain's Administrative Unit

   Bad Actors may gain access using compromised accounts or systems
   within the Administrative Unit corresponding to the signing-domain.
   Although submission of messages generally occurs prior to the
   application of a message signature, DKIM could still be effective at
   isolating compromised accounts, and should be effective at isolating
   compromised message signing systems when each system utilizes
   specific keys.  Defense in such cases would be improved by monitoring
   for account abuse and system integrity, in addition to limiting
   access to local system services.

   DKIM can be effective at improving email security within the
   Administrative Unit, especially in the case where an Administrative
   Unit has systems coupled by the Internet.  DKIM signatures can
   validate legitimate externally-originated messages considered within
   the Administrative Unit.

7.1.2  Access in the Recipient's Administrative Unit

   Bad Actors may gain access using compromised systems within the
   Administrative Unit of the message recipient.  Since messages
   typically undergo DKIM verification one time within a possible
   successions of systems carrying messages to their destination within
   the Administrative Unit, DKIM may not detect invalid messages from
   compromised systems that are subsequent to the DKIM verification.
   Bad Actors may also masquerade as a system within the succession as
   another means of introducing invalid messages.  Defense in such cases
   would be improved by verifying DKIM at the last system in the
   succession, using authentication mechanisms like SMTP AUTH, by
   monitoring system integrity, in addition to limiting access to local
   system services.




Otis                     Expires April 27, 2006                [Page 10]


Internet-Draft             Email+DKIM threats               October 2005


7.2  Bad Actors with External Access

   DKIM focuses primarily on Bad Actors that do not have privileged
   access within the Administrative Units of the signer or the
   recipient.  Outside these Administrative Units, the trust
   relationships required for authenticated message submission do not
   exist and do not scale adequately to be practical.

   Bad Actors with only external access will usually attempt to exploit
   the open nature of email.  Most Administrative Units will accept
   messages with a valid email address for a local domain, often after
   investigating the reputation of the source IP address.  Bad Actors
   may generate messages without signatures and rely upon techniques
   that obfuscate their source IP address.

   When signing-domains accrue reputations serving as a basis for
   acceptance, Bad Actors may take advantage of registrars that protect
   the privacy of domain owners, or that do not verify the domain
   owner's identity in a reliable manner.  Bad Actors may then use these
   domains without an initial negative reputation to generate messages
   with valid signatures.  Bad Actors may send messages containing a
   diversity of email addresses to avoid filtering techniques.  Often
   this ploy by Bad Actors is attempted while posing as mailing lists,
   greeting cards, or other agents which legitimately send or re-send
   messages on behalf of others.

8.  Representative Bad Acts

   One of the most common bad acts attempted is the delivery of messages
   which obfuscate their true source within the network or associated
   domain.  The purpose of obfuscation might be to gain acceptance or to
   defraud the recipient.  The severity of this problem ranges from
   messages merely being unwanted, to defrauding the recipient or
   compromising their system with a payload of malware.

8.1  Use of Arbitrary Identities

   Arbitrary Identifiers typify those bad acts aimed at obfuscation to
   gain acceptance of messages.  Such methods use a wide range of
   techniques as previously described.

   DKIM may be effective for abating the misuse of a domain which
   asserts all messages are signed by the domain.  The effectiveness of
   DKIM at preventing domain misuse would depend upon the prevalence of
   recipients validating DKIM signatures and obtaining domain-wide
   assertions.  For cases where a domain is not being misused, or when
   signed by a domain controlled by Bad Actors, the recipient would then
   be reliant upon reputation or accreditation services for protection.



Otis                     Expires April 27, 2006                [Page 11]


Internet-Draft             Email+DKIM threats               October 2005


8.2  Use of Specific Identities

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

8.2.1  Exploitation of Social Relationships

   One reason for falsifying an associated domain is to encourage a
   recipient to act on a particular email message that appears to be
   from an acquaintance or previous correspondent trusted by the
   recipient.  This tactic has been used by email-propagated malware
   which emails to addresses in the compromised system's address book.
   In this case, the sender's email address and related signatures may
   not have been falsified, so DKIM would not be directly effective in
   preventing this act, but could facilitate the isolation of the
   compromised system when an opaque-identifier has been included, see
   [I-D.otis-mass-reputation].  Using opaque-identifiers would allow
   rapid correlations of malware sources by third-parties monitoring for
   this type of threat.

   It is also possible for address books to be harvested and used by an
   attacker to send messages from elsewhere.  DKIM may be effective at
   mitigating these acts when the recipient verifies the DKIM signature
   and when the sending domains assert all messages are signed by the
   domain.  It is also possible for the recipient to retain a binding of
   the opaque-identifier with the signing-domain associated with the
   sender's email-address, see [I-D.otis-mass-reputation].

8.2.2  Identity-Related Fraud

   Bad acts related to email-based fraud often involve the transmission
   of messages misusing visible associated domains as part of the fraud
   scheme.  The misuse of a specific associated domain sometimes
   contributes to the success of the fraud by convincing the recipient
   that the message is valid.

   To the extent the success of the fraud is enhanced by the misuse of a
   specific visible associated domain, Bad Actors may have significant
   motivation and resources to circumvent measures that target specific
   headers for unauthorized use.  There could be exigent cases where a
   domain-wide assertion becomes beneficial if it prohibits the
   appearance of the domain in any originating header unless also signed
   by the domain.  This would be accomplished with a domain-wide
   assertion made by the signing-domain, similar to the assertion that
   all messages are signed by the domain, see [I-D.otis-mass-
   reputation].





Otis                     Expires April 27, 2006                [Page 12]


Internet-Draft             Email+DKIM threats               October 2005


8.2.3  Reputation Attacks

   Another motivation for using a specific associated domain in a
   message is to harm the reputation of the domain.  For example, a
   commercial entity might wish to harm the reputation of a competitor,
   perhaps by sending a copy of their competitor's signed promotion as
   unsolicited bulk email.  A reputation service would categorize abuse
   primarily by the recipient, and not the message content.  A
   reputation service would not be able to differentiate between valid
   and invalid uses of a signed message.

   While reputation services must accrue behaviors based upon verified
   identifiers, there must also be a means to mitigate ongoing abuse.
   Without a means to abate ongoing abuse, the reputation service, which
   must be responsive to the needs of their subscribers, would have
   little choice but to list the domain being attacked and expect them
   to undergo a rehabilitation process.  Rehabilitation may involve a
   demonstration of having a means to respond to abuse.  See the
   following section on Message Replay Attacks.

9.  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, when the systems prove effective.  Some
   categories of bad acts are described below.  Additional postulated
   attacks are described in the Security Considerations section of
   [I-D.allman-dkim-base].

9.1  DoS Attack

   Checking either the authorizations associated with a message
   signature or the verification of the signature will not afford any
   Denial of Service protections.  There are only two choices available
   where DoS protections are possible.  The DoS protections could be
   based upon the remote IP address or upon the verification of the EHLO
   name.  In the case of the EHLO name, the problem associated
   collateral blocking is overcome, and a subsequent reputation check on
   the signing-domain may be skipped when the EHLO name is within the
   signing-domain.

   If the strength of the EHLO is not considered adequate, it may be
   possible to added a signature, the last digit of the year, and the
   week number prefixed to the EHLO name delineated with an '_'.  The
   hash of the EHLO would could include a string that represents all but
   the lower three bits of the remote IP address.  After all, the EHLO
   is currently permitted to fail verification.



Otis                     Expires April 27, 2006                [Page 13]


Internet-Draft             Email+DKIM threats               October 2005


9.2  Invalid Signatures

   Messages with invalid signatures would be handled as messages without
   signatures.  Such messages would be handled in the normal fashion
   where the reputation of the remote IP address would be assessed.
   Rejections based upon the remote IP address often creates a problem
   when the address is being shared.  When a Bad Actor sharing the IP
   address sends abusive email, other entities may be collaterally
   blocked when a negative reputation is then applied.  Such blocking
   may encourage those that find themselves blocked to adopt message
   signing as an alternative basis for reputation assessment.

9.2.1  Canonicalization and Message Normalization

   Until signatures are known to be reliably valid throughout the email
   infrastructure, invalid signatures should be treated in the same
   manner as a message without a signature.  As with any message, these
   messages may be introduced by Bad Actors.  The intent may be to have
   the message appear as though it was legitimately sent, but "broken"
   in transit.  This should not affect how the message is handled, and
   the reputation of the remote IP address should still be assessed.

   To minimize the number of broken messages and thus improve the
   reliability of the message signature, message normalization is
   required to ensure line-lengths are compliant prior to signing.  The
   current simple canonization is rather fragile, whereas the relaxed
   canonicalization allows for several exploits.  On the DKIM list, Earl
   Hood has recommended what appears to be a suitable replacement for
   the no-white-space method.  This technique removes white-spaces
   preceding end-of-lines and streaming white-space at the beginning and
   end of the message body.

9.3  Body Length Parameter

   The Body Length parameter available as an option within DKIM must be
   used with great caution.  Recipients that find the message length has
   increased, should discard the portion of the message that prevents
   signature validation when included as signed content.  The concept
   behind this option was to accommodate the appending of information by
   providers or some list servers.  As this option can be easily
   exploited, especially through a list server, mandating the deletion
   of added information would be the only solution that prevents this
   option from inviting an abusive message replay problem.

9.4  Multiple Signatures

   The DKIM draft offers little guidance with respect to multiple
   signatures.  Multiple signatures, rather than offering greater



Otis                     Expires April 27, 2006                [Page 14]


Internet-Draft             Email+DKIM threats               October 2005


   information, may obfuscate the role played by the signer.  There have
   been suggestions that signatures be sequenced by way of a count
   added, or by their header order within the message.  Unfortunately
   these techniques do not clarify which signature is significant with
   respect to the initial signer.  Any miscreant could either rearrange
   signature headers, add sequence numbers that appear as if signatures
   have been dropped, or add several "throw-away" signatures where
   reputation accrual may be diffused.  Multiple signatures also provide
   plausible deny ability when a reputation service attempts to locate
   the accountable domain.  An association with an email-address may not
   clarify the role of the signer, as the signing may be done by domains
   that are independent of any message headers.  There should also be a
   limit with respect to the number of signatures allowed within a
   message, as each signature represents added message overhead.

   It may be advisable to have signature headers that clarify the role
   of the signer.  The current signature header could be considered the
   "Originating" signer.  A list server may add their signature as a
   "Remailing" signer.  The receiving domain within the recipient's
   Administrative Unit may wish to add their "Verifying" signature as
   verification that various checks have been completed.  Any previous
   signatures of the same role would be deleted and perhaps logged
   within the Received headers.  The "Verifying" signature should not be
   considered valid beyond the Administrative Unit.

   For additional protection against message replay attacks, a practice
   could be established that restricts these three roles to a single
   signature per message.  A Remailing signature may encompass the
   Originating signature.  A Verifying signature may encompass both the
   Originating signature and the Remailing signature.  When adding a
   signature that encompass previous signatures, the signature
   information associated the 'b=' tag with could be overwritten with
   "remailing-checked", "verifying-checked" or "invalid."  The typical
   recipient could rely upon the Verifying signature provided by the
   Administrative Unit at the MUA, but would not have access to
   signatures that could be used to stage a message replay attack.

   In a situation where message replay attacks become problematic for
   messages sent to a specific domain, the signing domain may wish to
   preclude sending signed messages to these domains.  The receiving
   domain may wish to prevent the possibility that any of their users
   could be capable of such an attack by obfuscating Originating and
   Remailing signatures and adding the Verifying signature.

9.5  Use of "throw-away" domains

   Bad Actors may also introduce messages with valid signatures from
   domains they control, perhaps "throw-away" domains registered under



Otis                     Expires April 27, 2006                [Page 15]


Internet-Draft             Email+DKIM threats               October 2005


   false pretenses or using registrars that protect the privacy of the
   domain owner.  In other words, the existence of a message signature
   does not imply the conduct of a signing-domains is trustworthy.  The
   already common use of such domains require domain-based accreditation
   or reputation systems.  A reputation service may not be able to
   differentiate between a new and a throw-away domain.  A Bad Actor
   could also acquire a domain previously used for legitimate purposes.
   Reputation services may extend the weighing of behaviors to include
   that of the registrar.  Current name based reputation systems are
   known as Right-Hand-Side reputation services.  Even without the use
   of a name-based reputation service, local reputation, mostly in the
   form of white-lists, can be maintained by domains to improve the
   deliverability of email from domains where existing relationships
   have been established.

   Accreditation and reputation, or even local white-lists, require a
   verifiable identity upon which to base the accrual of behaviors and
   possible feedback reports.  Message signing provides an identity
   which is intended to be sufficiently reliable for this purpose.  A
   verifiable identity is necessary for accreditation and reputation
   systems to operate, provided there is a means established to either
   prevent or abate message replay attacks.

   Providers operating shared email services, mailing lists, and other
   legitimate agents may commonly sign messages with headers containing
   differing domains.  This common practice offers valuable freedoms for
   typical users.  This practice may allow a Bad Actor to sign messages
   containing divergent domains and to also appear legitimate.
   Nevertheless, the assessments of the signing-domain should remain the
   primary factor when deciding whether to accept the messages.  When
   the signing-domain is provided by a registrar that ensures domain
   owner privacy and has not obtained a recent reputation, little
   confidence in the signing-domain can be obtained.  As with message
   replay abatement, such mysterious signing-domains may be given a
   Transient Negative Completion reply.  Over time, the signing-domain
   will become known, or the administrators of the signing-domain may
   contact the relevant reputation and accreditation services.

9.6  Message Replay Attack

   Attacks based upon abusive retransmission of an otherwise valid
   message is referred to in this document as a "message replay attack".
   DKIM is able to provide an option that offers a means to promptly
   abate this type of replay, while also identifying all culpable
   sources, see [I-D.otis-mass-reputation].  This could be accomplished
   using an opaque-identifier revocation mechanism that is checked when
   the message appears to be coming from a different domain, or when the
   recipient has changed.  Abusive replay abatement is essential for the



Otis                     Expires April 27, 2006                [Page 16]


Internet-Draft             Email+DKIM threats               October 2005


   protection of the signing-domain's reputation.

   Message replay must be allowed to occur, even at high levels.
   Legitimate replays may result when a message is distributed through a
   list server, for example.  As valid message replay is performed at
   systems unrelated to the signing-domain, this replay process must be
   monitored for abuse, and strategies will be needed to deter efforts
   attempting to elude an abatement process.  There are methods that can
   be used to mitigate the precautions needed to deal with a potential
   replay problem.  The EHLO verification, essential for name based DoS
   protections, could also mitigate replay abatement.  A signed hash of
   a salted [RFC2821] RCPT TO header could be another replay abatement
   mitigation strategy.

   Part of this mitigation strategy may involve delaying the complete
   processing of messages identified as having potential replay risk.
   This delay is needed to allow abuse-monitoring the requisite time to
   react, which could be done within minutes.  This processing delay may
   occur at the transmitter, or the receiver, or at a combination of
   both.  Transient Negative Completion replies indicating the request
   was aborted with an error in processing should cause the message to
   be held at the transmitter, see [RFC2821].  The receiver may opt to
   queue a limited number of messages identified as having a replay
   risk, and once that limit has been reached, a Transient Negative
   Completion reply is issued.  This mechanism could be further
   mitigated by white-lists of trusted message resenders, such as list
   servers.

   When a message appears to be coming from a different domain and has
   an invalid hash of the [RFC2821] RCPT TO, as yet another option,
   messages may be held within a queue for a brief period to allow time
   for an opaque-identifier revocation to occur, see [I-D.otis-mass-
   reputation].  While opaque-identifiers may normally reflect the
   account used to gain access, serializing the opaque-identifier per a
   recipient of bulk email may also isolate the culpable recipient.

   Revocation of keys would not be a practical solution, as this will
   likely impact the delivery of many unrelated messages and will not
   likely be as prompt.  However, revocation of the opaque-identifier
   could also act as acknowledgement to a reputation or accreditation
   service that the signing-domain has responded to the reported abuse.
   Even the listing of revocations could become a service by delegating
   the revocation zone.  Lengthy delays in responding would provide
   little protection against such acts and likely precipitate a negative
   reputation as well as increased abuse.

   Bad Actors may obtain a reply from an individual within a signing-
   domain that carries a copy of their desired content.  The reply may



Otis                     Expires April 27, 2006                [Page 17]


Internet-Draft             Email+DKIM threats               October 2005


   then be used to distribute the desired content in bulk where no
   account has been obtained from the signing domain.  The person
   replying may be unaware of the risk.  When Bad Actors obtain an
   account from a provider that offers services to the public, and they
   send a small number of messages with desired content to addresses
   controlled by Bad Actors, the activity of the account will appear
   normal, but messages obtained can be used for abusive replay.

   Some other suggestions to abate message replay abuse burden the
   recipient.  These suggestions are usually based upon content
   filtering of messages that have been signed.  Once an unwanted
   message is discovered through filtering, signature finger-prints may
   then be used to identify any replicate message.  There is no
   assurance Bad Actors will not limit the number of replicate messages
   sent to a specific domain.  In such a case, filters would not be
   greatly advantaged by the signature.  There is also a suggestion that
   the signature finger-print itself accrues a reputation.  It is then
   expected the recipient would obtain the services of a signature
   finger-print reputation service.  The amount of centralized data
   exchanged to support a signature finger-print reputation scheme would
   represent a significant increased burden for the recipient that would
   be difficult to scale for either the service or the recipient.

   Other suggestions attempt to burden the sender.  Some suggestions
   have the signing-domain employ outbound content filtering.  Although
   outbound filtering could be a reasonable practice, the effectiveness
   of filtering is never 100%.  Bad Actors attempting to accumulate
   signed messages sent to themselves would be advantaged by outbound
   filters.  Messages that manage to evade outbound filters are also
   likely to evade inbound filters employed in other domains.  Another
   strategy suggests to enforce greater accountability for accounts
   whose messages are to be signed by DKIM.  Even with exorbitant fines
   exacted and with extensive vetting processes, there remains the
   problem created by the millions of compromised systems.  The stricter
   policies would increase the harm created by the compromised systems.

   Perhaps the greatest suggested burden placed upon the sender is to
   register the paths for all their valid email.  An onerous enough task
   is made more difficult with the path registration being predicated
   upon an email-address domain within a specific header selected in a
   non-compliant fashion, and not the signature itself.  See the section
   on Sender Signing Policy below.  This mingling of mail-address domain
   paths with a signing-domain path is actually attempting to solve two
   different problems simultaneously.  Neither message replay abuse, nor
   the misuse of an email-address is effectively prevented.  For many
   years from now, there will be recipients that use forwarded accounts,
   or users wishing to send messages to simple exploding list servers.
   These uses, as well as hundreds of others, will create a multitude of



Otis                     Expires April 27, 2006                [Page 18]


Internet-Draft             Email+DKIM threats               October 2005


   exceptions that must be accommodated.  Each method of accommodation
   represents a means for exploitation.

10.  Threats to Delivery

   DKIM relies upon more of the network infrastructure.  Normal email
   exchanges depend upon the recipient's DNS to locate MTAs that accept
   delivery for the recipient.  DKIM adds reliance upon the signing-
   domain's DNS for distributing public-keys.  With DKIM's Sender
   Signing Policy (SSP) [I-D.allman-dkim-ssp], as currently defined,
   delivery also depends upon allowances made for "third-party" signers
   when the [RFC2822] Sender, Resent-From, or Resent-Sender headers are
   used by the signing-domain.  Such increased dependency, especially
   with respect to policy assertions, represents additional avenues for
   attack and will negatively impact many commonly used email services.

   While DNSSEC [RFC4033][RFC4034][RFC4035] offers protection from
   various attacks on DNS, its greater overhead may increase DKIM DoS
   vulnerabilities.  There could be increased susceptibility at the
   recipient's DNS resolver, especially when wildcard public-keys or
   policies have been published.  Synthetic labels may allow an attack
   with increased requisite interaction and caching prior to verifying
   the signature.

   An SSP policy which excludes third-party signing, and is the only
   mode that can repudiate Bad Actors, may cause messages to become lost
   when remailed, or mailed.  For example, such a policy could prevent
   messages containing an email-address in the [RFC2822] From header
   from surviving mailing lists that sign messages, or when sent as
   signed news articles or invitations.  Such a consequence will
   discourage the vital adoption of the only policy that affords
   protection from Bad Actors.

11.  Urgent Response to Threats for Consumer Protections

11.1  Restricted Two-Party Communication

   While "phishing" attacks may be creating an exigent situation
   requiring an urgent response, parsing a complex policy record for
   qualifiers and lists of authorized "third-party" signers is not
   something that can be incorporated quickly.  A simpler record is
   required to allow immediate incorporation into MTAs as a means to
   offer the most expedient response to this type of threat.  This
   lookup should be offered as a service by the industry to combat this
   specific threat.

   A Two-Party listing service should simply return a record to indicate
   the queried domain prohibits the use of this domain within any email



Otis                     Expires April 27, 2006                [Page 19]


Internet-Draft             Email+DKIM threats               October 2005


   parameter or header unless also signed by this domain.  This would
   limit the use of the listed domain to two-party exchanges.
   Exceptions for messages containing the prohibited domain would be
   made when the only recipient is the prohibited domain.

11.2  Unrestricted Multiple-Party Communication

   When multiple-party email exchanges are to be protected, an assertion
   that all emails are exclusively signed by the domain should be based
   upon the header specified by [RFC2822] as having introduced the
   message into the email transport system.  Compliance with [RFC2822]
   email transport introduction allows common services to be retained
   without specific white-listing.  No information has been lost with
   respect to the signing domain and the email-address contained within
   the From header.  The receiving domain may assess such messages
   according to the relationships indicated.  However, acceptance should
   be primarily based upon the reputation of the signing-domain.  Where
   it is absolutely critical that the From header for a specific domain
   be protected, the Two-Party listing service should be used.  By
   removing any disruption in services resulting from a domain signing
   all their messages and making assertions on that basis would allow
   immediate repudiation of Bad Actors.  The current SSP policy
   necessitates a disruption in some services in order to repudiate
   messages from Bad Actors.

   Authorizing third-party signing defeats protection from Bad Actors.
   SSP's use of the From header to designate which domain establishes
   signing policy is disruptive and limits the scope of messages that
   can be afforded protection.  Messages being remailed where they are
   signed and reintroduced into the email transport system following
   [RFC2822] conventions, may be designated by SSP policies as being
   signed by "third-party" domains.  Rather an adhering to [RFC2822]
   conventions for establishing the header having introduced the message
   into the transport, the often visible From header was used as a basis
   instead, while risking the loss of a substantial number of otherwise
   valid messages and limiting the adoption of a protective policy.

11.3  Opportunistic Protection without Domain-wide Policy Assertions

   SSP designating the From, or when multiple-addresses exist, the
   Sender header for establishing signing policy is primarily to abate
   attempts at falsifying the author's email-address when third-party
   signing is not permitted.  Such falsification is often the case in
   "phishing" attacks.  The success of such an effort remains doubtful
   as many MUAs display just the "pretty-name."  Policy based upon the
   visible header also does not deal with threats associated with
   domains that have a similar appearance and with MUAs susceptible to
   character-set attacks.



Otis                     Expires April 27, 2006                [Page 20]


Internet-Draft             Email+DKIM threats               October 2005


   Attempts to base policy on the [RFC2822] From header significantly
   decreases protections afforded by DKIM by imposing dire consequences
   when indicating emails are signed exclusively by the domain.  While
   white-lists of authorized third-party signers may mitigate some
   unintended message loss, such an authorization strategy burdens the
   recipient, is expensive to maintain, and is not practical.

   DKIM can offer significant protection for multiple-party email
   commutations without the separate publication of signing policy.
   There is an alternative method that can be used to extend protection
   to recipient.  This strategy would take advantage of the situation
   that protection is often desired for prior correspondents.  With the
   messages being signed, the message itself offers a secure means to
   communicate what elements within the message can be relied upon to
   uniquely identify the message's author.

   For domains that assure those granted access are limited to specific
   email-addresses, any email-address from this domain can then be used
   to uniquely identify the author.  Domains that do not limit the
   email-address can alternatively offer an opaque-identifier within the
   signature to uniquely identify the account used to gain access.  The
   recipient could request that bindings of the requisite identifiers be
   saved.  With these bindings saved, the recipient can then be alerted
   when these identifiers have changed in subsequent messages.  In some
   cases, it would be possible to automatically retain the bindings at
   the MTA rather than just the MUA.

   By retaining binding for those specific email-addresses considered
   important to the recipient, greater analysis can occur to defeat
   "pretty-name", character-set, and domain look-alike attacks.  When an
   identifier appeared to have changed, the recipient should be shown
   the email-address and other identifiers using a consistent character-
   set and asked if the information should replace or be merged with
   current bindings, or perhaps be ignored, or flagged as a spoofing
   attempt.

12.  Sender Signing Policy

   DKIM Sender Signing Policy (SSP) [I-D.allman-dkim-ssp] attempts to
   introduce several constraints on an email-addresses found in one of
   two headers in conjunction with DKIM signatures.  These constraints
   may indicate that a signature is required either of some third-party
   domain, or of a first-party domain, or no signature is required at
   all.  The SSP also introduces a constraint placed upon the [RFC2822]
   From header that may be conditionally relegated to the Sender header
   when there are multiple email-addresses within the From header.
   Conditionally relegating the From to the Sender header may confuse
   recipients for two reasons.  The Sender header may be indicated by



Otis                     Expires April 27, 2006                [Page 21]


Internet-Draft             Email+DKIM threats               October 2005


   some MUAs as being the significant email addresses.  It also may not
   be obvious to the recipient when there are multiple email-addresses
   within the From header.

   It is also not clear how a third-party signature should be handled in
   the case where there are multiple signatures added to the message.
   Should a message that has a first-party signature and a policy that
   third-party signatures are prohibited, then cause a message to be
   rejected when a signature is added by a third-party?  What happens
   when the first-party signature has expired, but the third-party
   signature is still valid?

   Unless the domain-wide assertion that all emails are signed follows
   normal email conventions with respect to which header introduced the
   message into the email transport system, there will be messages that
   are not be protected by the SSP From/Sender assertion.  This failure
   to provide full protection in such cases was created by a desire to
   ensure the significant header related to policy is always visible.
   Nevertheless, to establish protections without disrupting email
   services, it would be beneficial to have an Introduction assertion.
   With an Introduction assertion, all messages that would normally be
   considered to have been introduced by a domain using [RFC2822]
   definitions would be assured protection.  This approach would suffer
   from far fewer policy conflicts by other domains and provide much
   greater delivery integrity.

   The SSP strategy also fails to consider there are other methods that
   may be used to qualify email and assumes the From/Sender headers are
   always significant.  An MUA that uses SPF Classic may indicate a
   message has been qualified based upon the [RFC2821] MAILFROM, but
   this parameter is not checked against the DKIM signing-domain, and
   yet the recipient may see a message as verified as a result of the
   MAILFROM.

   Once normal email conventions are allowed, a new assertion is
   required to protect those domains that have become "phishing"
   targets.  This new assertion would prohibit other domains the use
   parameters and headers that could contain an email-address considered
   to have introduced the message.  It would cover the MAILFROM, From,
   Sender, Reply-To, and corresponding Resent-* headers.  Such a domain-
   wide assertion would curtail exploits still possible with an SSP
   policy that erroneously assumes what the recipient considers
   significant.

   Using non-compliant conventions with respect to the significant
   header also disrupts normal email practices.  A domain making a
   domain-wide assertion that all messages are signed may be unable
   receive protection for some of their messages, and may find that some



Otis                     Expires April 27, 2006                [Page 22]


Internet-Draft             Email+DKIM threats               October 2005


   of their messages have been subsequently prohibited by other domains.
   Even appending a Sender or Resent-* header will not offer a solution,
   as the From header may retrain significance.

   Attempting to bind specific headers to a signing-domain has an
   unfortunate consequence that some mechanisms may unfairly extend
   accountability to the email-address.  Any authorization of third-
   party signers with respect to a specific header's email-address is
   highly problematic.  This authorization is likely to be assumed as
   having authenticated the email-address causing unfair reputation
   accrual.  The SSP mechanism may also require an extensive number of
   lookups.  This mechanism will require lookups walking up the label
   tree, to qualify the local-part of an email address, and, with a
   pending proposal, to also authorize specific third-party signers.

13.  IANA Considerations

   This document defines no items requiring IANA assignment.

14.  Security Considerations

   This document describes the security threat environment in which
   DomainKeys Identified Mail (DKIM) is expected to provide some
   benefit.

15.  References

15.1  Normative References

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
              April 2001.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.





Otis                     Expires April 27, 2006                [Page 23]


Internet-Draft             Email+DKIM threats               October 2005


15.2  Informative References

   [I-D.allman-dkim-base]
              Allman, E., "DomainKeys Identified Mail (DKIM)",
              draft-allman-dkim-base-01 (work in progress),
              October 2005.

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

   [I-D.crocker-csv-csa]
              Crocker, D., "Client SMTP Authorization (CSA)",
              draft-crocker-csv-csa-00 (work in progress), October 2005.

   [I-D.crocker-csv-intro]
              Crocker, D., Otis, D., and J. Leslie, "Certified Server
              Validation (CSV)", October 2005.

   [I-D.crocker-email-arch]
              Crocker, D., "Internet Mail Architecture",
              draft-crocker-email-arch-04 (work in progress),
              March 2005.

   [I-D.otis-mass-reputation]
              Otis, D., "MASS impacts upon reputation",
              draft-otis-mass-reputation-03 (work in progress),
              September 2005.


Author's Address

   Douglas Otis
   Trend Micro, NSSG
   1737 North First Street, Suite 680
   San Jose, CA  95112
   USA

   Phone: +1.408.453.6277
   Email: doug_otis@trendmicro.com











Otis                     Expires April 27, 2006                [Page 24]


Internet-Draft             Email+DKIM threats               October 2005


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


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.


Acknowledgment

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




Otis                     Expires April 27, 2006                [Page 25]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/