Subject: [spfbis] Simplified DDoS concern statement

From: Douglas Otis <[email-masked]>
Date: Tue, 03 Apr 2012 20:14:51 -0700

Dear Andrew, Scott, and John,

I'll attempt to simplify SPF DDoS discrepancies in response to 
statements made in the WG meeting without getting too bogged down in 
details.

Those developing SPF offered senders a new role in the selection of DNS 
services by adding macros that construct "hostnames" in conjunction with 
"answer" processing.  Such macros provided malefactors an ability to 
have recipients target specific resources using a macro expansion 
process that requires all DNS transactions be replayed every time a 
check_host() identity is being resolved. Normally DNS resolves services 
where clients use hostnames to obtain random or round-robin lists of IP 
addresses for hosts offering the desired service that can be truncated 
to fit within a single DNS response.

Instead, SPF attempts to define a complete set of IP addresses for ALL 
hosts authorized to originate a domain's messages used by the 
recipient.  This much larger response is obtained using ahigher level 
check_host() process that repeats DNS transactions while combining up to 
10 additional TXT resource records or macro "mechanisms" where each 
"mechanism" may include 10 additional DNS transactions which may result 
in a total of 100 targeted and reflected transactions on behalf of an 
unknown entity.

Email is heavily abused and often leveraged by fairly successful social 
engineering attacks.  As a result, many institutions recommend various 
authentication or authorization strategies to better vet inbound email.  
Increased promotion of SPF, when it can be leveraged by malefactors, 
becomes a growing concern.  SPF has not represented a significant 
opportunity since most large domains don't use SPF to reject messages 
due to erroneous rejection rates requiring expensive customer support.  
Exploitation opportunities may grow as otheracceptance policies combine 
with SPFand its use becomes more common.

While indeed SpamAssassin among other email vetting processes make 
extensive use of DNS, these transactions are against services scaled to 
handle the volume, such as Surbl, Razor, Pyzor, DCC, and iXhash using 
specialized DNS zones supporting these various vetting strategies.  
Extensive use of these typical DNS based services do not permit 
malefactors a means to target their transactions, however processing 
incoming email generates extensive levels of legitimate DNS traffic.

Local-part macros exemplify a method that allows malefactors a means to 
leverage cached SPF records to repeatedly generate lengthy DNS 
transaction sequences.  SPF recommends "Mail From" and "HELO" identities 
be resolved even though neither of these are normally visible to 
recipients.  As currently defined, SPF may still return a "Pass" result 
after receiving 100 "no data" responses to requests made against 
non-existent resources in a victim's domain.  None of these hosts may be 
apparent within the triggering message which provides malefactors a 
means to avoid virtually all current email vetting strategies.  In 
addition, victim domains are completely independent of malefactor domains.

It is common to impose shortened limits on retention of negative answers 
to avoid customer support calls.  Once a spam campaign extends beyond a 
recipient's negative caching limits, repeated use of local-parts will 
not require malefactors to expend additional resources when generating 
repeated transactions against victim domains. 
draft-otis-spf-dos-exploit-01 showed resolving just the "Mail From" 
identity for a single message generated 34.8K bytes from a victim's name 
server in response to 28.8K bytes of recipient requests without use of 
DNSsec.  Per message traffic doubles when HELO identities are also 
resolved because fictitious sub-domains can replace the role of the 
local-part macro at the expense of caching additional SPF records for 
each new fictitious sub-domain.  As with other resource records supplied 
by malefactors, these too can be reused after a spam campaign extends 
beyond the recipient's negative caching limits.

While there are other methods available for staging DDoS attacks, risks 
pertaining to SPF can be easily mitigated without negatively impacting 
its utility.  Murray's SPF database showed only 24 domains used 
local-part macros.  Seven of these domains did not include IP address 
macros necessary to prevent trivially spoofed messages that place 
recipients at risk.  Use of local-part macros also permits unconstrained 
dictionary attacks that can expose a domain's valid local-parts.  This 
also represents a use level lower than that used to justify deprecation 
of SPF (type 99) resource records.  A sound interim solution that 
prevents disruption of services would be to always assert "postmaster" 
for any local-part reference.  This scheme is required to work, or 
respective servers would be unable to send NDNs from that domain.

Since SPF still permits malefactors an ability to target victim domains 
from recipient resources, reasonable limits should be required for 
no-data and name error results seen within the check_host() process.  It 
is also unreasonable to expect those operating inbound MTAs are likely 
to be aware of their possible role in a DDoS attack, or that other 
services have resources able to absorb even a small fraction of this 
possible traffic.  Use of RFC5451 supplanting the SPF-Received header 
field would make it more difficult to identify compromised sources.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Apr 2012 23:26:05 -0400

> field would make it more difficult to identify compromised sources.

The problem is not failing to understand the concern you are stating.  It is 
not agreeing with it.  There is nothing new here.

Scott K