ietf
[Top] [All Lists]

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

2013-08-26 18:57:17


Douglas Otis <doug(_dot_)mtview(_at_)gmail(_dot_)com> wrote:

On Aug 26, 2013, at 4:29 PM, Scott Kitterman <scott(_at_)kitterman(_dot_)com>
wrote:

On Monday, August 26, 2013 16:28:03 Douglas Otis wrote:
On Aug 26, 2013, at 3:48 PM, Scott Kitterman 
<scott(_at_)kitterman(_dot_)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?

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

<Prev in Thread] Current Thread [Next in Thread>