Re: Trouble with Sender Authentication

On Nov 2, 2006, at 5:56 PM, wayne wrote:

> In <[email protected]> Douglas  
> Otis <[email protected]> writes:
>
>> This list remains available for continued discussions of any MARID  
>> related issues. The spf-discuss reflector required participants to  
>> first agree with the promotion of SPF.  An insurmountable barrier  
>> for some. : )
>
> The SPF-discuss mailing list has never required you to agree with  
> the promotion of SPF.

Review the archive and you'll find a posting of the agreement  
initially required before subscribing to spf-discuss.  While it may  
have changed, this was the reason for not participating on that  
list.  The MARID list is still functional.

More than 70% of emails are spam, of which more than 70% are sent  
from compromised systems.  SPF offers powerful tools to these  
senders.  Consuming disproportionate amounts of a recipient's  
resource remains a philosophical barrier preventing support for an  
SPF scheme that expects large, powerful, and dangerous scripts be  
executed by recipients at every stage of delivery. : (

> Doug, I've read a lot of your postings about SPF over the last  
> several years, and I can't say I can recall you ever trying to make  
> a *constructive* suggestion on how to improve SPF, other than to  
> throw it out.

In Dusseldorf, Julian and Ming received *constructive*  
recommendations to allow record scoping, but this was ignored and  
became the basis for Julian's ignored complaint made to the IESG.   
Macros contained within SPF scripts require separate transaction sets  
per each possible and undefined scope, even when the same domain is  
resolved. : (

> As far as the SPF DoS stuff goes, I was the first to really raise  
> the issue of the DoS potential of SPF back in 2003.  The constructs  
> that
> you have mentioned in your I-D were analyzed by me before you first  
> wrote a post about SPF.  The lack of sufficient process limits was  
> one of the major reasons why I split with Mark Lentczner on the SPF- 
> classic draft and started my own, which eventually became RFC4408.

The solution adopted in your libraries harms domains by randomizing  
results of those that utilize more than 5 targets in their MX  
records. : (

> I have discussed this at length on the SPF list.  The difference  
> between you and me is that I offered *constructive* ways to change  
> SPF so that the DoS potential is greatly reduced.

The design of SPF as a massive script forecloses meaningful  
solutions.  You have yet to recognize SPF creates an impossible  
situation. : (

> I really think your huge exaggerations and running around like  
> chicken-little claiming that the sky will fall if SPF is adopted  
> has done more to hurt my push to take SPF DoS potentials seriously  
> than anything else.  I've read your draft.  Your numbers don't make  
> sense.  You spend way too much time promoting yourself and ranting,  
> and far too little time actually presenting data.

You are free to ask questions regarding figures not understood.   
Several proposals are solutions that avoid threats created by SPF  
(while also improving email integrity).  This is thinking outside the  
SPF box.  No personal gains are achieved by offering IETF drafts or  
fundamentally opposing SPF.  Let's stick to the merits of the concerns.

> It wasn't until your -01 version of your draft that you actually  
> presented hard data in your Appendix A.  Your data doesn't back up  
> your 1000x claims.

45 pages in the addendum trace SPF resolving a single name at about  
64:1 increase in traffic.  Consider the distribution methods used by  
spammers.  Messages come from tens of thousands of systems at slow  
rates to avoid detection.  This is an ideal platform to leverage SPF  
for a number of very bad things.  Gains stated in the SPF-DoS draft  
underestimate the risk.  Bad actors are sending spam where the  
possible attack is a gift provided by SPF.

Email as well as a long lived SPF records should be excluded from the  
attack overhead.  The same SPF record can utilize components of a  
local-part to produce infinitely variable transaction sets.  Only in  
rare cases is the intended scope of SPF defined, which means the  
executions per message, per MHS, and per recipient is unknown.  Both  
the MTAs and MUAs execute SPF scripts.  Bad actors have no difficulty  
using SPF to canvass recipients to determine who is receiving and  
executing SPF scripts.  There has been some rather scary discussions  
suggesting SPF might control DKIM replay abuse.  Such would add any  
number of new names resolved using SPF.  : O

> As I said, I've done this analysis before.  I actually *tried* to  
> set something up that would DoS Meng's box and tested it, but it  
> turns out that this is *MUCH* harder in practice than your  
> theoretical hand-waving analysis makes it seem.  People *don't*  
> have the MTAs set up in stupid ways that make it easy.

Consider how spam is currently being distributed.  The attack  
scenario does not require anything more than executing SPF scripts  
referenced from the spam received.

> I'm tired of your rants Doug.  I'm tired of your rants making  
> reasonable discussions on this subject harder.  And, yes, I realize  
> I'm probably burning a bridge here.

Your frustration is appreciated and no bridge is burned.  However,  
please no not dismiss these concerns as rants.

-Doug