Hi Rainer, Comments below:
<snip> > > > http://wiki.rsyslog.com/index.php/TLS_for_syslog_use_cases > > > > > > After close consideration, I think the draft currently fails on > > > addressing the two use cases define above properly. > Partly it fails > > > because it is not possible under the current IESG > requirement to be > > > safe by default. We cannot be fully safe by default without > > > configuration, so whatever we specify will fail for the home user. > > > > > > A compromise may be to provide "good enough" security in > the default > > > policy. I see two ways of doing that: one is to NOT address the > > > Masquerade and Modification threats in the default > policy, just the > > > Disclosure threat. That leads us to unauthenticated > syslog being the > > > default (contrary to what is currently implemented) > [Disclosure is > > > addressed in this scenario as long as the client configs are not > > > compromised, which I find sufficiently enough - someone who can > > > compromise the client config can find other ways to get > hold of the > > > syslog message content]. > > > > > [Joe] If you don't address the relevant threats I'm not > sure you can > > call security "good enough". > > I can do this because, from a practical perspective, what > most people are concerned with is confidentiallity. Let me > ask a question: how can we say HTTPS is secure? After all, > the HTTPS client is almost never authenticated against the > server. From my practical perspective, HTTPS-like security, > easily enabled by default even for the unskilled user is much > better than "full" security that only exists in theory - > because people turn it off. Security is only as good as the > humans using it... > [Joe] We are not talking about HTTPS we are talking about syslog. What applies to one may not necessarily apply to the other (HTTP provides other ways to authenticate the client etc.). In addition HTTPS authenticates the server in most cases. In any case, I don't think you can claim confidentiality if you do not take care of masquerade or man-in-the-middle as either will result in a breach of confidentiality, you are still vulnerable to active attackers. I believe that implementations need to support mutual authentication and authorization with certificates. The recommended mechanisms for this probably still need some discussion, however I think it is important to provide this capability. I think what is more to the point in the current discussion is what is required by default. I would like to suggest that server authentication, certificate path validation and authorization be required by default, because I without this I don't think any security goals are met. I would also suggest that by default clients should present and authenticate with a certificate, however a server does not necessarily need to perform path validation or authorization, it can just record the certificate (or fingerprint) that carries the public key used in the authentication so it can be validated at a later time. This requires configuration on the client, but not necessarily on the server. _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
