Sam, thanks for your reply, I think I am getting closer (and many thanks for bearing with me)...
> > >> We also need to do the analysis of what security is actually > >> required by syslog deployments. If the ansers are different, > >> we'll have to deal with that. > > Rainer> I thought we are doing this by refering to the sections in > Rainer> RFC 3164 and syslog-protocol-16. Do you think we need to > Rainer> elaborate more on the potential threats? If so, we > Rainer> definitely would need to reconsider that part of the work > Rainer> (also in -protocol, because it should mention at least all > Rainer> transport-independant threats). > > no, that documents all the threats. It doesn't actually make a call > as to wether a particular threat is important to solve. > > As an example, if integrity is not important to the way people use > syslog, we might not consider it important to provide integrity. On > the other hand if integrity is important to how syslog is used but we > cannot find a way to deliver integrity in a manner that is useful to > people, we have to carefully consider what to do. I now understand. But wouldn't it then make sense to create a separate document for it? I have the feeling that would focus us better than when the discussion is split among different places/documents. And if I understood Eric Hibbard right, we may even have a volunteer to put it together. Or would it be better to put all of this into -protocol's security considerations section? > So, you and Chris have made an argument that we cannot provide > integrity without decreasing the utility of our security solution. Actually not. I wrote ### On the other hand, it might make sense to mandate that a -transport-tls (let me call it so for now) compliant implementation MUST support #2, but MUST be configurable to not use it. That way, we would require that each implementation supports full security but do not force the operator to use it. However, I am not sure if such wording is within the scope of the IETF. ### (#2 was authenticated TLS) Look at the last sentence. I was not sure if we could specify a configuration option inside a RFC. My intension is to mandate in -transport-tls that the implementation MUST support anonymous and authenticated TLS (its even easy to do), but that it must be possible that that the operator decides which to use. Now that I have written this sentence, it probably is already the solution. -transport-tls mandates both as two separate modes. So either mode could be configured by the operator. Then, it's security considerations section could document the implications of mode selection. Rainer _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
