SPF DoS Exploitation

Two experimental drafts and 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 .MailFrom, and the .Purported Responsible Address (PRA), where verifying each domain-name separately invokes the SPF evaluation process. There have been suggestions that the .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.

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 . Terminology conforms to . 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.

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 . The name-based path registration alternative to SPF starts by verifying the EHLO; see . 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.

There are no registrations required by IANA.

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 .