Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard

[Scott Kitterman <[e-mail]>]

On Thursday, March 01, 2012 04:47:43 PM Barry Leiba wrote:
> >> >>   "Security issues with respect to these reports are similar to
> >> >> those
> >> >>    found in [DSN]."
> >> >> 
> >> >> The reference to DSN could be normative.
> >> > 
> >> > Security Considerations are never normative, so I'm not sure I
> >> > agree
> >> > that this should be.
> >> 
> >> It should.  Just because the Security Considerations section doesn't
> >> usually use normative language doesn't mean that it's not normative.
> >> People reading the document and implementing the protocol certainly
> >> have to read and understand the Security Considerations section, along
> >> with any transitive sections in other documents.
> > 
> > The reason I didn't make it normative when I drafted that section is
> > because this isn't a DSN, it's an ARF, thus the similar to.  If people
> > think it should be normative, I think it's fine to change it.
> 
> Yes, but think about the difference between these two statements:
> 
> 1. Security issues with respect to these reports are similar to those
> found in [DSN].
> 
> 2. Security issues with respect to these reports are similar to those
> found in [DSN].  Specifically, X and Y.  Also Z, when that situation
> is applicable.
> 
> In the second case, you can understand the security issues here
> without going and reading [DSN].  It really is just saying that these
> are similar to those, so the reference is informative.  In the first
> case, how can you know *anything* about the security issues without
> reading the referenced document?
> 
> If sections 6.1 and 6.2 really do say everything that needs to be
> said, and the sentence in 6. could be removed without loss of
> important information, then leave it as an informative reference.  If
> one really has to go to [DSN] to see what some of the issues are, make
> it normative.  That's the test.

Makes sense.  Thanks for the clarification.

Today I reviewed RFC 3464 again.  It has the following security 
considerations:

4.1 Forgery
4.2 Confidentiality
4.3 Non-Repudiation

Of these, I think that only forgery is relevant to this draft.  The non-
repudiation issue is not applicable to authentication failure reporting.  The 
confidentiality issue should be addressed in the document that discusses 
creation and formatting of these reports.

draft-ietf-marf-authfailure-report-10 (which is already a normative reference 
and listed for included security considerations) covers forgeries in great 
detail, so to the extent the advice in 6.2 of this draft doesn't address it, I 
think it's addressed there.

Based on that, I think that the sentence in paragraph 6 could be lost without 
losing anything important, so I think it should stay as it is.

This discussion also caused me to re-read draft-ietf-marf-authfailure-
report-10 again since that's where report generations is described.  It is (I 
believe) silent on confidentiality, except to say:

6.  Security Considerations

   Security issues with respect to these reports are similar to those
   found in [DSN].

(the exact same text that caused comment in this draft)

It might be worth someone looking at draft-ietf-marf-authfailure-report-10 
again to see if that's really appropriate.

Scott K