Re: SPF and IPv6
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
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
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?