[ietf-dkim] Re: SSP + SPF records in DNS

[Douglas Otis]

On Jan 1, 2008, at 4:04 PM, Julian Mehnle wrote:

> Douglas Otis wrote:
>> On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:
>>>
>>> I proposed to put the SSP info into a separate DNS record in the  
>>> existing SPF RR set.  You don't need to look at any v=spf1 or  
>>> spf2.0/* record after a query=spf, you'd look for the v=ssp1 record.
>>
>> Original proponents failed to limit per message name evaluations.  
>> What prevents DKIM misuse when SPF includes DKIM policy?  Why  
>> wouldn't a DKIM specific domain be evaluated using SPF, and seen as  
>> analogous to that of the PRA?
>
> First, you seem to be completely missing Frank's point.  In the  
> above he is talking about sharing the "SPF" (code 99) RR typespace  
> among v=spf1/spf2.0 and v=ssp1 records, not about applying any  
> v=spf1/spf2.0/v=spf3 semantics to SSP or DKIM.

Of the small minority of domains publishing SPF records, 99.98% of  
these domains publish _only_ TXT RRs.  These records typically contain  
CIDR listings of IP addresses encompassing the SMTP clients.  These  
SMTP clients are thereby authorized to issue messages containing the  
email-addresses passed to the SPF processing routines.

However, SPF lacks a means to select a subset of IPv4 or IPv6  
addresses.  A realistic estimate of the text based CDIR payload might  
be about 140.  These CIDRs must span both IPv6 and IPv4 ranges.   
Cascading MX/hostname RRs is limited to 100, depending on limits  
imposed upon the hostname resolution process.  Some libraries limit MX/ 
hostname cascades to 50 CIDRs.  Any additional RRs placed at the email- 
address domain reduces overall CIDR capacity due to the RR property  
overhead, in addition to the RR content.  In addition, (as if this  
would ever happen) any versioning of SPF/PRA records _MUST_ also  
occupy the _same_ initial location.

Why should DKIM only use type 99 RRs, when the DKIM WG would not  
consider a new RR acceptable?  Essentially no one is using RR type 99  
now.  Any overhead reduction, albeit with larger payloads, is to be  
found by leveraging TXT RRs.  It it really wise to invite unrelated  
TXT resource records into this congested location, already (ab)used by  
a PRA evaluation process?

> Second, your analogy (which as I said misses Frank's point) to the  
> re-use of v=spf1 records for PRA evaluation (as propagated by  
> Microsoft) is broken.  Even if some v=spf3 came along and defined a  
> new "dkim:" mechanism, there would be no general risk of confusion  
> whatsoever with a separate SSP record scheme, because any additional  
> and potentially conflicting semantics would be entirely up for  
> domain owners to declare!

Each email-address evaluation may require processing an entire SPF  
record set.  This set may span as many as 111 resource record  
transactions, ignoring checks for TXT or type 99 and reporting  
records.  Subsequent processing of any different email-address, even  
within the same domain and message, may again span another 111  
transactions.  Complete reprocessing is needed to support expansion of  
macros contained within SPF records.  Any suggestion SPF should  
include DKIM policy greatly increases the risks related to SPF  
exploits that might then leverage the additional evaluations of DKIM  
specific email-address.  The risk caused by the number of DNS  
transactions employed, and a bad actor's ability to cache their  
attack.  More than 20% of domains override negative caching to  
intervals less than an hour.  Rampant SPF evaluations can result in a  
devastating attack completely free for spamer/attacker.  MTAs  
employing SPF are unlikely to detect when an SPF exploit is progress,  
nor will forensics of MTA logs be of much use.  An attack, free in  
almost every sense.

> IOW, if a domain owner published some "v=spf3 dkim:..." record  
> according to whatever specification of v=spf3 or "dkim:", it would  
> be that domain owner's decision.  The problem with the v=spf1/PRA  
> fiasco was that the Sender ID specification (and any implementations  
> thereof) did NOT leave it up to domain owners what their existing  
> v=spf1 records were supposed to mean.
>
> I am not going to discuss the details of your FUD about SPF being a  
> threat to the livelihood of DNS and the internet as a whole, but let  
> me summarize the SPF project's conclusion as follows for the benefit  
> of others:

The FUD is an attempt to increase awareness of risks remaining within  
the SPF protocol.  After all, DDoS are expensive for the victims. : (

OpenSPF's dismissed SPF transactional exploitation concerns based upon  
a bad actor's ability to also exploit DNS NS records?  Their example  
exploit was to return a bogus NS list misdirecting DNS transactions to  
other servers.  Their example somehow dismissed concerns related to  
the traffic generated by SPF's per message/MTA/MUA/recipient  
evaluation of a PRA and MailFrom email-address.  SPF still allows bad  
actors to exploit both SPF _and_ other resource records in tandem.   
OpenSPF expressed a rather callus lack of concern regarding their  
disabling of DNS congestion avoidance, allowing attacking records to  
be cached and then generate random queries, or to the very distributed  
nature of their mechanism.  SPF provides bad actors a tool that can be  
used for staging DDoS attacks, and even poisoning DNS itself. This  
exploit is beyond being controlled by firewalls, ACLs, and even  
universal implementation of BCP38. : (

>>> Let's say that there are still more pressing problems with DNS  
>>> attacks than your idea to abuse SPF to query addresses in ten MX  
>>> sets.
>>
>> This concern extends to macro expansions using the local-part of  
>> the email-address.  It is extremely difficult to determine whether  
>> a DDoS had been sourced by SPF.
>
> And that determination is of academic interest at best, because  
> there are indeed other ways for DNS-traffic-based DoS attacks that  
> are just as suitable as, if not more than, SPF:

SPF leverages MX records, where MX records themselves offer a moderate  
amplification of about 10.  SPF limits the number of different MX  
records employed to 10, and the resolution of subsequent hostnames to  
10 each (10 x 10 = 100 transactions).  However, SPF permits references  
to MX record to be based upon labels generated by macro expanding  
email-address local-parts. : (

Normal use of MX records will seldom cause all hostnames to be  
resolved at once when in different domains.  Hostname resolution is  
normally interspersed with attempts to contact the host, after all.   
SPF MX records represents a different situation.  Addresses resolved  
might have a CIDR mask applied and then immediately compared against  
the IP address of the SMTP client.  In other words, the SPF MX record  
is not used to locate a receiving host, and lacks the typical  
processing impediments.

SPF/Sender-ID also does not impose reasonable transactional limits  
when considering how these active records might be abused.  Once  
attacking records have been cached, a spammer/attacker can recycle at  
no additional resource cost to them, once their campaign extends  
beyond a negative caching interval.  An interval often inappropriately  
limited by receiving domains.  An attack with a gain of 10 using MX  
records then transitions to a gain approaching infinity, since spam  
enabling the attack is still accepted by appending a "+all" or its  
equivalent as the final SPF mechanism.

SPF records might be processed by routines taking shortcuts that fail  
to impose even recommended transactional limits.  However, SPF also  
recommends starting evaluation of a different record set while still  
within a DNS back-off interval.  Not waiting protects an MTA receiving  
process, very much at the expense of the DNS protocol.

Several proponents of SPF remarked they think DNS is broken.  DNS is  
clearly not well suited for returning massive address lists, at  
least.  Path registration, if desired, should have been done by-name,  
in a manner far more compatible with DNS.

-Doug