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