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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf