Re: TMDA backscatter

[Douglas Otis <dotis at mail-abuse.org>]

On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > By using the local-part in a spam campaign, one cached SPF record  
> > is able to reference an unlimited sequence of MX records.
>
> In theory IANA could publish one _spf.arpa "v=spf1 mx a aaaa -all"  
> record, and everybody could use it with "v=spf1  
> redirect=_spf.arpa". That one SPF record can (kind of) reference an  
> unlimited number of MX records doesn't depend on SPF's local-part  
> macro.

This adds perhaps 21 useless DNS transactions for each email  
received?  Do you expect everyone to use inbound servers to send?

> And e-mail providers wishing to offer "per user policies" could  
> also create corresponding subdomains replacing local at domain.example  
> addresses by say user at local.domain.example addresses.  Likewise  
> attackers trying to cause havoc can use user at local.domain.example  
> addresses, they don't need SPF's local part macro for this purpose.
>
> After all in your attack scenario it's the attacker who controls  
> the MX records pointing to bogus addresses in the zone of the victim.

Use of MX records are normally predicated upon the sending of  
messages.  When sending a message, MX records may have a potential  
DNS traffic amplification of about 10.  However, overall  
amplification is much less when a message triggers an automated  
response.  An automated response is likely to be filtered, and the  
sender risks being blocked, whether or not the MX record is doing  
something nefarious.  Many situations can achieve this level of  
network amplification.

However, SPF's macros transforms a spam related attack into being  
completely free without tainting the messages.  Sending spam should  
be considered a given as it represents a large portion of today's  
traffic.  SPF permits an enormous amount of DNS traffic to be  
directed toward an innocent, uninvolved domain.  Once the attack  
duration exceeds a recipient's negative caching, no additional  
resources of the attacker are consumed!  The attack can come from  
anywhere, is not easily traced, and, beyond universal banning of SPF  
records, there is no defence!  ACLs on DNS will not help, nor will  
BCP 38.  This attack is likely to continue for a long duration.

> > Spammers often send messages continuously.  A spam campaign can  
> > come from any source, purport to be from any domain, and yet  
> > attack the same innocent victim which can not be identified by  
> > examining the message.
>
> Your attack scenario has nothing to with a spam campaign, the goal  
> of a spam campaign is to send unsolicited mails to receivers.  The  
> goal of your attack scenario is to flood a zone with bogus and huge  
> A or AAAA queries.  And in your scenario the mail cannot purport to  
> come from any domain, it has to come from domains under the control  
> of the attacker where he manages his bogus MX records.

SPF adds a layer of indirection.  SPF allows the local-part of spam  
to generate DNS transactions without consuming additional resources  
of attackers once their SPF record has been cached!  The attack can  
then query any MX, A, AAAA, PTR, and TXT records from any domain  
unrelated to message content.  Even the attacking MX record might be  
unrelated to any domain found within the message.  SPF's added  
indirection provides spammers a complete disguise.  Recipients using  
SPF are to know which messages are staging an attack.  This is true  
even when they do not wish to play a role in a reported ongoing  
attack.  Expect spammers to take advantage of this generous SPF  
gift. : (

> > Compared to an SPF related attack, most auto-replies will consume  
> > a greater amount of an attackers resources, identify the source of  
> > the attack, and not achieve the same level of amplification.
>
> Backscatter doesn't consume resources of the spammer (apart from  
> sending the UBE with a forged envelope sender address), and it can  
> be "mail from" any "plausible" address, not identifying the real  
> source.  That's precisely the problem solved by SPF FAIL and PASS.

RFC3464 represents a far better solution as it removes incentives.

> > SPF enables a long duration DDoS attack.
>
> Sorry, from my POV you still arrive at "MX records can be abused",  
> not limited to SPF (or rather only limited if done using SPF).

Of course MX records can be abused.  SPF increases the potential  
level of abuse by a factor of 10 or 20.  With SPF macro's, abuse also  
becomes completely free.

> > Block all SPF records?
>
> At least we won't need a new rfc-ignorant zone to implement this  
> proposal... ;-)

Prevention might require DNS servers be modified to exclude SPF  
records.  Do not expect compliance without some form of blocking  
imposed.

> > > Maybe you should propose some "MX processing limits" for 2821bis.
>
> > Most systems are fairly careful about where they send messages to  
> > avoid being blocked, nor would the normal use of MX records  
> > require all targets be resolved.  Timeouts recommended by RFC2821  
> > ensure this operation remains fairly safe, unlike that for SPF.   
> > Even the packet limitation of DNS provides a fairly reasonable limit.
>
> I'm not sure that "call back verification" schemes follow the  
> "sending strategy" (4.5.4.1) in RFC 2821, after all they don't send  
> any DATA.

Call back verification is not part of RFC2821?

> You could squeeze quite a lot of names in the reply to an MX query,  
> that's why SPF has an explicit limit 10.  SMTP also doesn't specify  
> size limits for MX queries.
>
> > DKIM can be processed prior to acceptance
>
> Yes, but unlike SPF not before DATA.  I skip the "anti-phishing"  
> discussion because it's not directly related to "backscatter".

Other solutions are able to prevent the DATA phase for spam. : )

-Doug





_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf