Re: TMDA backscatter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Oct 10, 2007, at 12:12 AM, Frank Ellermann wrote:

Douglas Otis wrote:

Due to the macro nature of SPF, full processing is required for each name evaluated.

If what you call "full processing" is the procedure to fetch the policy record of the domain in question, and match the connecting IP against this policy for a PASS / FAIL / "DUNNO" verdict, then this doesn't depend on using macros or not in the policy.

IP address evaluations to determine a PASS / FAIL / DUNNO verdict may require the expansion of macros inserted into SPF records. SPF macros have the following syntax:

%{symbol | rev-label-seq | # of right-most labels | chars-into “.” }

rev-label-seq = “r”

chars-into “.” = “-” | “+” | “,” | “/” | “_” | “=”

# of right-most labels = 1 - 128

symbol =
 s = email-address or EHLO (initial parameter)
 l = left-hand side of email-address (initial parameter)
 o = right-hand side of email-address  (initial parameter)
 d = email-address domain or EHLO (initial parameter)
 i = SMTP client IP addr decimal octet labels (initial parameter)
 p = r-PTR domain with IP addr validated (not initial parameter)
 v = "in-addr" IPv4, or "ip6" if IPv6 (auto generated)
 h = EHLO host-name  (initial parameter)

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

For example, an MX record may be located using a label derived from some component of the email-address local-part. The address for each target name within the MX record must then be resolved and perhaps masked prior to checking for a match. The macro expansion therefore permits the same SPF record to cause a different set of DNS transactions to occur over the duration of a spam campaign. The macro expansion provides the spammer a means to fully leverage recipient resources any number of times against any domain. The domain being queried can be wholly unrelated to a domain within the email being evaluated. In otherwords, a flood of queries generated by spam recipients can target any innocent bystander. The SPF record is able to conclude with "+all" and still obtain a PASS while staging their completely free attack.

Maybe you mean that macros can reduce the chances for a DNS cache hit, e.g. for per-user-policies based on the local part macro.

The per-user-policy feature of SPF makes a reflected amplification attack entirely free for the spammer. Each new name evaluated from their cached records can generate 508 KB in DNS traffic, a higher amplification than that achieved in an open recursive attack.

The SPF group dismissed this concern by suggesting DNS amplifications could be further increased by including a series of bogus NS records.

A single message can be sent to 100 different recipients. 100 x 100 = 10,000 DNS transactions! Each message might be evaluated twice, once for the PRA, and then again for the MAIL FROM. Who knows, perhaps this might include the DKIM domain if the use of SPF is not denounced.

With SPF, the recipient might be interested in the PRA, or MAIL FROM.

When I talk about SPF it's generally RFC 4408, i.e. MAIL FROM and HELO, not the Sender-ID PRA. The PRA doesn't necessarily help to identify a permitted or forged MAIL FROM. In other words the PRA or FWIW DKIM are not designed to avoid backscatter.

DKIM could be extended to avoid backscatter and replay abuse. Unfortunately, Sender-ID is being heavily promoted as the anti- phishing solution. A problem not addressed by RFC4408.

when an SPF hammer is the only tool

Folks didn't like the idea to reintroduce RFC 821 return routes ;-)
Of course receivers are free to use any tool to avoid backscatter, but SPF is today the only tool designed for this job.

I do not agree. Discouraging abuse by using RFC3464 is a far safer tool. SPF is dangerous and breaks email.

Cleaning up how DSNs are constructed would be _far_ more effective than asking that all DSNs be dropped when SPF does not produce a PASS.

No. When I was the victim (back in 2004 before SPF started to work) the _size_ of DSNs and other backscatter wasn't the main issue, the _number_ of bogus auto replies was the real problem.

SPF now gives bad actors a much more dangerous tool than auto-replies ever represented. : (

JFTR, "not PASS" can be FAIL or "DUNNO".  FAILs should be rejected.

Your idea to abuse DSNs for indirect spam or malware delivery is a valid consideration, but in practice the volume of all backscatter not limited to DSNs is the real problem.

Limiting the size of DSNs is okay, but it's not "far more effective" than "reject a.s.a.p.", in fact it misses the point wrt backscatter.

This was in terms of reducing risk. SPF is a dangerous mechanism which attempts to leverage a recipient's resources. Had the recipient known who sent the message, SPF would not be needed. As a general rule, when the source is unknown, any scripted use of resources offered MUST be extremely limited. SPF violates this rule.

Perhaps that is why Bell Canada ensures all addresses achieve a PASS. : (

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. At least the "+all" discourages use of dangerous SPF libraries while also reducing the breakage and permitting white-listing.

Auto responders aren't in a good position to verify the validity of the return path. Good positions to do this are the MSA based on RFC 4409 and later the MX based on RFC 4408.

RFC4408 did not mitigate a potential DDoS exploit. This exploit exists when recipients attempt to process SPF as specified.

Actually they've to ignore a SHOULD in the security considerations of RFC 4408 if they wish to participate in your convoluted attack scenario. And the SPF RFC did mitigate this potential with several MUSTs in the security considerations in comparison with pre-MARID drafts.

No! Although there are many SPF parsing libraries in distribution that ignore the SHOULDs, the example attack scenario is not prevented by any RFC4408 SHOULD or MUSTs! The attack was based upon a _fully_ RFC4408 compliant SPF parser!

-Doug










_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]