ietf
[Top] [All Lists]

Re: TMDA backscatter

2007-10-15 06:25:11
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.  

And e-mail providers wishing to offer "per user policies" could also
create corresponding subdomains replacing local(_at_)domain(_dot_)example 
addresses by say user(_at_)local(_dot_)domain(_dot_)example addresses.  
Likewise 
attackers trying to cause havoc can use 
user(_at_)local(_dot_)domain(_dot_)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.

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.

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.

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).

Block all SPF records?

At least we won't need a new rfc-ignorant zone to implement this 
proposal... ;-)  

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.

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".

 Frank


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>