Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review
Douglas Otis <dotis@mail-abuse.org> Tue, 26 May 2009 01:22 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 235303A6CCF for <asrg@core3.amsl.com>; Mon, 25 May 2009 18:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.191
X-Spam-Level:
X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 9FdyUig0CYlc for <asrg@core3.amsl.com>; Mon, 25 May 2009 18:22:02 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 2BBEF3A6D91 for <asrg@irtf.org>; Mon, 25 May 2009 18:22:02 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 90E25A9443A for <asrg@irtf.org>; Tue, 26 May 2009 01:23:38 +0000 (UTC)
Message-Id: <DEC522CE-67F9-41CF-9855-0E3B6BDD0427@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <3be421270905251345l1bbe8ce9je5554b727e7440a7@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 18:23:37 -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>
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: Tue, 26 May 2009 01:22:03 -0000
On May 25, 2009, at 1:45 PM, Amir Herzberg wrote: >> On Mon, May 25, 2009 at 6:54 PM, Douglas Otis <dotis@mail- >> abuse.org> wrote: >> 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. > > Sorry - I simply was not aware of SPF checks being invoked by MUAs. > I actually find it a bit strange that MUAs would do SPF validations, > considering they don't get MAIL FROM, but human ingenuity is endless > and I apologize for this ignorance. Doug, can you give me specific > examples - preferably of common MUA clients and if possible, of > appropriate documentation so I can read about it and/or test it? Tks! SPF can be found in ClamAV, SpamAssassin, etc. extend filtering of incoming email at the desktop for any type of MUA. There are even Thunderbird plugins that specifically provide SPF resolution. >> 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. > > I believe my text already makes this argument except for > considering the issue limited to MTAs, MDAs. A common mistake. >> 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. > > But spec says (and even if it didn't, common sense would) that a > reasonable limit of resolutions, say 10, should be used. I think I > even discussed this, I definitely considered discussing this. When the goal is to poison DNS, the SPF specifications limit resolution to 10 mechanisms, and then the resolution of MX records (one such mechanism) to 10. 10 x 10 = 100. The draft that I wrote long ago demonstrated 100 transactions using unmodified off-the-shelf SPF libraries. >> 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. > > This is indeed the attack I've sketched in the paper; do u think > more details were needed? Maybe I can simply add citation of some > detailed publication on this since I think adding much more details > is not reasonable for such a review. You might want to go through the numbers. When SPF records are being cached, but then expanded upon using macros, the cost to the attacker becomes nil, however the impact on their victim can profound. -Doug
- [Asrg] DNS-based Email Sender Authentication Mech… Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication … Dave CROCKER
- Re: [Asrg] DNS-based Email Sender Authentication … Steve Atkins
- [Asrg] 答复: DNS-based Email Sender Authentication … Sean Shen
- Re: [Asrg] ´ð¸´: DNS-based Email Sender Authentic… grenville armitage
- Re: [Asrg] DNS-based Email Sender Authentication … Jose-Marcio Martins da Cruz
- Re: [Asrg] ´ð¸´: DNS-based Email Sender Authentic… Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … der Mouse
- Re: [Asrg] DNS-based Email Sender Authentication … John Leslie
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … Jose-Marcio Martins da Cruz
- Re: [Asrg] DNS-based Email Sender Authentication … Chris Lewis
- Re: [Asrg] DNS-based Email Sender Authentication … Amir Herzberg
- Re: [Asrg] DNS-based Email Sender Authentication … Jose-Marcio Martins da Cruz
- Re: [Asrg] DNS-based Email Sender Authentication … Alessandro Vesely
- Re: [Asrg] DNS-based Email Sender Authentication … Dave CROCKER
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … Chris Lewis
- Re: [Asrg] DNS-based Email Sender Authentication … Alessandro Vesely
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … der Mouse
- Re: [Asrg] rDNS Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … Chris Lewis
- Re: [Asrg] rDNS der Mouse
- Re: [Asrg] DNS-based Email Sender Authentication … John Levine
- [Asrg] DNS over SCTP (was: Re: DNS-based Email Se… Alessandro Vesely
- Re: [Asrg] rDNS Alessandro Vesely
- Re: [Asrg] DNS over SCTP Alessandro Vesely
- Re: [Asrg] DNS over SCTP Alessandro Vesely
- Re: [Asrg] DNS over SCTP (was: Re: DNS-based Emai… SM
- Re: [Asrg] DNS over SCTP Douglas Otis
- Re: [Asrg] rDNS der Mouse
- Re: [Asrg] rDNS Alessandro Vesely
- Re: [Asrg] DNS over SCTP Alessandro Vesely
- Re: [Asrg] DNS over SCTP Alessandro Vesely
- Re: [Asrg] rDNS der Mouse
- Re: [Asrg] DNS-based Email Sender Authentication … Florian Weimer
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS over SCTP Douglas Otis
- Re: [Asrg] rDNS discrimination Alessandro Vesely
- Re: [Asrg] DNS over SCTP (was: Re: DNS-based Emai… Stephane Bortzmeyer
- Re: [Asrg] DNS over SCTP Stephane Bortzmeyer
- Re: [Asrg] DNS over SCTP David Conrad
- Re: [Asrg] DNS over SCTP Paul Wouters
- Re: [Asrg] DNSSEC is NOT secure end to end Thierry Moreau
- Re: [Asrg] DNS over SCTP David Conrad
- Re: [Asrg] DNS over SCTP Masataka Ohta
- Re: [Asrg] DNS over SCTP Michael Tüxen
- Re: [Asrg] DNS over SCTP Paul Wouters
- Re: [Asrg] DNS over SCTP (was: Re: DNS-based Emai… Francis Dupont
- Re: [Asrg] DNS over SCTP Francis Dupont
- Re: [Asrg] DNS over SCTP David Conrad
- Re: [Asrg] DNS over SCTP Francis Dupont
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Bill Manning
- Re: [Asrg] DNS-based Email Sender Authentication … Florian Weimer
- Re: [Asrg] DNSSEC is NOT secure end to end Francis Dupont
- Re: [Asrg] DNSSEC is NOT secure end to end Christian Huitema
- Re: [Asrg] DNS-based Email Sender Authentication … Douglas Otis
- Re: [Asrg] DNS-based Email Sender Authentication … Amir Herzberg
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Paul Wouters
- Re: [Asrg] DNSSEC is NOT secure end to end Richard Barnes
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Richard Barnes
- Re: [Asrg] DNSSEC is NOT secure end to end David Wilson
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Thierry Moreau
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Thierry Moreau
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Mark Andrews
- Re: [Asrg] DNSSEC is NOT secure end to end (more … Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Christian Huitema
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Doug Otis
- Re: [Asrg] DNSSEC is NOT secure end to end Paul Wouters
- Re: [Asrg] DNSSEC is NOT secure end to end Doug Otis
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end David Wilson
- Re: [Asrg] DNSSEC is NOT secure end to end David Wilson
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- [Asrg] RISC is end to end (was Re: DNSSEC is NOT … Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end David Wilson
- Re: [Asrg] DNSSEC is NOT secure end to end David Wilson
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end Masataka Ohta
- Re: [Asrg] DNSSEC is NOT secure end to end der Mouse
- Re: [Asrg] DNS over SCTP Alessandro Vesely