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

Douglas Otis <dotis@mail-abuse.org> Mon, 25 May 2009 15:52 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 ED9F03A6827 for <asrg@core3.amsl.com>; Mon, 25 May 2009 08:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.45
X-Spam-Level:
X-Spam-Status: No, score=-5.45 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, URIBL_GREY=0.25]
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 I+RUn3HW-0u6 for <asrg@core3.amsl.com>; Mon, 25 May 2009 08:52:29 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 9CADC3A67E6 for <asrg@irtf.org>; Mon, 25 May 2009 08:52:29 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8D89AA9443A for <asrg@irtf.org>; Mon, 25 May 2009 15:54:10 +0000 (UTC)
Message-Id: <6684E747-55CB-4BB3-B838-9F4FE906AFE7@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <3be421270905250718y5d62f6d5odb6f2bebecf418d0@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: Mon, 25 May 2009 08:54:09 -0700
References: <003d01c9dd01$bf3531d0$800c6f0a@china.huawei.com> <4A1A45BA.5030704@swin.edu.au> <3be421270905250718y5d62f6d5odb6f2bebecf418d0@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: Mon, 25 May 2009 15:52:37 -0000

http://amir.herzberg.googlepages.com/somerecentpapers

This paper refers to DNS poisoning without fully exploring how SPF  
might be used to enable DNS poisoning.  SPF might be checked by MUAs  
in some cases.   More than just resolvers associated with MTAs are  
affected, so separate resolvers for MTAs, which themselves might  
become poisoned, does not represent a good solution.  SPF provides bad  
actors access to DNS resolvers that might otherwise be protected by  
ACLs.  At today's Internet speeds, DNS transactional IDs do not  
represent adequate protection.  SPF's use of macros ignores this  
security venerability.  Suggesting the use of DNSSEC is not reasonable  
justification for ignoring this problem.

SPF supports the use of macros to access A, AAAA, PTR and TXT DNS  
resource records.  These macros might expand local-parts within the  
email-message, which means SPF records may NOT be fully cacheable.   
Subsequent record resolutions can be triggered by the SPF macros,  
where as may as one hundred such record resolutions can occur when  
resolving a single SMTP source authorization.

These subsequent resolution events can be directed toward both a DNS  
resolver under the control of the bad actor to obtain timing and  
target information for the remaining tens or hundreds of record  
resolutions made against their victim's caching resolvers.  This  
attack can be renewed by simply changing local-parts within either the  
bounce address or the PRA.  Perhaps both the bounce address and the  
PRA authorization verifications are attempted, which would have the  
effect of doubling the amount of traffic.

SPF enables both sustained DDoS attacks and is able to bypass  
protections otherwise afforded by ACLs on local resolvers.  It seems  
that risk should be mentioned in a critical review.

-Doug