pre-workgroup D. Otis Internet-Draft Trend Micro, NSSG Expires: April 23, 2006 October 20, 2005 Review of Threats Associated with Email and DomainKeys Identified Mail (DKIM) draft-otis-dkim-threats-00 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 23, 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 domains. This document also considers the impact of adding an opaque-identifier and implementing abusive replay abatement. This document considers threats against Internet mail and threats created when employing a signature-based Otis Expires April 23, 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. Sender Signing Policy . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1 Normative References . . . . . . . . . . . . . . . . . . . 20 13.2 Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Otis Expires April 23, 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 which 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, and 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 23, 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. 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 largely to avoid being filtered and this may increase the filtering Otis Expires April 23, 2006 [Page 4] Internet-Draft Email+DKIM threats October 2005 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]. 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 be any remedy, which represents a serious problem. This problem may Otis Expires April 23, 2006 [Page 5] Internet-Draft Email+DKIM threats October 2005 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 measurements. Otis Expires April 23, 2006 [Page 6] Internet-Draft Email+DKIM threats October 2005 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 obfuscate their identity. Their infrastructure may include open- proxies, open-relays, and the use of multiple points of access which Otis Expires April 23, 2006 [Page 7] Internet-Draft Email+DKIM threats October 2005 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 3. Transmit messages using any message headers desired Otis Expires April 23, 2006 [Page 8] Internet-Draft Email+DKIM threats October 2005 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 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 Actor 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 from [I-D.crocker-email-arch], is used to refer to a portion of the email path under common administration. Recipients usually establish Otis Expires April 23, 2006 [Page 9] Internet-Draft Email+DKIM threats October 2005 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 23, 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 is by a domain controlled by Bad Actors, the recipient would then be reliant upon reputation or accreditation services for Otis Expires April 23, 2006 [Page 11] Internet-Draft Email+DKIM threats October 2005 protection. 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 asserts 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 become 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 23, 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 23, 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 no-white- space 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. 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 23, 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, or 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 separate signature headers that clarify the role of the signer. The current signature header could be considered the "accountable" signer. A list server may add their signature as a "last-hop" signer. The receiving domain may wish to add their "MDA" signature which indicates that various checks have been completed. Any previous signatures of the same role should be deleted and perhaps logged within the Received headers. 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 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 Otis Expires April 23, 2006 [Page 15] Internet-Draft Email+DKIM threats October 2005 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 was done 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 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 Otis Expires April 23, 2006 [Page 16] Internet-Draft Email+DKIM threats October 2005 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 2821.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 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 Otis Expires April 23, 2006 [Page 17] Internet-Draft Email+DKIM threats October 2005 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 exceptions that must be accommodated. Each method of accommodation represents a means for exploitation. 10. 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 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 Otis Expires April 23, 2006 [Page 18] Internet-Draft Email+DKIM threats October 2005 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 is significant, 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 is always visible. It may be beneficial to have a NORMAL assertion. With a NORMAL assertion, all messages that would normally be considered to originate from a domain using [RFC2822] definitions would be assured protection. This approach would suffer from fewer policy conflicts by other domains and provide 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 by 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 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 Otis Expires April 23, 2006 [Page 19] Internet-Draft Email+DKIM threats October 2005 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. 11. IANA Considerations This document defines no items requiring IANA assignment. 12. Security Considerations This document describes the security threat environment in which DomainKeys Identified Mail (DKIM) is expected to provide some benefit. 13. References 13.1 Normative References [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 13.2 Informative References [I-D.allman-dkim-base] Allman, E., "DomainKeys Identified Mail (DKIM)", draft-allman-dkim-base-00 (work in progress), July 2005. [I-D.allman-dkim-ssp] Allman, E., "DKIM Sender Signing Policy", draft-allman-dkim-ssp-00 (work in progress), July 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), Otis Expires April 23, 2006 [Page 20] Internet-Draft Email+DKIM threats October 2005 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 23, 2006 [Page 21] 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 23, 2006 [Page 22]