Re: TMDA backscatter

On Oct 16, 2007, at 5:00 AM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > Do you expect everyone to use inbound servers to send?
> No.  Of course I'd expect that mail to <postmaster> to the IP of an  
> MTA talking to an MX I care about works.  BTW, it would be nice if  
> only the MXs of the envelope sender address talk to other MXs, we  
> could then scrap SPF in this "inherent RMX" parallel universe.   
> Just decree that everybody has an implicit "v=spf1 mx a aaaa -all"  
> policy, what a dream.  Actually SPF is a clumsy approximation of  
> this dream.
Requiring MX for discovery eliminates additional transactions needed  
to assert no policy record or valid email domain.  However, the SPF  
or RMX concept is seriously flawed.
Defining valid sources might scale when done "by-name" but never "by- 
address".  By-Name is how MX records declare destinations.  PTR  
record-sets adjacent to an MX record could associate valid client  
domains.  Perhaps special names like "_NONE" or "_ANY" could be  
defined for PTRs under a _MX-OUT leaf.  DNS would then be able to  
return addresses needed to validate a specific client host-name  
within a single transaction, but not for all possible host-names.   
Being able to validate clients within an authorized source domain  
should safely satisfy your need for a protection mechanism.
Fully resolving just one MX record for either IPv4 and IPv6 addresses  
might necessitate 20 DNS transactions when permitting 10 MX targets.   
SPF allows 10 MX records, where each may contain 10 targets.  Unless  
IPv6 is excluded, subsequent transactions for both A and AAAA records  
might be needed where a high level of NXDOMAINs would be ignored.   
This means 10 x (10 + 10) or 200 DNS transactions satisfy SPF  
semantics for each email-address checked.  However, some suggest  
using SPF to authorize DKIM domains or PRAs first.  When DKIM or PRAs  
are not authorized, it is common to then check MAIL FROM.  Each  
message might therefore invoke 400 DNS transactions per message.   
Even after allowing this number of transactions, the resulting list  
may not encompass the addresses of all valid outbound hosts.
> > Use of MX records are normally predicated upon the sending of  
> > messages.
> Yes, I proposed a simplification of your DNS attack scenario based  
> on "call back verification" instead of SPF.  AFAIK "CBV" works by  
> connecting to an MX of the alleged sender, and trying a RCPT TO the  
> envelope sender address.  If that results in "unknown mailbox" the  
> receiver knows that the envelope sender address is dubious at best.
> Spammers also know this, that's why they forge "plausible"  
> addresses. An SPF FAIL cuts them off at this stage.  As long as  
> there are more than enough unprotected "plausible" (= surviving  
> CBV) addresses the spammers can carry on as is.
See above.

> > However, overall amplification is much less when a message  
> > triggers an automated response.
> When I got about 1,000 bogus bounces and other auto-replies per day  
> in 2004 I didn't care about other side effects, my mailbox was  
> almost unusable.
See above.

> > An automated response is likely to be filtered
> Filtering behind a POP3 modem connection is tricky, after all I  
> still wanted to get "good" bounces, challenges, and other auto- 
> replies.
> Filtering or rejecting auto-responses before final delivery needs  
> something in the direction of BATV plus good heuristics to identify  
> "non-standard" backscatter (as outlined in RFC 3834).
> BATV doesn't directly fight forgeries, it only stops backscatter  
> before final delivery (ideally rejecting it at the MX of the  
> alleged originator).  It's a nice scheme, use it if you can.  But  
> it won't help me (as receiver) to reject forged "mail from" Douglas  
> Otis.
See above.

