On Oct 11, 2007, at 2:23 AM, Frank Ellermann wrote:
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.
Each of 10 MX records may necessitate resolving 10 target addresses
for a total of 100 targeted DNS transactions per SPF name
evaluation. By using the local-part in a spam campaign, one cached
SPF record is able to reference an unlimited sequence of MX records.
Targets within MX records can also utilize a small variable label
together with large static labels to leverage DNS name compression.
Without MX records being cached with dependence upon negative cache
expiring, the network amplification of an SPF related attack using MX
targeting would be about 10. After a recipient's negative caching
expires, repeating a sequence of local-parts in a spam campaign could
thereafter use cached MX records. Negative caching is not always
under the control of the victim. Once a set of MX records becomes
cached and their target's negative response expire, the entire attack
becomes entirely _free_ for spammers. 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. : (
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.
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. In the case
of SPF, the attack can become entirely free and completely hidden
while spamming! Rate limiting auto-replies would be a much safer
solution for the recipient to perform.
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.
Each recipient can be within a different domain where a MAIL FROM and
the PRA may be both evaluated. By expanding upon the local-part of
the email-address, caching SPF records actually aids the attack. The
only tuning required would be that of the local-part sequence.
Duration of the sequence only needs to be a bit longer than the
negative caching of the recipient.
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.
Do you really think a spammer is unable to attack at a gain of 10,
and then continue the attack at no cost once the duration of the
attack exceeds the negative caching (determined by the recipients).
SPF enables a long duration DDoS attack. Good luck at attempting to
prevent this type of attack or at identifying the source. Block all
SPF records?
The attacker could also try to abuse "call back verification" with
his bogus MX records for a better amplification factor without SPF.
The SPF can also attack those using wildcard MX, TXT or A records.
This attack would be instantly free and much simpler as it would not
require waiting for negative caching to expire. : (
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.
SPF introduces a long list of macros locating a sequence of records,
that then often involve additional DNS transactions. Even the time
limit applied by SPF disables DNS congestion avoidance!
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.
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.
A policy record at the MAIL FROM domain could reference an authorized
DKIM signature within a single DNS transaction. The same type of
policy record could be applied against the SMTP client to curtail
replay abuse. The MAIL FROM policy could thereby ensure a DSN is
issued when there is a problem, and the SMTP client could avoid
possible grey-listing should the recipient find replay abuse to be
problematic.
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.
DKIM can be processed prior to acceptance, and could safely help
prevent backscatter with a few minor by-name extensions.
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.
Agreed, but that does not mean that two names PRA and MAIL FROM will
not be checked.
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".
From my point of view, anti-phishing requires examination of message
content more than just email headers. When the message appears to be
misleading, and is not signed as expected, it should be marked as
suspicious or rejected.
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.
When desired, path registration should be by-name and not by-address
to avoid the unscalability, complexity, and risk. Something as
simple as CSV and a MAIL FROM policy record is far more scalable,
easier to manage, and much safer.
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.
I suspect they felt pressured by ISPs like AOL who use SPF records to
white-list other large providers. This indicates being part of the
club.
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.
It also removes any possible advantage for running these libraries
and avoids problems where the path of the message and the path
expressed by SPF legitimately differ.
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.
The example attack scenario never exceeded typical DNS transaction
sizes. It did not use TCP or EDNS0. It did not exceed the SHOULD
limits on the number of mechanisms or subsequent address
resolutions. SPF, as current defined, remains very dangerous. The
use of libraries implementing SPF per this specification are
dangerous as they permit a totally free attack, where the source is
hidden, and there is not a means to defend against it.
-Doug
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf