Hi,
On Tue, 10 Jan 2006, Balazs Scheidler wrote:
On Tue, 2006-01-10 at 22:02 +1100, Darren Reed wrote:
On Mon, 2006-01-09 at 09:08 +0100, Rainer Gerhards wrote:
I would say that addressing the security concerns at the transport level
is way easier management and implementation wise than implementing
syslog-sign.
I disagree with the statement about management as the problem is the
same for using a secure protocol at either transport or application
level.
My reasoning is that people are "used to" encrypting channels with SSL,
they are used to the PKI requirements it involves, they are familiar
with SSL cipher suites, CA verification parameters and the like, in
summary SSL/TLS itself is a familiar cryptographic framework.
Syslog-sign on the other hand is different, it is true that it is going
to use X.509 PKI, but all the other familiarity is gone. My point
regarding managebility is that network operators use TLS already with a
lot of applications (HTTPS is the primer example), compared to this
using syslog/TLS is simple.
Agreed. I'm trying to work up a note that documents that.
1) transport level implements security mechanisms on a per hop-by-hop
basis, the message itself is not authenticated, each of the relay
stations can modify the message
2) syslog-sign implements per-message, end-to-end authenticity where the
relay hosts cannot modify messages as they are individually signed by
their origin.
So I'd go with using TLS/DTLS on the transport first and then possibly
adapting syslog-sign when the transport issues are resolved.
(1) and (2) are complimentary and one do not exclude the other
from being necessary.
True, (1) and (2) are independent, my point was to give priority to the
first one as it already solves a lot of problems and will help us keep
focused.
Agreed as well.
I appreciate this input and I'll have a proposal out as soon as I can get
it. :)
Thanks,
Chris
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