> > SPF permits an enormous amount of DNS traffic to be directed  
> > toward an innocent, uninvolved domain.
> Well, I'd try something more direct when I'd wish to attack a  
> domain, your idea is IMO far too convoluted.
SPF enables a cached record to redirect the subsequent DNS  
transactions of a recipient.  In addition, SPF provides an attacker  
the means to manage a sequence of MX records independently from what  
is seen as the originator.
> And your claim that a domain under attack by bogus A or AAAA  
> queries caused by MX records of the attacker, based on CBV, SPF, or  
> what else, has no chance to find out who the attcker is, might be  
> also wrong.
Logs of the DNS and mail servers may provide clues about which  
domains appear to have staged the attack, but the domain visible to a  
mail server is able to transition rapidly which prevents any filter  
from curtailing an ongoing attack.
> The querying hosts can find out why they do this, and at that point  
> one or more name servers of the attacker (where he manages the  
> bogus MX records) are also known.
Finding one of perhaps hundreds of DNS servers used by an attacker  
will not offer a meaningful defence.  The ability to redirect DNS  
transactions afforded a cached SPF record ensures an attacker can  
escape any blocking effort.
> > Once the attack duration exceeds a recipient's negative caching,  
> > no additional resources of the attacker are consumed
> BTW, who determines the TTL of NXDOMAIN, can a zone under attack  
> tune this?
The recipient decides.  They may follow RFC2308 recommendations which  
is the lesser of either the SOA MINIMUM field or the SOA TTL.   
However some experience problems and truncate the duration.  Here is  
a common tip given to Windows users:
"By default these negative entries are cached for 5 mins.  But we can  
tweak the registry to NOT store negative entries at all!"
> > Even the attacking MX record might be unrelated to any domain  
> > found within the message.
> They're referenced by mx-mechanisms in the SPF policy of the  
> envelope sender, i.e. the attacker.  And this SPF policy record  
> still exists at least in the DNS cache of the receivers.  FWIW, the  
> querying hosts can find out what's going on.
How long will these records remain?  A single cached SPF record can  
do untold damage with its ability to redirect recipient  
transactions.  Rapidly changing these records will not consume much  
of an attackers resources.  Attackers are extremely adept at fast- 
fluxing DNS.  It is not 2004 any more.
> > Expect spammers to take advantage of this generous SPF gift.
> Don't confuse "spammers" and "attackers".  This might be the same  
> persons, but the roles are very different.  Spammers in their role  
> as spammer might wish to attack successful anti-spammers, but they  
> have no reason to prefer your attack strategy based on SPF where  
> they'd be forced to risk one of their own name servers.  I think  
> all attackers prefer to risk more anonymous resources like zombies.
Why do you think there is a difference between a zombie and a name  
server?  Why shouldn't a spammer offer an attacking service when it  
will not impact their spamming service?
> > RFC3464 represents a far better solution as it removes incentives.
> No, that's not true.  When my addresses were abused it was the  
> number of bogus DSNs and other auto-replies that bothered me most,  
> not the size of the DSNs.
RFC3464 removes incentives which affords greater protection at much  
smaller costs.  SPF is not the only tool available!
> And the incentive isn't to send spam indirectly in the form of a  
> DSN to the forged envelope sender, the incentive is to abuse an  
> unprotected "plausible" address.  SPF FAIL offers the protection.
Despite intentions, SPF creates a far graver danger.

> > Call back verification is not part of RFC2821?
> True, but I was talking about abusing CBV for an MX attack instead  
> of SPF's mx-mechanism, and you then hinted that normal RFC 2821  
> sending strategies won't query for addresses of all names found in  
> the MX records at once.  Actually I don't know what real MTAs do if  
> they get NXDOMAIN, do they wait before they try the next name ?
Regardless, it should not happen more than the number of targets  
contained within a single MX record.  This attack would also incur  
the message and MX record overhead.  While a concern, it is not in  
the same league.
> > Other solutions are able to prevent the DATA phase for spam. : )
> Whatever it might be, it didn't work for me back in 2004.  Victims  
> of backscatter can't wait for worldwide adoption of MTAMARK, CSV,  
> or "other solutions", they need something working now.  SPF works  
> as designed because it's in the best interest of spammers to stay  
> away from FAIL-protected addresses.
The same could have been said about the use of DDT as a pesticide.   
This attitude will likely require banning SPF before its use can be  
irradiated. : (
-Doug






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