Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review

Douglas Otis <dotis@mail-abuse.org> Wed, 27 May 2009 17:04 UTC

Return-Path: <dotis@mail-abuse.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3E43A6F45 for <asrg@core3.amsl.com>; Wed, 27 May 2009 10:04:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.325
X-Spam-Level:
X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OlSEj9MjsNd for <asrg@core3.amsl.com>; Wed, 27 May 2009 10:04:45 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id A9E953A6452 for <asrg@irtf.org>; Wed, 27 May 2009 10:04:45 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5B2A1A9443E for <asrg@irtf.org>; Wed, 27 May 2009 17:02:25 +0000 (UTC)
Message-Id: <F3B40501-6A72-4F28-9514-3CD3B669F003@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <3be421270905262259v777cb54jadf4fd9df1c50c6a@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 10:02:17 -0700
References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <4A1A45BA.5030704@swin.edu.au> <3be421270905250718y5d62f6d5odb6f2bebecf418d0@mail.gmail.com> <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org> <3be421270905251345l1bbe8ce9je5554b727e7440a7@mail.gmail.com> <DEC522CE-67F9-41CF-9855-0E3B6BDD0427@mail-abuse.org> <3be421270905262259v777cb54jadf4fd9df1c50c6a@mail.gmail.com>
X-Mailer: Apple Mail (2.935.3)
Subject: Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 17:04:46 -0000

On May 26, 2009, at 10:59 PM, Amir Herzberg wrote:

> Doug, thanks! I completely agree that applying SPF at the client -  
> or in fact, anywhere after the border MTA - is probably a very poor  
> idea, due to the potential exposure to DoS and DNS poisoning  
> exploits. I just didn't think this people would do it - I'll try to  
> add warning against it. This is far beyond the question of whether  
> there is also some real goal in doing SPF validation at this point  
> (client) [referring to Chris's note].

A warning is likely not something a typical user would know how to  
control.  SPF record processing is found lurking in many places.   
Within AV and various email filtering and annotation schemes that do  
not indicate the processing of SPF records will occur.    
Unfortunately, some of these schemes are rather poorly written and  
even lack some of the recommended albeit generous processing limits.

> And I agree that it may be worthwhile also mentioning the 10*10  
> amplification factor for implementations that allow 10 mechanisms  
> where each could do 10 MX (or PTR) RR lookups, for a total of 100  
> DNS queries (or I think actually 111). Notice that again, the use of  
> SPF by multiple mail agents, e.g. at the client, would provide even  
> further amplification.

The important aspect of this concern is that SPF _macros_ allow the  
SPF record itself to be cached and thereby not expend _any_ additional  
resources of the attacker.  Macro expansion of cached SPF records by  
recipients can generate 10x transactions as a completely free gift to  
the attacker!   This free attack eliminates a major factor that  
discourage most DDoS attacks.  This represents an indirect attack that  
is difficult to trace,  that is likely not logged, and is  
substantially free because a final transaction, or even the end of the  
SPF record, can result in full authorization regardless of the MTA IP  
address.

-Doug