ietf
[Top] [All Lists]

Re: TMDA backscatter

2007-10-11 02:44:42
Douglas Otis wrote:

Macro expansion and text strings can be combined with any SPF record
mechanism and CIDR mask.  Any email-address differing in just the
local-part must then be iteratively processed across the SPF record
set (up to 10 follow-on SPF records or mechanisms).

Yes, an attacker can use 10 mx mechanisms in his malicious policy for
domains under his control with names containing 10 different parts of
the LHS (local part) in his envelope sender address.

The SPF record is able to conclude with "+all" and still obtain a
PASS

Sure, a PASS for "mail from" unknown strangers only guarantees that 
bounces and other auto-replies won't hit innocent bystanders.  A PASS
can be still spam or an attack, but it won't create backscatter, that
is more or less the idea of SPF.

A single message can be sent to 100 different recipients.  100 x 100
= 10,000 DNS transactions!

The number of RCPT TO for a given MAIL FROM at the border MTA where
SPF is checked is irrelevant, it's evaluated once.  Actually the same
MAIL FROM at a given border MTA has no further effect while the SPF
and MX records of the attacker are still cached.  But of course an
attacker can send more mails to more domains with different envelope
sender addresses, and he can tune the TTL of his SPF and MX records.

Whatever he does, your attack scenario depends on the mx mechanism,
and you get an amplification factor of about 10 DNS queries to the
victim per DNS query to the attacker.

The attacker could also try to abuse "call back verification" with
his bogus MX records for a better amplification factor without SPF.

AFAIK SPF is so far the only protocol specifying "processing limits"
for DNS based attacks.  RFC 2821 certainly doesn't talk about it,
and I'm not aware of any processing limits wrt SRV or NS records.

Maybe you should propose some "MX processing limits" for 2821bis.

DKIM could be extended to avoid backscatter and replay abuse.

Hardly.  DKIM is intentionally independent of SMTP, it doesn't
look at the envelope sender address.  The envelope sender address
(aka return path, mail from, or bounce address) and the MX concept
are the essence of SMTP, anything else is syntactical sugar.

The PRA is the best approximation of the envelope sender address,
but DKIM also doesn't look at the PRA, it's not designed to fight
backscatter.  

Unfortunately, Sender-ID is being heavily promoted as the anti- 
phishing solution.  A problem not addressed by RFC4408.

RFC 4408 doesn't discuss PRA or phishing or 2822, it's about SMTP
and backscatter.  For discussions why the best approximation PRA
isn't good enough see the <http://www.openspf.org> pages.  

Using PRA as anti-phishing solution might make sense, with several
caveats addressed in the IESG note.  Unlike PRA pure DKIM offers
no FAIL, it can help to identify various kinds of "non-phishing".
That's not the same as "anti-phishing".

Had the recipient known who sent the message, SPF would not be
needed.

Indeed, SPF is used to figure out when "originator as indicated
in the reverse path" in RFC 2821 is acceptable (PASS) or should
be rejected (FAIL) at a border MTA.  Other uses of SPF are at best
nice to have, and in the worst case dangerous.

Oops, bell.ca still has this ridiculous policy, that certainly  
won't help them to reduce backscatter.

Obviously that is not why the SPF record is published.

If all they want is a PASS they could use a short "v=spf1 +all"
without the other PASSing gibberish they're publishing now.

At least the "+all" discourages use of dangerous SPF libraries

No, "v=spf1 +all" and more verbose policies with the same effect
are perfectly valid and supported by SPF libraries, dangerous or
otherwise.  

the example attack scenario is not prevented by any RFC4408 
SHOULD or MUSTs

 <http://tools.ietf.org/html/rfc4408#section-10.1>
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries.  For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory usage
| and DoS attacks.

 Frank


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

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