Subject: RE: Effects on DNS can be severe &&& Re: call for ideas: tail-heavy IETF process

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 May 2013 14:11:28 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Kitterman
> Sent: Friday, May 03, 2013 1:00 PM
> To: [email-masked]
> 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 <[email-masked]>
> 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

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 03 May 2013 18:06:53 -0400

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:
> 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
> issue-tracker discussion is inadequate, or this is exactly the kind of
> thing that adds excess delay and workload to the IESG review process.
>

---

From: S Moonesamy <[email-masked]>
Date: Fri, 03 May 2013 16:25:11 -0700

Hi Tony,
>implementers know what and why.

Yes.

>that adds excess delay and workload to the IESG review process.

It seems that the above is related to Issue #24 [1].  I posted a 
rough summary of the initial discussion [2].  I took a look at the 
IETF 83 minutes and I found "DNS amplification attacks" [3] 
mentioned.  There was a message from Andrew Sullivan [4].

A working group may decide to blow off the issue if it wants.  The 
issue can be listed in the write-up.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00906.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00847.html
3. http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00944.html

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 3 May 2013 17:36:59 -0700

S Moonesamy wrote:
> >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.
> 
> It seems that the above is related to Issue #24 [1].  I posted a rough
summary
> of the initial discussion [2].  I took a look at the IETF 83 minutes and I
found
> "DNS amplification attacks" [3] mentioned.  There was a message from
> Andrew Sullivan [4].
> 
> A working group may decide to blow off the issue if it wants.  The issue
can
> be listed in the write-up.

Yes it can, and they often do. The question in this case is more about the
way that was documented, and Douglas' effective call for a wider review of
the decision. It may simply be the wording in the issue tracker, but reading
that the effective message is: 
   "a security issue was raised, and a subset of the potential attack is
easily mitigated, therefore the WG is dropping it"
There may well be more to it, and I said I have not been following it. The
point is that 'outside reviewers' will not be immersed in past discussion,
so what and why should be clear. I purposefully tied this to the ongoing
IESG process discussion, because it is a prime example of why post-WG
discussions take longer than expected, and may result in changes. 

Tony

---

From: S Moonesamy <[email-masked]>
Date: Sat, 04 May 2013 01:44:52 -0700

Hi Tony,
>easily mitigated, therefore the WG is dropping it"

Yes.  I would add a little more than so that the external reviewer 
can assess whether the potential attack is easily mitigated.

>discussions take longer than expected, and may result in changes.

It is difficult for someone who joins a working group in the middle 
of a discussion to understand what happened.  It's a lot of work for 
the external reviewer.  The external reviewer has to decide whether 
to take the word of the author when the latter says "it has been 
discussed".  An IESG member would probably generate a DISCUSS.  The 
working group might respond angrily.  The effect is excessive delay 
for an issue which could easily have been resolved.  In terms of IETF 
time there are four persons having to deal with it.  It is a prime 
example of tail-heavy.

Regards,
S. Moonesamy