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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Scott Kitterman
Sent: Friday, May 03, 2013 1:00 PM
To: ietf(_at_)ietf(_dot_)org
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(_at_)kitterman(_dot_)com>
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