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

[Scott Kitterman <[e-mail]>]

Douglas Otis <[e-mail]> wrote:
>
>On Aug 26, 2013, at 4:29 PM, Scott Kitterman <[e-mail]>
>wrote:
>
>> On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
>>> On Aug 26, 2013, at 3:48 PM, Scott Kitterman <[e-mail]>
>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?
>> 
>> Your conclusion is different than the one the working group reached.
>
>Dear Scott, 
>
>Do you recall whether DNSSEC had been considered?

My recollection is that it was discussed. I believe it was concluded that SPF would benefit from the enhanced security associated with DNSSEC.  SPF doesn't seem to suffer from any unique problems associated with the potential for a larger payload. 

Scott K