[Top] [All Lists]

Re: SPF and IPv6

2008-01-13 21:04:06

On Jan 9, 2008, at 7:48 PM, Frank Ellermann wrote:

Even if a "no answer" or "no domain" limitation were to become specified as a recommended limitation for SPF parsing routines
The number of transactions that can be induced by a cached SPF record remains critically relevant to a DDoS concern

The proposed 2..5 limit in the "rebuttal" (one way to implement an existing SHOULD in RFC 4408) reduces your worst case of 100 bogus overlong attack-queries to 2..5. Implementation details, after reaching 3..6 just trying this *again* for the next mail of the attacker is not the smartest thing to do.

Botnets remain a threat. A direct attack consumes the bot's resources and allows BCP 38 detection. Even DNS open recursive reflective attacks allow bots to remain hidden until BCP 38 is instantiated.

The SPF DoS draft's macro exploit example with an MX mechanism caused some confusion. The draft didn't clarify the motivations for using SPF as an attack mechanism. SPF, as defined and typically implemented, allows botnets to become orders of magnitude more dangerous and not controllable by BCP 38. SPF allows bots to remain hidden, uncontrolled, while also staging a free attack.

SPF parsing routines currently enable DNS resolver reflected attacks at levels significantly above that of the spam traffic acting as a trigger. Assuming the SPF macro exploit concern causes "no answer", or "no domain" responses to limit the extent of SPF macro induced transactions, then ensuring the critical recipient adoption necessitates exclusive publishing of a different SPF record version.

Such a change could help limit the magnitude of SPF exploit attacks triggered by spam. However, adding an answer failure limit would not protect domains publishing MX or A wildcards. In addition, rather than a maximum of 100 targeted transactions, quitting at N answer failures limits the number of targeted transactions to N times 4. Even so, the SPF macro exploit still allows the targeted transaction attacks to be free and beyond BCP 38 control. A botnet is dangerous at 1:1 gains, and extremely dangerous at 100:1.

Your "fast flux local parts" idea selects malicious MX records, but after reaching 3..6 once it's clear that the policy is up to no good, or something on the side of a legit sender has to be fixed a.s.a.p.

Spam exploiting the SPF local-part macro can induce a series of new type 99, TXT, A, AAAA, or MX RR transactions from cached SPF records. SPF routines return Pass, Fail, SoftFail, Neutral, TempError, PermError, and None. Due to SPF expansion of macros, even a PRA email- address within the same domain as MailFrom still requires repeating an entire SPF process whenever PASS is not first obtained.

Email path registration safe for domains using wildcards must first verify SMTP client names and then determine authorization (path registration) with records like TPA labels. SMTP client authorization by-name scales well beyond that of SPF. SMTP client authorization by- name requires only one transaction, avoids manual entry of address CIDRs, and can directly merge with DKIM domain signing policies.

Making SPF safer requires:

1) Changing the record version and specifying the scope of its coverage

2) Excluding processing of prior SPF versions

3) Limiting answer failures and returning TempError, instead of as specified by the ALL mechanism

4) Limiting the MX mechanism to 1 where host resolution min/max is specified

5) Prohibiting macro expansion for all but the EXP mechanism record

6) Delaying subsequent processing after time-outs until outstanding DNS transactions complete

7) Removing the Exists mechanism and dropping SoftFail

8) Specifying None is to be handled as Neutral

A different and safer SPF strategy could be adopted, but it is unlikely. Why not consider SMTP client authorization by-name instead?