Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

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
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog