Subject: Effects on DNS can be severe

From: Douglas Otis <[email-masked]>
Date: Fri, 3 May 2013 12:04:53 -0700

Dear ietf and dnsext,

I apologies for posting this ahead of the wg last call.

Over many years at attempting to change the course of the SPF process, this effort appears to have been futile.
It seems many even feel the present spfbis document represents current practices.  It does not, from the perspective of macros.
I have written an I-D that I fully expect SPF proponents will denounce and so I have left that wg alone.  

Here is a draft written in hopes of placing these concerns into a broader scope--
http://tools.ietf.org/html/draft-otis-ipv6-email-authent-00

Two references in this draft  did not carry over in the same manner as in the tcl script?  
Until remedied, here are the links missing in this i-d:

[I-D.otis-spf-dos-exploit]
http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01

[v6-BGP-Rpts]
http://bgp.potaroo.net/v6/as6447/

SPF can pose serious threats, that when confronted, few solutions are available.  I have been able to convince some of the larger providers of this concern, who in returned offered assurances the macro extensions in their SPF libraries are removed and in doing so have not seen any problems.

This is a serious effort at addressing a security concern, please read this draft from that perspective.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 May 2013 15:21:41 -0400

On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
...
> effort appears to have been futile.
...

It does seem a bit odd for you to claim you're being ignored when the largest 
change in SPF processing limits contained in 4408bis was your suggestion.  An 
alternate interpretation to consider is that the working group fully 
considered your inputs and incorporated those that were appropriate 
technically and in scope for the charter.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 May 2013 12:46:52 -0700

> technically and in scope for the charter.

Dear Scott,

This was not directly part of the IETF process, as my input there was ignored.

As I recall, removal of unlimited recursion occurred after a presentation made in Boston to the Open Group.

As with unlimited recursion, the need for the macro functions are also negligible while posing real risks. This is a serious security concern still needing to be addressed.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 May 2013 16:00:23 -0400

On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
> >> Over many years at attempting to change the course of the SPF process,
> >> this
> >> effort appears to have been futile.
> > 
> > ...
> > 
> > It does seem a bit odd for you to claim you're being ignored when the
> > largest change in SPF processing limits contained in 4408bis was your
> > suggestion.  An alternate interpretation to consider is that the working
> > group fully considered your inputs and incorporated those that were
> > appropriate technically and in scope for the charter.
> 
> Dear Scott,
> 
> 

I assume you are referring to some of the pre-IETF activities for SPF.  
Recursion based processing limits don't appear in RFC 4408 (and also not in 
4408bis).

> As with unlimited recursion, the need for the macro functions are also
> negligible while posing real risks. This is a serious security concern
> still needing to be addressed.

This was discussed in the working group and tracked in the WG issue tracker:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24

The change mentioned in the ticket is a direct result of your input to spfbis 
(referenced in the ticket).

As far as I can tell, this is just a case of "the working group came to a 
different conclusion, so I'll whine about it on the main list".

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Fri, 3 May 2013 15:39:57 -0700

Dear Scott,

While the recommendation may have helped, there is a trend of large websites publishing synthetic domains as an alternative to web cookies. This overcomes the suggested fix. A similar issue applies to SPF reverse namespace macro expansion consuming connection resources, especially in regard to IPv6.  In the end, the domain is still not authenticated, the number of transactions remain excessive and inhibit meaningful mitigation. Nothing justifies active content in DNS resource records distributed with email.  Macros are not needed and seldom if ever are used in this regard.  Simply put, SPF macros are not safe.  DKIM as specified is not safe. Open IPv6 email can not be defended.  The IETF needs to seek better and fairer remedies.

Regards,
Douglas Otis