Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Douglas Otis <doug.mtview@gmail.com> Mon, 26 August 2013 23:28 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1BB11E8226 for <ietf@ietfa.amsl.com>; Mon, 26 Aug 2013 16:28:24 -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 JvHFLEWc9zHs for <ietf@ietfa.amsl.com>; Mon, 26 Aug 2013 16:28:07 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id CDFB711E820D for <ietf@ietf.org>; Mon, 26 Aug 2013 16:28:07 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up15so4022531pbc.40 for <ietf@ietf.org>; Mon, 26 Aug 2013 16:28:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1k4p8MgcfqZq+Bh3XBatEask6P9o7DuHYk77zYM/R+Y=; b=ytQtjhibfJCpLH+j/CvVGTVn8d0qCrLj1gbSKWLpnRqpr7ROWBhVYx3EmmRne486+2 WdJ5Mk3f3xTnULnkJ7FEOXsISSnbBq0ZFZccthzLMgApFrTMFLY2dR+CDrYO31JcJxkn 082fSRQ67Wvoc9ih47mKAXH8lmbWRwQx66Lu8uzIHOVu3R41f4ZkD+noIxNxUqtfTX37 nQGyTznutji5HdZVhaCCFTylFIMKUF9z0aHnwzzel/gJcWrySDiol+fIZhsx7bHugQFI +QCJr4HmaR5hcEP9/e5OHumc/DhK378XS3c/w0lgLgnJq7n2sbFUNfEhFMfVTo+aeacY R/iA==
X-Received: by 10.68.244.73 with SMTP id xe9mr17732825pbc.119.1377559686536; Mon, 26 Aug 2013 16:28:06 -0700 (PDT)
Received: from [192.168.2.247] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id kd1sm22599477pab.20.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Aug 2013 16:28:05 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <1973922.OgEpFZ84lJ@scott-latitude-e6320>
Date: Mon, 26 Aug 2013 16:28:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE72B4FF-2948-4EB4-9A91-D026FC493B4F@gmail.com>
References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com> <6.2.5.6.2.20130823234808.0b7cfed0@elandnews.com> <C5D75C5C-D468-4104-A478-0A055F43AED9@gmail.com> <1973922.OgEpFZ84lJ@scott-latitude-e6320>
To: Scott Kitterman <scott@kitterman.com>
X-Mailer: Apple Mail (2.1508)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2013 23:28:24 -0000

On Aug 26, 2013, at 3:48 PM, Scott Kitterman <scott@kitterman.com> wrote:

> On Monday, August 26, 2013 15:42:41 Douglas Otis wrote:
>> Please also note that the PTR RR is not constrained in the current
>> specification and can create erratic results.  It would be far safer to
>> Perm error when overflowing on the number of PTR records.  There is no
>> upper limit as some represent web farms hosting thousands of domains. 
> 
> This exact issue was the subject of working group discussion.  Since the 
> number of PTR records is an attribute of the connect IP, it is under the 
> control of the sending party, not the domain owner.  A cap that resulted in an 
> error would, as a result, enable the sender to arbitrarily get an SPF 
> permerror in place of a fail if desired.  The WG considered that not a good 
> idea.


Dear Scott,

It is within the control of the Domain owner about whether to make use of the ptr mechanism in their SPF TXT.  Random ordering or responses is also controlled by the IP address owner and not the Domain owner.  The ptr mechanism may offer intermittent results that will be difficult to troubleshoot.  By offering a Perm error on a ptr overflow, the domain owner is quickly notified this mechanism should not be used and are not fooled by it working some of the time.  The greater concern is in regard to the over all response sizes when DNSSEC is used.  In that case, response sizes can grow significantly.  Allowing large responses to occur without producing an error seems like a risky strategy from the DDoS perspective.  That is also another reason for worrying about the use of TXT RRs.  How many large wildcard TXT RR exist, and if they do, who would be at fault when this becomes a problem for SPF?

Regards,
Douglas Otis