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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf