| draft-otis-spf-dos-exploit-01.txt | draft-otis-spf-dos-exploit-01-english-noplugs.txt | |||
|---|---|---|---|---|
| individual D. Otis | individual D. Otis | |||
| Internet-Draft Trend Micro, NSSG | Internet-Draft Trend Micro, NSSG | |||
| Expires: December 26, 2006 June 24, 2006 | Expires: December 26, 2006 June 24, 2006 | |||
| SPF DoS Exploitation | SPF DoS Exploitation | |||
| draft-otis-spf-dos-exploit-01 | draft-otis-spf-dos-exploit-01-english-noplugs | |||
| (translated by Julian Mehnle <julian@mehnle.net>) | ||||
| (Hey, Doug, substance is everything!) | ||||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 41 | skipping to change at line 43 | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on December 26, 2006. | This Internet-Draft will expire on December 26, 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2006). | Copyright (C) The Internet Society (2006). | |||
| Abstract | Abstract | |||
| This document describes an email induced Denial of Service threat | This document describes an email-induced Denial of Service threat from | |||
| from SPF script used to evaluate the association of a source domain- | SPF, which is used to evaluate the association of a source identity | |||
| name with the sending-system. The SPF script attempts to establish | domain-name with the sending-system IP address. SPF aims to establish | |||
| the domain-name association through the construction of an extensive | the domain-name association through the enumeration of the IP | |||
| IP address list of all sending-systems. Expectations of an | addresses of all sending-systems for the domain-name. | |||
| 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 | There are multiplicative effects when a large number of common DNS | |||
| associates a source domain-name with the sending-system by | resources are relied upon by a sequence of Mail Handling Systems (MHS) | |||
| conditionally comparing a list of domain-names against a verified | forwarding a message. The two indirect SPF mechanisms, "ptr" and | |||
| EHLO. This alternative name-based association follows the | "mx", makes SPF a highly dangerous method to verify an anonymous SMTP | |||
| verification of the sending-system's EHLO. Each of the two steps in | client's authorization. | |||
| this alternative approach involves only a single DNS transaction. | ||||
| Initially verifying the EHLO of the sending-system avoids the | ||||
| 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. The two | ||||
| SPF indirect references found in the text script, PTR, and MX records | ||||
| makes this scheme a highly dangerous method to verify an anonymous | ||||
| SMTP client's authorization. Dramatic reductions in the scale of the | ||||
| potential impact is accomplished by limiting common resources used | ||||
| for evaluating a domain-name to that of a single conditional DNS | ||||
| transaction. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 3. Defense against Denial of Service Attacks . . . . . . . . . . 5 | 3. Defense against Denial of Service Attacks . . . . . . . . . . 5 | |||
| 4. The Exploit Example . . . . . . . . . . . . . . . . . . . . . 8 | 4. The Exploit Example . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 | 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 | |||
| skipping to change at page 4, line 10 | skipping to change at line 75 | |||
| Appendix B. Example Traffic Qualifying | Appendix B. Example Traffic Qualifying | |||
| jo@cert-test.mail-abuse.org . . . . . . . . . . . . . 15 | jo@cert-test.mail-abuse.org . . . . . . . . . . . . . 15 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 62 | |||
| Intellectual Property and Copyright Statements . . . . . . . . . . 63 | Intellectual Property and Copyright Statements . . . . . . . . . . 63 | |||
| 1. Introduction | 1. Introduction | |||
| Two experimental RFCs "Sender Policy Framework (SPF) for Authorizing | Two experimental RFCs "Sender Policy Framework (SPF) for Authorizing | |||
| Use of Domains in E-Mail, Version 1" [RFC4408] and "Sender ID: | Use of Domains in E-Mail, Version 1" [RFC4408] and "Sender ID: | |||
| Authenticating E-Mail" [RFC4406] relate various email source domains | Authenticating E-Mail" [RFC4406] relate various email source domains | |||
| with the IP address of the SMTP client by assembling an extensive | with the IP address of the SMTP client by assembling an extensive list | |||
| list of IP addresses. Both drafts utilize the SPF script syntax to | of IP addresses. Both drafts use TXT RRs to describe those lists of | |||
| manipulate names and content of Resource Records (RRs) obtained | IP addresses using the SPF syntax defined in [RFC4408]. An additional | |||
| through DNS transactions. The SPF script is stored in one or more | lookup may be required to ascertain whether SPF specific RR types are | |||
| TXT RRs that are intended to hold generic character-strings. An | being used instead of TXT RRs. | |||
| additional lookup may be required to ascertain whether SPF specific | ||||
| RR types are being used instead of TXT RRs. | ||||
| SPF script employs string related macros, Address RRsets containing | SPF employs string related macros, Address RRsets ("ip4" and "ip6" | |||
| IP address information, MX RRsets containing the name and preference | mechanisms) containing IP address information, MX RRsets containing | |||
| numbers of Mail Transfer Agents (MTAs), and the PTR RRsets located in | the names of Mail Transfer Agents (MTAs), and the PTR RRsets located | |||
| the reverse reference IP address domains. Although this SPF script | in the reverse reference IP address domains. Although SPF can be | |||
| can be utilized in a number of ways, normally the intent is to return | utilized in a number of ways, normally the intent is to return IP | |||
| IP addresses of all systems directly involved with sending messages | addresses of all systems directly involved with sending messages for a | |||
| for a particular domain. In doing so, SPF drastically alters the | particular domain. In doing so, SPF drastically alters the scale of a | |||
| scale of a DNS answer. The SPF script may define these addresses | DNS answer. An SPF record may define these addresses with CIDR | |||
| with CIDR notation and/or lookups of various RRsets. | notation and/or lookups of various RRsets. | |||
| The SPF script places limits on the number of DNS transactions | SPF limits the number of DNS lookups permitted at each Mail Handling | |||
| permitted at each Mail Handling Service (MHS) in the path of the | System (MHS) in the path of the message when evaluating each source | |||
| message when evaluating each source domain-name. SPF script may | domain-name. An SPF record may invoke 10 DNS lookups for various | |||
| invoke 10 DNS transactions for various RRsets, where up to 10 | RRsets, where up to 10 follow-on DNS lookups may then occur. When the | |||
| follow-on DNS transactions may then occur. When the script does not | record does not provide a PASS result, an additional lookup might be | |||
| provide a PASS result, an additional lookup might be made to obtain a | made to obtain a macro expanded explanation TXT RR. As an example, | |||
| macro expanded explanation TXT RR. As an example, evaluating just | evaluating just one domain-name per MHS may involve lookups for 1 TXT | |||
| one domain-name per MHS may involve lookups for 1 TXT RR, 10 MX | RR, 10 MX RRsets, and 100 A RRsets for a total of 111 DNS lookups. | |||
| RRsets, and 100 A RRsets for a total of 111 DNS transactions. While | While there can be 11 SPF TXT RRs in different domains, each of the 10 | |||
| there can be 11 SPF TXT RRs containing script in different domains, | MX mechanism RRsets can contain 10 unique domain-names that span 100 | |||
| each of the 10 MX mechanism RRsets can contain 10 unique domain-names | victim domains. | |||
| that span 100 victim domains. | ||||
| Currently, there are two different domain-names in a message that are | Currently, there are two different domain-names in a message that are | |||
| evaluated using SPF records. There is the [RFC2821].MailFrom, and | evaluated using SPF records. There is the [RFC2821].MailFrom, and | |||
| the experimental and proprietary "Purported Responsible Address in | the experimental and proprietary "Purported Responsible Address in | |||
| E-Mail Messages" [RFC4407], where verifying each domain-name | E-Mail Messages" [RFC4407], where verifying each domain-name | |||
| separately invokes the SPF evaluation process. There have been | separately invokes the SPF evaluation process. | |||
| suggestions that the [I-D.ietf-dkim-base] Signing-Domain might also | ||||
| be evaluated using SPF, where multiple signatures from different | ||||
| domains can also exist. | ||||
| SPF script is not predicated upon verifying the domain controlling | ||||
| the MTA. Obfuscation of the controlling domain may even erroneously | ||||
| shift accountability onto the often hapless email-address domain | ||||
| owners who typically rely upon third-party services and may publish | ||||
| open-ended address lists. The address-list approach prevents fair | ||||
| name-based accrual of MTA behaviors as a means 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 | 2. Definitions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
| Terminology: Terminology conforms to [I-D.crocker-email-arch]. | Terminology: Terminology conforms to [I-D.crocker-email-arch]. | |||
| RR: A DNS Resource Record. | RR: A DNS Resource Record. | |||
| RRset: Resource Records of the same type and name location. | RRset: Resource Records of the same type and name location. | |||
| Victim Domain: A domain not causing the transaction. | Victim Domain: A domain not causing the transaction. | |||
| Open-ended: Not all valid elements are included in the set. | Open-ended: Not all valid elements are included in the set. | |||
| 3. Defense against Denial of Service Attacks | 3. Defense against Denial of Service Attacks | |||
| The DoS concern specific to SPF scripts is manifold. SMTP is a store | The DoS concern specific to SPF records is manifold. SMTP is a store | |||
| and forward protocol that distributes the SPF script threat to | and forward protocol that distributes the SPF-related threat to | |||
| otherwise reputable MHS. This distribution multiplies the impact of | otherwise reputable MHSs. This distribution multiplies the impact of | |||
| the script when many common DNS resources from multiple domains are | an SPF record when many common DNS records from multiple domains are | |||
| utilized by subsequent MHS. By encompassing multiple domains, the | utilized by subsequent MHSs. By encompassing multiple domains, the | |||
| SPF script may not establish an accountable domain-name subsequent to | SPF record may not establish an accountable domain-name subsequent to | |||
| evaluation when inconclusive results are obtained. Owing to these | evaluation when inconclusive results are obtained. Owing to these | |||
| conditions, there is no reasonable strategy that can be used to | conditions, there is no reasonable strategy that can be used to | |||
| mitigate the potential harm created by a distributed SPF script | mitigate the potential harm created by a distributed SPF generated DoS | |||
| generated DoS attack. To estimate the potential for the SPF script | attack. To estimate the potential for the SPF generated threat, the | |||
| generated threat, the level of network amplification is considered | level of network amplification is considered. | |||
| for this SPF DNS scripting scheme. | ||||
| A typical stance taken when discussing DoS concerns is that there are | A typical stance taken when discussing DoS concerns is that there are | |||
| other network amplification techniques to facilitate DoS exploits. | other network amplification techniques to facilitate DoS exploits. | |||
| One such exploit utilizes DNS servers. This exploit depends upon a | One such exploit utilizes DNS servers. This exploit depends upon a | |||
| lookup to be amplified by the difference between the query size and | 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 | that of the answer, in addition to the number of queries made in a | |||
| recursion process. To roughly estimate the network impact created by | recursion process. To roughly estimate the network impact created by | |||
| DNS UDP traffic, 1.3 queries will be assumed to occur on average from | 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 | every DNS lookup, with an average query size of 100 bytes and an | |||
| average answer of 500 bytes. Based upon these coarse assumptions, | average answer of 500 bytes. Based upon these coarse assumptions, the | |||
| the resulting DNS amplification is about 13 to 1 when the source IP | 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 | address of the lookup is also spoofed to be that of the targeted | |||
| domain. Some techniques have increased the level of this exploit by | domain. Some techniques have increased the impact of this exploit by | |||
| employing the [RFC2671] EDNS0 extension to query large RRsets that | employing the [RFC2671] EDNS0 extension to query large RRsets that | |||
| exceed the network MTU, and cause packet fragmentation. This | exceed the network MTU, and cause packet fragmentation. This | |||
| technique can achieve an impact with about a 60 times amplification, | technique can achieve an impact with about a 60 times amplification, | |||
| however the source of the large RRset can be identified. | however the source of the large RRset can be identified. | |||
| About 1 K bytes of outbound TCP traffic may be needed to send a small | 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 | SMTP message. SPF records can invoke 100 DNS lookups when evaluating | |||
| evaluating a single domain-name. In estimating the targeted | a single domain-name. In estimating the targeted amplification, the | |||
| amplification, the number of common DNS transactions is multiplied by | number of common DNS lookups is multiplied by the number of recipients | |||
| the number of recipients in different domains, the different domain- | in different domains, the different domain- names evaluated within the | |||
| names evaluated within the same message, and each sequential MHS that | same message, and each sequential MHS that does not share a common DNS | |||
| does not share a common DNS cache. A message sent to only 1 | cache. A message sent to only 1 recipient who also utilize SPF | |||
| recipient who also utilize SPF evaluation in their MUA could then | evaluation in their MUA could then create about 312 to 1 network | |||
| create about 312 to 1 network amplification directed toward a | amplification directed toward a targeted domain. As a comparison, | |||
| targeted domain. As a comparison, evaluating domain-names using SPF | evaluating domain-names using SPF represents about 24 times the threat | |||
| represents about 24 times the threat caused by an exploit using | caused by an exploit using recursive DNS, and about 5 times the threat | |||
| recursive DNS, and about 5 times the threat caused by the use of | caused by the use of EDNS0. Unlike the EDNS0 technique however, the | |||
| EDNS0. Unlike the EDNS0 technique however, the source of the problem | source of the problem remains hidden. | |||
| remains hidden. | ||||
| The network amplification exploit using SPF may also leverage a | The network amplification exploit using SPF may also leverage a | |||
| provider's SMTP servers that are available from systems an attacker | provider's SMTP servers that are available from systems an attacker | |||
| may have compromised. It is common for tens of thousands of | may have compromised. It is common for tens of thousands of | |||
| compromised systems to act in concert to disseminate spam, while each | compromised systems to act in concert to disseminate spam, while each | |||
| system may conform to normal use profiles. These spam messages could | system may conform to normal use profiles. These spam messages could | |||
| have a small list of recipients that further amplify the level of the | have a small list of recipients that further amplify the level of the | |||
| attack. Perhaps these messages contain an average of 10 recipients. | attack. Perhaps these messages contain an average of 10 recipients. | |||
| These messages may purport to be from email-addresses with random | These messages may purport to be from email-addresses with random | |||
| local names and sub-domains, beneath a list of top level domains. | local names and sub-domains, beneath a list of top level domains. All | |||
| All of these different domains can nevertheless reference similarly | of these different domains can nevertheless reference similarly | |||
| targeted SPF records. The messages in the attack could be a stock | targeted SPF records. The messages in the attack could be a stock tip | |||
| tip ending up in a spam folder. No single message may convey the | ending up in a spam folder. No single message may convey the same | |||
| same information, and yet still target the same victim regardless who | information, and yet still target the same victim regardless who | |||
| appears to be the author, or which folder is ultimately selected to | appears to be the author, or which folder is ultimately selected to | |||
| receive the message. | receive the message. | |||
| (1.3 x (100+500))/1000 = .78 DNS/SMTP Gain Factor | (1.3 x (100+500))/1000 = .78 DNS/SMTP Gain Factor | |||
| SPF Script Network Amplification at victim domain: | SPF Network Amplification at victim domain: | |||
| RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | 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 2 x 1 x .78 = 312 | |||
| 100 x 2 x 1 x 10 x .78 = 1560 | 100 x 2 x 1 x 10 x .78 = 1560 | |||
| SMTP Name Path Network Amplification at victim domain: | SMTP Name Path Network Amplification at victim domain: | |||
| RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | RR x MHS x Domain-Names x Recipients x DNS/SMTP = Gain | |||
| 1 x 2 x 2 x 1 x .78 = 3 | 1 x 2 x 2 x 1 x .78 = 3 | |||
| The SPF script facilitates canvassing by a covert DNS server for | SPF facilitates canvassing by a covert DNS server for domains that | |||
| domains that utilize SPF evaluations and also facilitates a sustained | utilize SPF evaluations and also facilitates a sustained DoS attack | |||
| DoS attack based upon this knowledge. Without altering the SPF | based upon this knowledge. Without altering the SPF record, | |||
| script, local-part label macros provided by SPF can instantiate | local-part label macros provided by SPF can instantiate different | |||
| different queries for a series of messages from the same set of | queries for a series of messages from the same set of domains. Using | |||
| domains. Using this technique, in addition to ensuring the DNS | this technique, in addition to ensuring the DNS information has not | |||
| information has not been locally cached to inundate the targeted | been locally cached to inundate the targeted domain with DNS queries, | |||
| domain with DNS transactions, this will also flood the local DNS | this will also flood the local DNS cache which may expel previously | |||
| cache which may expel previously obtained information prior to its | obtained information prior to its normal expiration. | |||
| 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 | ||||
| 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]. The | ||||
| name-based path registration alternative to SPF starts by verifying | ||||
| the EHLO; see [I-D.crocker-csv-csa]. 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 using SPF to evaluate a domain-name risks the integrity of DNS | |||
| just one or two steps. The first steps ensures the EHLO of the MTA | itself. A poisoning exploit often attempts to both flood the DNS | |||
| is directly verified with a single DNS transaction. Once the EHLO is | answering for the RR being poisoned, and to gain access to the DNS | |||
| verified, and when the EHLO is within the domain-name in question, no | whose cache is to be poisoned. Both of these efforts are facilitated | |||
| second step is needed. Otherwise, the second step attempts to | by SPF. SPF also provides the ability to query a covert DNS server | |||
| establish a domain association by making a single forward reference | that tracks the source IP address, ports, and Transaction IDs of DNS | |||
| PTR RRset lookup from the domain in question. These PTR RRsets would | queries to improve upon subsequent construction and the timing of | |||
| simply list the provider's root domains used by the owner of the | poison answers. | |||
| 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. The Exploit Example | 4. The Exploit Example | |||
| This section and the accompanying appendix information is in response | This section and the accompanying appendix information is in response | |||
| to requests made by a few large providers. Explaining the threat in | to requests made by a few large providers. Explaining the threat in | |||
| general terms proved difficult for many to understand. This example | general terms proved difficult for many to understand. This example | |||
| represents one of many possible techniques that are enabled by the | represents one of many possible techniques that are enabled by the | |||
| various SPF script parsing applications. Other techniques can | various SPF implementations. Other techniques can further increase | |||
| further increase the severity of such an attack, but are not | the severity of such an attack, but are not reviewed. The | |||
| reviewed. As with any script, the permutations of possible actions | permutations of possible actions are incredibly vast. | |||
| are incredibly vast. | ||||
| This Exploit Example makes use of script parser capabilities in many | This Exploit Example works with many SPF libraries, although libspf2 | |||
| SPF libraries, although libspf2 by Wayne Schlitt et al, by default, | by Wayne Schlitt et al, by default, is at half the recommended number | |||
| is at half the recommended number of RRs to be processed within an MX | of RRs to be processed within an MX RRset. It is not uncommon for an | |||
| RRset. It is not uncommon for an RRset to exceed this lowered limit. | RRset to exceed this lowered limit. For example, more than this | |||
| For example, more than this number of MX RRs are found within | number of MX RRs are found within t-online.de or nokia.com. These | |||
| t-online.de or nokia.com. These domains also do not publish SPF TXT | domains also do not publish SPF TXT records, which means even when a | |||
| records, which means even when a default SPF script containing the MX | default ("best guess") SPF record containing the MX lookup mechanism | |||
| lookup mechanism is used instead, the lowered RRset cut-off randomly | is used instead, the lowered RRset cut-off randomly prevents some MX | |||
| prevents some MX RRs from being examined. | RRs from being examined. | |||
| Although several libraries impose the recommended limit, the original | Although several libraries impose the recommended limit, the original | |||
| SPF script's limiting mechanism was recursion depth, that contained | SPF specification draft's limiting mechanism was recursion depth, that | |||
| the DNS transactions by the number of mechanisms that could be | contained the DNS transactions by the number of mechanisms that could | |||
| defined within 20 and changed to 10 additional SPF scripts. This | be defined within 20 and changed to 10 additional SPF records. This | |||
| recursive method allows for exceedingly high numbers of DNS | recursive method allows for exceedingly high numbers of DNS | |||
| transactions. There are several other recent libraries where no | transactions. There are several other recent libraries where no | |||
| limits are imposed upon the number of MX RRsets, other than the | limits are imposed upon the number of MX RRsets, other than the number | |||
| number returned within the MX lookup. SPF requires the acquisition | returned within the MX lookup. SPF requires the acquisition of the | |||
| of the TXT SPF record, which may then direct queries to 10 or 11 | TXT SPF record, which may then direct queries to 10 or 11 other | |||
| other domains. Most would consider that approach as mandating 10 | domains. Most would consider that approach as mandating 10 times the | |||
| times the number of DNS transactions, but SPF also adds highly risky | number of DNS transactions, but SPF also adds highly risky indirection | |||
| indirection enabled through SPF script and macro expansion. | enabled through macro expansion. | |||
| Taking advantage of just one level of indirection made possible by | Taking advantage of just one level of indirection made possible by SPF | |||
| SPF macros, the Exploit Example closely matches the initial estimates | macros, the Exploit Example closely matches the initial estimates made | |||
| made in Section 3, but where the request increases, the response is | in Section 3, but where the request increases, the response is reduced | |||
| reduced by about the same amount. The Example Exploit therefore | by about the same amount. The Example Exploit therefore represents a | |||
| represents a fairly symmetrical attack, and requires little knowledge | fairly symmetrical attack, and requires little knowledge of the | |||
| of the victim's DNS information. The traffic required to establish | victim's DNS layout. The traffic required to establish both the TXT | |||
| both the TXT and MX resource record sets should be excluded from the | and MX resource record sets should be excluded from the gain | |||
| gain estimates, as the attack is able to take advantage of a | estimates, as the attack is able to take advantage of a difference | |||
| difference between negative cache retention, and the TTL of these | between negative cache retention, and the TTL of these RRsets. | |||
| RRsets. | ||||
| Often negative caching is for a few minutes, but the RRset could be | Often negative caching is for a few minutes, but the RRset could be | |||
| retained many hours. After the requesting DNS servers have been | retained many hours. After the requesting DNS servers have been | |||
| seeded, the level of the attack could maintain a steady barrage while | seeded, the level of the attack could maintain a steady barrage while | |||
| requiring far less effort. The Time-To-Live for negative DNS caching | requiring far less effort. The Time-To-Live for negative DNS caching | |||
| may be determined by the recipient, or represent the lesser of the | may be determined by the recipient, or represent the lesser of the | |||
| SOA TTL or the SOA MINIMUM field, depending upon the recipient's | SOA TTL or the SOA MINIMUM field, depending upon the recipient's | |||
| implementation, see [RFC2308]. | implementation, see [RFC2308]. | |||
| The attacker would initially populate TXT and MX RRsets that point | The attacker would initially populate TXT and MX RRsets that point | |||
| toward the victim's domain. Referencing different MX RRsets does not | toward the victim's domain. Referencing different MX RRsets does not | |||
| require an additional SPF TXT script. Instead, the macro expansion | require an additional SPF TXT record. Instead, the macro expansion | |||
| capability can be used to reference a vast array of MX records, as | capability can be used to reference a vast array of MX records, as | |||
| illustrated by the Example Exploit which uses the local-part as a | illustrated by the Example Exploit which uses the local-part as a | |||
| selector. Optimally, this reference would cycle at a period longer | selector. Optimally, this reference would cycle at a period longer | |||
| than the resolver's negative cache retention period. A reference to | than the resolver's negative cache retention period. A reference to | |||
| a covert DNS server that replicates the SOA record parameters of the | a covert DNS server that replicates the SOA record parameters of the | |||
| victim could signal the optimal cycle period. | victim could signal the optimal cycle period. | |||
| The level of attack described in the presentation made for The DNS | The level of attack described in the presentation made for The DNS | |||
| Operations, Analysis, and Research Center (DNS-OARC) called "Recent | Operations, Analysis, and Research Center (DNS-OARC) called "Recent | |||
| DNS Reflector Attacks From the Victim and the Reflector POV" by Frank | DNS Reflector Attacks From the Victim and the Reflector POV" by Frank | |||
| Scalzo of Verisign, see [r-VS-Reflect] indicated the 35,000 | Scalzo of Verisign, see [r-VS-Reflect] indicated the 35,000 | |||
| amplifying reflectors caused on average 144kbps (18KBps) to be | amplifying reflectors caused on average 144kbps (18KBps) to be | |||
| exchanged with the victim. A similar level of attack could be | exchanged with the victim. A similar level of attack could be | |||
| achieved by the Example Exploit occurring 0.28 times a second or 17 | achieved by the Example Exploit occurring 0.28 times a second or 17 | |||
| times per minute. When 2 domains are being examined, as may occur | times per minute. When 2 identities are being examined, as may occur | |||
| with Sender-ID, this level of attack would require just 8.5 messages | with Sender-ID, this level of attack would require just 8.5 messages | |||
| per minute. | per minute. | |||
| Processing 8.5 messages per minute would represent a very small | Processing 8.5 messages per minute would represent a very small | |||
| percentage of the emails already being handled by many providers. | percentage of the emails already being handled by many providers. | |||
| Already a majority of these emails are considered abusive. A large | Already a majority of these emails are considered abusive. A large | |||
| provider may issue as many as 25,000 messages per minute and receive | provider may issue as many as 25,000 messages per minute and receive | |||
| emails at twice that rate. A strategy that sends messages through | emails at twice that rate. A strategy that sends messages through | |||
| network providers addressed to 10 individuals on average from 35,000 | network providers addressed to 10 individuals on average from 35,000 | |||
| compromised systems at 50 per hour represents a scale of concerted | compromised systems at 50 per hour represents a scale of concerted | |||
| attack commonly seen. If these messages also get processed by spam | attack commonly seen. If these messages also get processed by spam | |||
| filtering applications that also uses SPF/Sender-ID, the attack rate | filtering applications that also uses SPF/Sender-ID, the attack rate | |||
| could then drop to 25 per hour and still sustain the same barrage. | could then drop to 25 per hour and still sustain the same barrage. | |||
| This type of activity could be considered a good way to leverage | This type of activity could be considered a good way to leverage | |||
| skipping to change at page 10, line 18 | skipping to change at line 306 | |||
| network providers addressed to 10 individuals on average from 35,000 | network providers addressed to 10 individuals on average from 35,000 | |||
| compromised systems at 50 per hour represents a scale of concerted | compromised systems at 50 per hour represents a scale of concerted | |||
| attack commonly seen. If these messages also get processed by spam | attack commonly seen. If these messages also get processed by spam | |||
| filtering applications that also uses SPF/Sender-ID, the attack rate | filtering applications that also uses SPF/Sender-ID, the attack rate | |||
| could then drop to 25 per hour and still sustain the same barrage. | could then drop to 25 per hour and still sustain the same barrage. | |||
| This type of activity could be considered a good way to leverage | This type of activity could be considered a good way to leverage | |||
| efforts. While sending spam, perhaps containing malware, | efforts. While sending spam, perhaps containing malware, | |||
| authoritative DNS servers are taken out by knowing which domains | authoritative DNS servers are taken out by knowing which domains | |||
| incorporate poorly considered, and ultimately fatally flawed, SPF | incorporate poorly considered, and ultimately fatally flawed, SPF | |||
| parsers. Once the authoritative DNS servers are disabled, the same | implementations. Once the authoritative DNS servers are disabled, the | |||
| SPF script can illicit queries through thousands of provider's DNS | same SPF record can illicit queries through thousands of provider's | |||
| servers, and also trigger a barrage of poison answers. These attacks | DNS servers, and also trigger a barrage of poison answers. These | |||
| can be done through two levels of indirection where it would be | attacks can be done through two levels of indirection where it would | |||
| difficult to correlate what domain is inducing the problem, or how it | be difficult to correlate what domain is inducing the problem, or how | |||
| can be stopped. The SPF RRsets causing trouble will not appear on a | it can be stopped. The SPF RRsets causing trouble will not appear on | |||
| log. In the Example Exploit, the message is accepted with a neutral | a log. In the Example Exploit, the message is accepted with a neutral | |||
| status without any evidence it was related to the victim's domain. | status without any evidence it was related to the victim's domain. | |||
| SPF/Sender-ID reduces security. Although there was already "A DNS RR | SPF/Sender-ID reduces security. Although there was already "A DNS RR | |||
| Type for Lists of Address Prefixes (APL RR)" [RFC3123] that could | Type for Lists of Address Prefixes (APL RR)" [RFC3123] that could | |||
| serve extremely well for white-listing, SPF was developed as a method | serve extremely well for white-listing, SPF was developed as a method | |||
| that avoids declaring who are the sending system's administrators and | that avoids declaring who are the sending system's administrators and | |||
| offers the feature-rich/security-poor scripting found with HTTP/TCP. | offers the feature-rich/security-poor scripting found with HTTP/TCP. | |||
| Sender-ID was even originally specified using XML contained within | With the highly distributive anonymous nature of email, reducing | |||
| 2KB DNS resource records, expecting DNS/TCP would not become a | security while crime is rampant, is foolhardy at best. SPF/ Sender-ID | |||
| problem. With the highly distributive anonymous nature of email, | continues to place the DNS infrastructure at risk. | |||
| reducing security while crime is rampant, is foolhardy at best. SPF/ | ||||
| Sender-ID continues to place the DNS infrastructure at risk. Adopt | ||||
| EHLO verification, Name-Path registration, and the use of APL RRs. | ||||
| Drop the use of SPF. Such a change would offer additional security, | ||||
| without actually reducing it instead. Don't be afraid to use binary | ||||
| with DNS. | ||||
| 5. IANA Considerations | 5. IANA Considerations | |||
| There are no registrations required by IANA. | There are no registrations required by IANA. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| This document describes a threat to SMTP created by the evaluation of | This document describes a threat to SMTP created by the evaluation of | |||
| message related domain-names using SPF scripts. This document | message related domain-names using SPF records. | |||
| 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]. | ||||
| 7. Informative References | 7. Informative References | |||
| [I-D.crocker-csv-csa] | ||||
| Crocker, D., "Client SMTP Authorization (CSA)", | ||||
| draft-crocker-csv-csa-00 (work in progress), October 2005. | ||||
| [I-D.crocker-email-arch] | [I-D.crocker-email-arch] | |||
| Crocker, D., "Internet Mail Architecture", | Crocker, D., "Internet Mail Architecture", | |||
| draft-crocker-email-arch-04 (work in progress), | draft-crocker-email-arch-04 (work in progress), | |||
| March 2005. | March 2005. | |||
| [I-D.ietf-dkim-base] | ||||
| Allman, E., "DomainKeys Identified Mail Signatures | ||||
| (DKIM)", draft-ietf-dkim-base-02 (work in progress), | ||||
| May 2006. | ||||
| [I-D.otis-smtp-name-path] | ||||
| Otis, D., "SMTP Name Path Registration", | ||||
| draft-otis-smtp-name-path-00 (work in progress), | ||||
| April 2006. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS | [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS | |||
| NCACHE)", RFC 2308, March 1998. | NCACHE)", RFC 2308, March 1998. | |||
| [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", | |||
| RFC 2671, August 1999. | RFC 2671, August 1999. | |||
| [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, | |||
| April 2001. | April 2001. | |||
| [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, | ||||
| April 2001. | ||||
| [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes | [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes | |||
| (APL RR)", RFC 3123, June 2001. | (APL RR)", RFC 3123, June 2001. | |||
| [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", | |||
| RFC 4406, April 2006. | RFC 4406, April 2006. | |||
| [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail | [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail | |||
| Messages", RFC 4407, April 2006. | Messages", RFC 4407, April 2006. | |||
| [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) | [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) | |||
| skipping to change at line 2890 | skipping to change at line 2775 | |||
| Copyright Statement | Copyright Statement | |||
| Copyright (C) The Internet Society (2006). This document is subject | Copyright (C) The Internet Society (2006). This document is subject | |||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| vim:tw=73 sw=3 sts=3 | ||||
| End of changes. 31 change blocks. | ||||
| 231 lines changed or deleted | 130 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||