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 October 16, 2006.

Copyright Notice

Copyright © The Internet Society (2006).

Abstract

This document describes an email induced Denial of Service threat from SPF script used to evaluate the association of a source domain-name with the sending-system. The SPF script attempts to establish the domain-name association through the construction of an extensive IP address list of all sending-systems. Expectations of an association have become problematic, as message handling might be negatively affected without an apparent domain-name relationship discovered between the sending-system and either the message envelope or the message itself.

There is a safe name-based alternative to the SPF method that associates a source domain-name with the sending-system by conditionally comparing a list of domain-names against a verified EHLO. This alternative name-based association is performed only after the EHLO of the sending-system has been verified and accepted. Each of the two steps in this alternative approach involves only a single DNS transaction. Initially verifying the EHLO of the sending-system avoids multiplicative effects created when a large number of common DNS resources are relied upon by a sequence of Mail Handling Systems (MHS) forwarding a message. A verified EHLO also provides a name-based identifier for establishing requisite DoS protections. Dramatic reductions in the scale of a potential impact is accomplished by limiting common resources for evaluating a domain-name to a single conditional DNS transaction.

Table of Contents

1.  Introduction
2.  Definitions
3.  Defense against Denial of Service Attacks
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1. Introduction

Two experimental drafts [I-D.schlitt-spf-classic] (Schlitt, W. and M. Wong, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1,” June 2005.) and [I-D.lyon-senderid-core] (Lyon, J. and M. Wong, “Sender ID: Authenticating E-Mail,” May 2005.) relate various email source domains with the IP address of the SMTP client by assembling an extensive list of IP addresses. Both drafts utilize the SPF script syntax to manipulate names and content of Resource Records (RRs) obtained through DNS transactions. The SPF script is stored in one or more TXT RRs that are intended to hold generic character-strings. An additional lookup may be required to ascertain whether SPF specific RR types are being used instead of TXT RRs.

SPF script employs string macros, Address RRsets containing IP address information, MX RRsets containing the name and preference numbers of Mail Transfer Agents (MTAs), and the PTR RRsets located in the reverse reference IP address domains. Although this SPF script can be utilized in a number of ways, normally the intent is to return IP addresses of all systems directly involved with sending messages for a particular domain. In doing so, SPF drastically alters the scale of a DNS answer. The SPF script may define these addresses with CIDR notation and/or lookups of various RRsets.

The SPF script places limits on the number of DNS transactions permitted at each Mail Handling Service (MHS) in the path of the message when evaluating each source domain-name. SPF script may invoke 10 DNS transactions for various RRsets, where up to 10 follow-on DNS transactions may then occur. When the script does not provide a PASS result, an additional lookup might be made to obtain a macro expanded explanation TXT RR. As an example, evaluating just one domain-name per MHS may involve lookups for 1 TXT RR, 10 MX RRsets, and 100 A RRsets for a total of 111 DNS transactions. While there can be 11 SPF TXT RRs containing script in different domains, each of the 10 MX mechanism RRsets can contain 10 unique domain-names that span 100 victim domains.

