On Nov 7, 2008, at 5:25 PM, Scott Kitterman wrote:
On Fri, 7 Nov 2008 16:09:22 -0800 Douglas Otis <dotis(_at_)mail-
abuse.org> wrote:
....
I think it's worth pointing out when considering how much to worry
about Doug's latest "SPF will melt the Internet" theory that shared
MTA concerns are directly addressed in the RFC 4408 security
considerations. This is nothing new that wasn't carefully
considered during the protocol design.
Scott,
Thanks you for the opportunity to respond to this mistaken view.
The local-part macro concern of SPF was dismissed by some proponents
as being no worse than other DNS related transactions. This was
viewed incorrectly by proponents as only offering a 10x gain in a
reflective attack, as measured by the expansion of MX records. Their
dismissal of this concern failed to consider how cached records might
be leveraged in a spam campaign that cycles local-parts at the
negative cache interval. In this case, the attack gain can rise to
several hundred over that of the spam campaign traffic (spam that will
have been sent anyway). In essence, a free attack.
RFC 4408 security considerations suggest imposing limits at 10 MX
records (and at 10 targets each) will offer adequate protection from
participating in a DDoS attack. This assertion falls short in at
least two ways.
1) The SPF attack is reflective and can achieve without local-part
macro expansion at least 10x amplification at about 500 KB of DNS
traffic per message name resolved.
The 10x gain is created by 10x10 (100) MX record targets resolved per
SPF name, of which there may be 2x per message. A spam message is
often fairly short.
2) The 10x gain can increase to being > 300x gain compared against the
spam campaign traffic, once the timing of negative caching and local-
part macros are employed.
RFC 4408 offers no advise on how to avoid local-part expansion of
cached SPF records. Since the local-part expansion macros are seldom
used, these macros, as well as the exists() function should be made
obsolete for security reasons.
As network bandwidth increases, and NATs become more prevalent with
enterprises and carriers, DNS transaction IDs offer diminishing
protection. SPF allows bad actors control over a long sequence of DNS
transactions that might start with one directed to an evil DNS server,
that is then followed by 99 rapid fire transactions toward victim DNS
servers. SPF is ideal for both suppressing authoritative servers,
while also generating ample and well timed poisoning opportunities.
Victim domains are not required to publish SPF records to be
attacked. Is it not great that MUA plugins also resolve SPF records,
but frequently don't follow even the recommended limitations
considering that it is rather common to have tens of thousands of SMTP
clients act in concert.
I requested an opportunity to better explain this concern at MAAWG,
but was prevented from doing so by the board. They insisted only
promotional information would be allowed.
I think it's reasonable to assume that implementers pay attention to
RFC security considerations. I think there are plenty of protocols
that would have security holes if their security considerations were
ignored.
Unfortunately, adopting security considerations in RFC 4408 is not
enough. Also, SPF combines both IPv4 and IPv6 into a common data-
set. As network address diversity grows, so will the size and number
of SPF related transactions.
If a DKIM signing shared MTA were to sign a message sent by somone
not authorized to use the domain, the exact some situation arises.
Unlike SPF that requires separate IP addresses to isolate each
customer's traffic, DKIM offers an unlimited number of domain names
per MTA without the need to impose any header field restrictions.
Seldom will a single MTA be assigned more than 8 IP addresses, and yet
many MTAs handle thousands of different domains.
It is nonsense to suggest that SPF or Sender-ID authenticates a PRA or
MailFrom domain. It is normal for many domains to share the IP
address of an MTA. There is no way to discern which instance of an
published SPF record represents a unique IP address, or one that
adequately protects or adequately modifies the PRA. Few really do, so
assessments should not be based upon the Sender-ID or SPF authorized
domain, but instead should be based upon the MTA IP address or on a
non-authorized MTA.
A cynic may view the absence of the IP address from the
"authentication-results" header for Sender-ID or SPF as an effort to
shift blame toward hapless domain owners, and away from email
providers. Not including the IP address discourages recipients or
filters from checking with their trusted public IP address reputation
service at least. Most of the abuse seen today is introduced through
compromised systems. For Sender-ID or SPF, compromised systems are
best tracked by the MTA IP address.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html