Re: [dnsext] SPF, a cautionary tale

Douglas Otis <doug.mtview@gmail.com> Sun, 05 May 2013 01:01 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29D721F96B9 for <dnsext@ietfa.amsl.com>; Sat, 4 May 2013 18:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du34gHCLl3CR for <dnsext@ietfa.amsl.com>; Sat, 4 May 2013 18:01:05 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id D375221F96B8 for <dnsext@ietf.org>; Sat, 4 May 2013 18:01:05 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id x10so1457444pdj.21 for <dnsext@ietf.org>; Sat, 04 May 2013 18:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=nRN2vPei0FUyW103DvtEJxQzciu6mPPS+MgWXrUNpuU=; b=mLp9obr/ndsPeu9WCQTJCDbDYczEdQbG027WFOEAo+O/elgXJjmId61fD14I5Iks/C uemnMiQm7JNeBQPZzRCZpuPJPGgaZJfMygChvxbvML72i3ZhEd+6LKKh8T4zUjT0XiTc 3BQcWE0eayd18gdlXnNhiMZAmGFGoj8Kz4GCOgV/MTxzcf6EekR3x6yHict1RGjAtbt6 5XSUE+YAAVEQdLT+bdEPJH2Vf1nuMWw0ih5OeiKArUx5TMefm5e+gkPlNldB+uBO0Seu +s732id5AHlzGTVo9SX6W/ExymKaDB8wNt5HNfOJWAvH+RXfmKReZL0b9xqF9qYaisi9 pmsw==
X-Received: by 10.66.149.5 with SMTP id tw5mr20919027pab.87.1367715665641; Sat, 04 May 2013 18:01:05 -0700 (PDT)
Received: from [192.168.1.194] (c-24-4-157-244.hsd1.ca.comcast.net. [24.4.157.244]) by mx.google.com with ESMTPSA id 10sm17547498pbr.45.2013.05.04.18.01.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 May 2013 18:01:04 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <alpine.BSF.2.00.1305041103360.8602@joyce.lan>
Date: Sat, 04 May 2013 18:01:02 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <FB9C23A1-1BE9-46F3-BB1F-B26A5218872F@gmail.com>
References: <8D23D4052ABE7A4490E77B1A012B63077516EA82@mbx-01.win.nominum.com> <20130503171843.39672.qmail@joyce.lan> <20130504133312.GA27772@vacation.karoshi.com.> <alpine.BSF.2.00.1305041103360.8602@joyce.lan>
To: John R Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.1503)
Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org, Ted.Lemon@nominum.com
Subject: Re: [dnsext] SPF, a cautionary tale
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2013 01:01:11 -0000

On May 4, 2013, at 8:16 AM, John R Levine <johnl@taugh.com> wrote:

>>> ... and interpreting SPF records requires more DNS queries than any other DNS application I know.
> 
>> 	So what you are saying is that SPF is a carefully crafted DNS
>> 	DDoS attack because it was too hard to do the work inside your
>> 	own protocol?
> 
> Yup, just like CNAME.
> 
> In the decade that SPF has been around, the putative DDoS has never been observed in the wild, ever, despite Doug Otis warning us about it every 15 minutes since 4408 was a draft, and a few experiments I did with stunt DNS servers that returned giant trees of SPF records very slowly.  It turns out everyone does loop breaking, just like for CNAME.  It's a sloppy design from a decade ago that succeeded because it made an end run around the DNS provisioning problems of "better" alternatives.
> 
>> 	What ever happened to "Be Conservative in What you Send..."
> 
> It lost out to Stuff That Actually Exists Works Better than Stuff That Doesn't.
> 
> A decade ago, SPF was far from my favorite authentication design, but now it exists, it's more widely used than most standards track protocols, and it would be silly to pretend otherwise.  Hence the spfbis charter to standardize existing practice.

Dear John and Bill,

I have heard this canard several times as if it offers some level of assurance.  How does one know whether SPF sourced any particular DDoS related query?  These represent reverse PTR, TXT, A, AAAA record types at any location.

It is also wrong to suggest SPF specification represents existing practice. Not all providers implemented SPF macro components.  The decision to depreciate SPF (99) RRs happened at roughly the same level of local-part macro expansion use.  Use of local-part macros requires other mechanisms to prevent unlimited spoofing when SPF pass becomes independent of the sending client.  The impact that such clever mechanisms may have is unknown if they ever become popular. 

Thank you Bill for clearly expressing this opinion.

Regards,
Douglas Otis