Currently, there are two different domain-names in a message that are evaluated using SPF records. There is the [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MailFrom, and the [I-D.lyon-senderid-pra] (Lyon, J., “Purported Responsible Address in E-Mail Messages,” May 2005.).Purported Responsible Address (PRA), where verifying each domain-name separately invokes the SPF evaluation process. There have been suggestions that the [I-D.allman-dkim-base] (Allman, E., “DomainKeys Identified Mail (DKIM),” October 2005.).Signing-Domain might also be evaluated using SPF, where multiple signatures from different domains can exist.

SPF script is not predicated upon verifying the domain controlling the MTA. Obfuscation of the controlling domain may erroneously shift accountability onto the often hapless email-address domain owners who typically rely upon third-party services and may even publish open-ended address lists. The address-list approach prevents fair name-based accrual of MTA behaviors in order to establish effective DoS protections. To be effective, a DoS protection scheme must indicate specifically what domain is in control. SPF scripts might reference only victim domains unrelated to the control of the MTA, and provide inconclusive results subsequent to the evaluation.

2. Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Terminology:

Terminology conforms to [I-D.crocker-email-arch] (Crocker, D., “Internet Mail Architecture,” March 2005.).

RR: A DNS Resource Record.

RRset: Resource Records of the same type and name location.

Victim Domain: A domain not causing the transaction.

Open-ended: Not all valid elements are included in the set.

3. Defense against Denial of Service Attacks

The DoS concern specific to SPF scripts is manifold. SMTP is a store and forward protocol that distributes the SPF script threat to otherwise reputable MHS. This distribution multiplies the impact of the script when many common DNS resources from multiple domains are utilized by subsequent MHS. By encompassing multiple domains, the SPF script may not establish an accountable domain-name subsequent to evaluation when inconclusive results are obtained. Owing to these conditions, there is no reasonable strategy that can be used to mitigate the potential harm created by a distributed SPF script generated DoS attack. To estimate the potential for the SPF script generated threat, the level of network amplification is considered for this SPF DNS scripting scheme.

A typical stance taken when discussing DoS concerns is that there are other network amplification techniques to facilitate DoS exploits. One such exploit utilizes DNS servers. This exploit depends upon a lookup to be amplified by the difference between the query size and that of the answer, in addition to the number of queries made in a recursion process. To roughly estimate the network impact created by DNS UDP traffic, 1.3 queries will be assumed to occur on average from every DNS lookup, with an average query size of 100 bytes and an average answer of 500 bytes. Based upon these coarse assumptions, the resulting DNS amplification is about 13 to 1 when the source IP address of the lookup is also spoofed to be that of the targeted domain.

About 1 K bytes of outbound TCP traffic may be needed to send a small SMTP message. SPF scripts can target 100 DNS transactions when evaluating a single domain-name. In estimating the targeted amplification, the number of common DNS transactions is multiplied by the number of recipients in different domains, the different domain-names evaluated within the same message, and each sequential MHS that does not share a common DNS cache. A message sent to only 1 recipient who also utilize SPF evaluation in their MUA could then create about 312 to 1 network amplification directed toward a targeted domain. As a comparison, evaluating domain-names in this example using SPF represents about 24 times the threat caused by an exploit using recursive DNS.

The network amplification exploit using SPF may also leverage a provider's SMTP servers that are available from systems an attacker may have compromised. It is common for thousands of compromised systems to act in concert to disseminate spam, while each system may conform to normal use profiles. These spam messages could have a small list of recipients that further amplify the level of the attack. Perhaps these messages contain an average of 10 recipients. These messages may purport to be from email-addresses with random local names and sub-domains, beneath a list of top level domains. All of these different domains can nevertheless reference similarly targeted SPF records. The messages in the attack could be a stock tip ending up in a spam folder. No single message may convey the same information, and yet still target the same victim regardless who appears to be the author, or which folder is ultimately selected to receive the message.

  (1.3 x (100+500))/1000 = .78 DNS/SMTP Gain Factor

  SPF Script Network Amplification at victim domain:
   RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain

  100 x  2  x      2       x     1      x   .78    = 312

  100 x  2  x      1       x    10      x   .78    = 1560


  SMTP Name Path Network Amplification at victim domain:
   RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain

   1  x  2  x      2       x     1      x   .78    =  3

The SPF script facilitates canvassing by a covert DNS server for domains that utilize SPF evaluations and also facilitates a sustained DoS attack based upon this knowledge. Without altering the SPF script, local-part label macros provided by SPF can instantiate different queries for a series of messages from the same set of domains. Using this technique, in addition to ensuring the DNS information has not been locally cached to inundate the targeted domain with DNS transactions, this will also flood the local DNS cache which may expel previously obtained information prior to its normal expiration.

Just using the SPF script to evaluate a domain-name risks the integrity of DNS itself. A poisoning exploit often attempts to both flood the DNS answering for the RR being poisoned, and to gain access to the DNS whose cache is to be poisoned. Both of these efforts are facilitated by SPF script. The SPF script also provides the ability to query a covert DNS server that tracks the source IP address, ports, and Transaction IDs of DNS transactions to improve upon the subsequent construction and the timing of poison answers.

The name-based path registration approach provides a 100 to 1 reduction in the amount of network amplification with a maximum of only one conditional DNS transaction of a common resource. This name-based approach also always provides an accountable domain-name for effective DoS protections; see [I-D.otis-smtp-name-path] (Otis, D., “SMTP Name Path Registration,” April 2006.). The name-based path registration alternative to SPF starts by verifying the EHLO; see [I-D.crocker-csv-csa] (Crocker, D., “Client SMTP Authorization (CSA),” October 2005.). This allows a name-based defense to be established that fairly holds the domain controlling each sending system accountable for any abuse. This approach also ensures that prior to acceptance, there is no amplification of DNS transactions made with a victim domain, as each subsequent MTA forwarding a message offers their own EHLO that exists within their own domain or EHLO verification fails. A failure to verify the EHLO allows the recipient to delay subsequent acceptance of messages from both the EHLO and the associated client IP address as an effective DoS defensive tactic. Once EHLO verification is established as a requisite, message refusals could then be handled in a permanent fashion.

The safe name-based alternative to the SPF script method requires just one or two steps. The first steps ensures the EHLO of the MTA is directly verified with a single DNS transaction. Once the EHLO is verified, and when the EHLO is within the domain-name in question, no second step is needed. Otherwise, the second step attempts to establish a domain association by making a single forward reference PTR RRset lookup from the domain in question. These PTR RRsets would simply list the provider's root domains used by the owner of the email-address domain. A failure to verify the EHLO or to find an association with the message domain-names can delay acceptance of the message. EHLO verification is comparatively easier to administer than SPF scripts.

4. IANA Considerations

There are no registrations required by IANA.

5. Security Considerations

This document describes a threat to SMTP created by the evaluation of message related domain-names using SPF scripts. This document recommends a safer alternative that first verifies the EHLO of the MTA and then conditionally finds associations using a domain-name list. It is expected that the verified EHLO name will be checked against block-lists of abusers. When either the EHLO can not be verified, or an association with a message domain-name can not be established, delayed message acceptance provides another defensive strategy which allows time for abuse to be reported. Delay in acceptance can be accomplished with a Transient Negative Completion, in conjunction with "Requested action aborted: error in processing" SMTP response; see [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).

6. References

6.1. Normative References

6.2. Informative References

Author's Address

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 © The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

Acknowledgment

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