On Oct 15, 2007, at 5:51 AM, Frank Ellermann wrote:
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.
This adds perhaps 21 useless DNS transactions for each email
received? Do you expect everyone to use inbound servers to send?
And e-mail providers wishing to offer "per user policies" could
also create corresponding subdomains replacing local@xxxxxxxxxxxxxx
addresses by say user@xxxxxxxxxxxxxxxxxxxx addresses. Likewise
attackers trying to cause havoc can use user@xxxxxxxxxxxxxxxxxxxx
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.
Use of MX records are normally predicated upon the sending of
messages. When sending a message, MX records may have a potential
DNS traffic amplification of about 10. However, overall
amplification is much less when a message triggers an automated
response. An automated response is likely to be filtered, and the
sender risks being blocked, whether or not the MX record is doing
something nefarious. Many situations can achieve this level of
network amplification.
However, SPF's macros transforms a spam related attack into being
completely free without tainting the messages. Sending spam should
be considered a given as it represents a large portion of today's
traffic. SPF permits an enormous amount of DNS traffic to be
directed toward an innocent, uninvolved domain. Once the attack
duration exceeds a recipient's negative caching, no additional
resources of the attacker are consumed! The attack can come from
anywhere, is not easily traced, and, beyond universal banning of SPF
records, there is no defence! ACLs on DNS will not help, nor will
BCP 38. This attack is likely to continue for a long duration.
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.
SPF adds a layer of indirection. SPF allows the local-part of spam
to generate DNS transactions without consuming additional resources
of attackers once their SPF record has been cached! The attack can
then query any MX, A, AAAA, PTR, and TXT records from any domain
unrelated to message content. Even the attacking MX record might be
unrelated to any domain found within the message. SPF's added
indirection provides spammers a complete disguise. Recipients using
SPF are to know which messages are staging an attack. This is true
even when they do not wish to play a role in a reported ongoing
attack. Expect spammers to take advantage of this generous SPF
gift. : (
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.
RFC3464 represents a far better solution as it removes incentives.
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).
Of course MX records can be abused. SPF increases the potential
level of abuse by a factor of 10 or 20. With SPF macro's, abuse also
becomes completely free.
Block all SPF records?
At least we won't need a new rfc-ignorant zone to implement this
proposal... ;-)
Prevention might require DNS servers be modified to exclude SPF
records. Do not expect compliance without some form of blocking
imposed.
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.
Call back verification is not part of RFC2821?
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".
Other solutions are able to prevent the DATA phase for spam. : )
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf