> I'm concerned that your analysis seems to be based on what is easy to > implement.
Well, I have to admit that in the world of syslog people vote with their feet. If it is not easy to implement (better said: deploy), the majority will not deploy it. Maybe I have a false impression, but I think I am not totally wrong. Security is only as secure as people actually use it. Just think about the nice yellow "post it" notes below the keyboards where all these strong passwords that nobody can remember are being kept. Is it really a good thing to have a multitude of strong passwords that leads to people resort to easily accessible, totally insecure paper notes? Wouldn't it be better to have fewer and not so totally strong passwords, but ones that are actually used as designed? I know there can be a lot said in this regard - I do not want to go into the specifics here. My point is that security is only as good as it is being accepted by the typical user. Stronger security might actually turn out to be weaker when you look at how it is actually *used*. > 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. I thought we are doing this by refering to the sections in RFC 3164 and syslog-protocol-16. Do you think we need to elaborate more on the potential threats? If so, we definitely would need to reconsider that part of the work (also in -protocol, because it should mention at least all transport-independant threats). > > But e are in a different situation if we decide to do something > because we don't know how to do better than if we meet what we believe > the security requirements are. I think with TLS and certificates we can address the security threads I mentioned. Making the use of certificates optional for operators is in the spirit of what I said above. I don't see any unnecessary evil in that. After all, even seat belts are somewhat optional. So far, cars don't force their drivers to wear them (all attempts to actually force the driver have been circumvented by the user). Please advise. Rainer _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
