There's been a details review of his draft done when it was published, if you want something more coherent to read: http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis In the more than half decade since, the issue has been discussed and reviewed many times. In the pre-IETF phase of SPF development the processing limits were very different and, in my opinion, inherently risky. The changed processing limits is probably the most important technical difference between RFC 4408 and the pre-IETF drafts. To the extent there is a significant problem, I think the changes in RFC 4408 substantially mitigated it and the 4408bis draft goes a bit further. We did have an extensive discussion about SPF macros and if they should be removed. The conclusion of the working group was that given our charter and the facts available, they should not. Doug's claim not to have participated is not correct. All you have to do is look at the mailing list archive. It's true that he seems to have stopped at some point, but having submitted issues to a WG that were reviewed and that ultimately impacted the text in the draft is not at all not participating. Finally, I don't think it's reasonable for a draft to document internally why various decisions were made. It needs to document the results of the WG efforts. 4408bis is long enough already and all the working group discussions are documented for people who are interested. Scott K On Friday, May 03, 2013 02:11:28 PM Tony Hain wrote: > Scott, > > See the thread about Re: call for ideas: tail-heavy IETF process for > discussion about wider review at an earlier point in the process. Also, just > because there is a discussion on issue-tracker does not mean the document > is 'high quality'. If there is an explicit trade-off being made, the main > document needs to address that directly so subsequent reviewers and > implementers know what and why. > > I have not followed this discussion, but my cursory read of the tracker > ticket shows the WG blew off the issue by claiming that historical > unsophisticated attacks can be easily thwarted, while completely ignoring > the case where the target domains exist. Aborting an amplification attack on > failures does not do anything about the case where an attacker goes to the > trouble to make sure all the quires will return valid answers. Either the > issue-tracker discussion is inadequate, or this is exactly the kind of > thing that adds excess delay and workload to the IESG review process. > > FWIW: id-otis-spf is an incoherent collection of issues. I can see why a WG > might have trouble parsing it, and come out with a different answer than > what was expected. That said, wider review requires a simpler problem > statement and understanding of what resources are being traded against > others, and for security issues in particular, a comprehensive set of attack > scenarios and mitigations. > > Tony > > > -----Original Message----- > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > > Scott Kitterman > > Sent: Friday, May 03, 2013 1:00 PM > > To: ietf@xxxxxxxx > > Subject: Re: Effects on DNS can be severe > > > > On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote: > > > On May 3, 2013, at 12:21 PM, Scott Kitterman <scott@xxxxxxxxxxxxx> > > > > wrote: > > > > On Friday, May 03, 2013 12:04:53 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, > > > > > > > > > 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. > > > > 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