I think having a "lightweight" secure transport option without requiring PKI is good. If one were to use PKI, no doubt TLS beats SSH as an established standard. But using PKI is not trivial and should not be a requirement IMO.
Based my experience with SSL/TLS on an unrelated product, private key configuration is a very frequent support issue. Of course, some of it could be streamlined with better tools and documentation, but whatever you do it is not as easy as a setting shared secrets. So, I'd prefer to have a basic secure transport option that allows for using a shared secret. If that transport does not provide for privacy, I am fine with that. The added benefit thought is that it is transport-agnostic and adds no overhead on proxies. The validation on receiver end can also be delayed until message is actually used (if at all). Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris > Lonvick (clonvick) > Sent: Tuesday, January 17, 2006 3:21 PM > To: Tom Petch > Cc: [EMAIL PROTECTED]; Sam Hartman > Subject: Re: [Syslog] Re: Threat model and charter > > Hi Tom, > > On Fri, 13 Jan 2006, Tom Petch wrote: > > > Replying to no-one specifically, I think one significant > consideration > > is being missed. > > > > Basing security on a secure transport may already exist as an > > implementation but not as an I-D. I expect it to take at least 6 > > months, more like 12, to produce an IESG ready I-D. By > that time, our > > long-suffering editor of syslog-protocol says he will have had to > > stand down. I believe that means we will never produce the > two I-Ds > > needed for advancement and that the WG will shut down with > nothing done. > > > > More hopefully, I do believe that the threats can be met by > > syslog-sign. Almost every user I talk to about security wants > > encryption. I have to work very hard to do so, but mostly > succeed, in > > demonstrating to them that what they need is message origin > > authentication and integrity and it just so happens that > that is what > > most IPS protocols offer, and, even better, it is much > cheaper than encryption. > > > > I believe syslog falls into this category for most users, > and that the > > aims of syslog-sign will meet most requirements. I hear it > criticised > > for having the wrong algorithms. Fine, we must change that since > > every security system nowadays should be algorithm > agnostic. MD5 got busted, fine we switch to SHA-1. > > SHA-1 under threat, no problem, roll on SHA-256. This > process will go > > on for ever so we must incorporate it in anything we > produce - like syslog-sign. > > > > And, given the state of syslog-sign, current editors still > willing, I > > believe we can get those two I-Ds ready inside four monhts. > > > > The only realistic alternative would be to incorporate signature > > blocks in the style of syslog-sign in the structured data > of the message being authenticated. > > Your suggestion has good reasoning behind it. > > I have not heard back from anyone about how SSL is currently > being implemented for syslog. From that, I might conclude > that message confidentiality is not a priority for the > community. (Responses to that would be welcome.) > > If origin authentication, and loss detection are important > then syslog-sign is a fit. Can we get some discussion on this? > > Thanks, > Chris > > _______________________________________________ > 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
