Sender Policy Framework

Table of Contents

• Introduction
• Hints for understanding the (original) Document
• Clarifications required
• Rebuttal to the Main Point of the Document
• Rebuttals to Minor Points of the Document
• Analysis Assumptions

Introduction

Douglas Otis has published an Internet-Draft called draft-otis-spf-dos-exploit that describes a worst-case SPF record scenario that can be employed to perform a denial of service (DoS) attack against an uninvolved victim.

The last revision of the draft is draft-otis-spf-dos-exploit-01 (local copy).

Julian Mehnle has created a cleaned-up edition of the document that clarifies the terminology and omits all the advertising of supposed SPF alternatives that is irrelevant to the actual DoS attack described: draft-otis-spf-dos-exploit-01-english-noplugs (diffs: side-by-side, wdiff).

Hints for understanding the (original) Document

• The term "SPF script" is used synonymously to both "SPF" and "an SPF record". This is confusing.
• The term "DNS transaction" is used mostly synonymously to "DNS lookup".
• Readers should try to ignore the polemics and any statements that are unrelated to the actual DoS attack scenario, or that are trying to advertise Otis' draft-otis-smtp-name-path.
• Readers should begin by looking at the example DNS configuration in appendix A and try to understand its mechanics. Any effects due to DNS domain name compression should be ignored at first – they only play a minor role in the attack scenario.
• In various places, a number of "domain-names" per e-mail message greater than 1 (e.g. 2) is assumed. This implies that multiple identities per message are subjected to an SPF check, which is the case only when both a HELO and an MFROM check, or both an MFROM and a PRA check, are performed.
• Section 3, paragraph 2 talks about a "recursive DNS" attack merely for the sake of later (in paragraph 3) comparing its traffic amplification factor (allegedly 13:1) to that of an SPF-based attack (allegedly 312:1).
• Section 3, paragraph 3 refers to an alleged traffic amplification factor of 321:1 for an SPF-based attack. Regardless whether this allegation is correct, note that this number is explained further down in section 3, in paragraph 5 (the table).

Clarifications required

• In section 3, paragraph 2, what exactly does "1.3 queries will be assumed to occur on average from every DNS lookup" mean?

Rebuttal to the Main Point of the Document

Otis' overall allegation is that SPF allows an attacker to publish an SPF DNS record that will cause an unwary 2nd-party to send abusive DNS query packets to a 3rd-party victim's domain name servers, basically achieving an amplification factor of packet numbers of 10 (since for every 10 queries induced against the victim, one query must still go to the attacker's domain). (A higher packet number amplification factor could theoretically be achieved by the attacker by choosing appropriate negative and positive TTLs, specifically depending on the configuration of the 2nd-party's and the victim's DNS infrastructure, which may not be completely visible from the outside.)

However, Otis is missing (or deliberately omitting) that the fact that SPF does not place a very strict limit (<<10) on the number of 3rd-party query referrals is not a weakness that is specific to SPF. In fact, this seems to be an entire class of weaknesses that is shared by several other frequently deployed DNS record types that allow 3rd-party query referrals, such as NS and MX. Any of these record types refer resolvers to other records that are potentially owned by a 3rd-party victim.

For example:

$ORIGIN attacker.dom.
@   IN  SOA  ns.attacker.dom. hostmaster.attacker.dom. ...
    IN  NS   0.victim.dom.
    IN  NS   1.victim.dom.
    IN  NS   ...
    IN  NS   9.victim.dom.

Or:

$ORIGIN attacker.dom.
@   IN  SOA  ns.attacker.dom. hostmaster.attacker.dom. ...
    IN  MX   0.victim.dom.
    IN  MX   1.victim.dom.
    IN  MX   ...
    IN  MX   9.victim.dom.

Contrary to SPF, the number of abusive referrals that can be delivered to an unwary 2nd-party in a single DNS packet can even be significantly larger than 10 (the limit inherent to SPF).

It seems that this class of weaknesses should best be addressed in DNS, SMTP, or SPF (etc.) client implementations by limiting the number of "void" DNS lookups, i.e. the number of lookups that are allowed to return an empty answer packet with RCODE 0 (NODATA) or 3 (NXDOMAIN) before the client implementation aborts the entire NS/MX/SPF record resolution process. The actual void-lookups limit would depend on the specific DNS application. (For example, a viable void-lookups limit for SPF might lie between 2 and 5.)

Rebuttals to Minor Points of the Document

• Section 3, paragraph 4 talks about

  1. "a provider's SMTP servers that are available from systems an attacker may have compromised", and
  2. "spam messages [that] could have a small list of recipients that further amplify the level of the attack"

  and adds these attack amplifications innate to (1) bot/zombie networks and (2) the SMTP multi-recipient feature to the amplification factor of the described SPF-based attack. This is orthogonal and a misappropriation, as such amplifications can take place without SPF.

Analysis Assumptions

Both the original draft-otis and this analysis are based on RFC 4408 processing limits. Pre-IETF SPF specifications had a significantly different approach for processing limits. No analysis of the pre-IETF SPF processing limits was attempted, but they are substantially more generous than the final RFC 4408 processing limits. See implementations for discussion on which libraries support RFC 4408 requirements.