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