Hi Sam & WG, I understand the reasoning behind requiring a security mechanism. I just want to remind everyone that a major drawback in Vancouver was that we had lost some backwards-compatibility to existing syslog implementations.
The weeks after Vancouver we worked hard to find a minimum consensus on how we could provide the needed backwards compatibility. When we mandate a security mechanism, we must be very careful not to invalidate all these attempts. Why? Simply because any transport-layer requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with currently existing syslog implementations. So due to this requirement, we can not create a backwards-compatible spec (not even in the sense that existing receivers can put messages in the right bins). So in my point of view the only option is to use structured-data embedded signatures. As they do not modify the message format AND work over UDP, they allow old receivers to receive messages and put them into the right bins while new receivers can enjoy their benefits. In my point of view, anything further (like required confidentiality) conflicts with the backwards-compatibility approach and thus with the rest of the new charter. So I propose we update the charter to include that item and make sure syslog-sign advances. Syslog-protocol can than require all messages to be signed via syslog-sign. Of course, a threat model should also be developed, but please keep in mind that anything other than signatures breaks what this WG has fought for since Vancouver. syslog-protocol should be finished (I hope we are there soon) as well as syslog-transport-udp. Then, these both should be taken to a rest and syslog-sign be modified in the sense of -transport and being worked on. I think this can probably done quickly, because -sign is almost complete and just needs to be modified to take advantage of -protocol. To be honest, though, I have to admit that I expect many of the upcoming implementations to violate syslog-protocol by just implementing -protocol and -transport-udp, but not -sign. But that's probably not something to care about... Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam Hartman > Sent: Thursday, January 05, 2006 11:12 PM > To: [EMAIL PROTECTED] > Subject: [Syslog] Charter comments from IESG Review > > > > Hi. The IESg reviewed the proposed syslog charter at today's telechat > and decided that it requires revision. The main concern seems to be > the lack of a mandatory to implement security mechanism. I indicated > this might be the case in the Vancouver meeting. > > so, you definitely need to have some sort of mandatory to implement > security mechanism. I'm not quite sure what needs to be said about > this in the charter. > But the working group will need to: > > 1) Identify a threat model for syslog > > > 2) Define mechanisms to address these threats. > > So, questions for the threat model include things like whether > confidentiality is important or whether integrity of mesages is > sufficient. > > Depending on the threat model here are some possible solutions: > > 1) Require some transport like syslog over TLS|DTLS be implemented. > > 2) Require that all senders implement signatures stored in structured > data as an option. > > I don't think you need to commit to one of these options now. > However, you do need to reflect the security issues in the charter. > > --Sam > > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
