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  
> 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?
-Doug