Subject: RE: [Syslog] Charter comments from IESG Review

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 9 Jan 2006 09:08:39 +0100

Hi Sam & WG,

I understand the reasoning behind requiring a security mechanism. I just
want to remind everyone that a major drawback in Vancouver was that we
had lost some backwards-compatibility to existing syslog
implementations.

The weeks after Vancouver we worked hard to find a minimum consensus on
how we could provide the needed backwards compatibility.

When we mandate a security mechanism, we must be very careful not to
invalidate all these attempts. Why? Simply because any transport-layer
requirement (DTSL, SSL, SSH, whatever) would NOT be compatible with
currently existing syslog implementations. So due to this requirement,
we can not create a backwards-compatible spec (not even in the sense
that existing receivers can put messages in the right bins). So in my
point of view the only option is to use structured-data embedded
signatures. As they do not modify the message format AND work over UDP,
they allow old receivers to receive messages and put them into the right
bins while new receivers can enjoy their benefits.

In my point of view, anything further (like required confidentiality)
conflicts with the backwards-compatibility approach and thus with the
rest of the new charter.

So I propose we update the charter to include that item and make sure
syslog-sign advances. Syslog-protocol can than require all messages to
be signed via syslog-sign.

Of course, a threat model should also be developed, but please keep in
mind that anything other than signatures breaks what this WG has fought
for since Vancouver.

syslog-protocol should be finished (I hope we are there soon) as well as
syslog-transport-udp. Then, these both should be taken to a rest and
syslog-sign be modified in the sense of -transport and being worked on.
I think this can probably done quickly, because -sign is almost complete
and just needs to be modified to take advantage of -protocol.

To be honest, though, I have to admit that I expect many of the upcoming
implementations to violate syslog-protocol by just implementing
-protocol and -transport-udp, but not -sign. But that's probably not
something to care about...

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sam Hartman
> Sent: Thursday, January 05, 2006 11:12 PM
> To: [email-masked]
> Subject: [Syslog] Charter comments from IESG Review
> 
> 
> 
> Hi.  The IESg reviewed the proposed syslog charter at today's telechat
> and decided that it requires revision.  The main concern seems to be
> the lack of a mandatory to implement security mechanism.  I indicated
> this might be the case in the Vancouver meeting.
> 
> so, you definitely need to have some sort of mandatory to implement
> security mechanism.  I'm not quite sure what needs to be said about
> this in the charter.
> But the working group will need to:
> 
> 1) Identify a threat  model for syslog
> 
> 
> 2) Define mechanisms to address these threats.
> 
> So, questions for the threat model include things like whether
> confidentiality is important or whether integrity of mesages is
> sufficient.
> 
> Depending on the threat model here are some possible solutions:
> 
> 1) Require some transport like syslog over TLS|DTLS be implemented.
> 
> 2)  Require that all senders implement signatures stored in structured
>     data as an option.
> 
> I don't think you need to commit to one of these options now.
> However, you do need to reflect the security issues in the charter.
> 
> --Sam
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2006 07:06:40 -0500

>>>>> "Rainer" == Rainer Gerhards <[email-masked]> writes:

    Rainer> Hi Sam & WG, I understand the reasoning behind requiring a
    Rainer> security mechanism. I just want to remind everyone that a
    Rainer> major drawback in Vancouver was that we had lost some
    Rainer> backwards-compatibility to existing syslog
    Rainer> implementations.

    Rainer> The weeks after Vancouver we worked hard to find a minimum
    Rainer> consensus on how we could provide the needed backwards
    Rainer> compatibility.

    Rainer> When we mandate a security mechanism, we must be very
    Rainer> careful not to invalidate all these attempts. 

Agreed.

    Rainer> Why? Simply
    Rainer> because any transport-layer requirement (DTSL, SSL, SSH,
    Rainer> whatever) would NOT be compatible with currently existing
    Rainer> syslog implementations. So due to this requirement, we can
    Rainer> not create a backwards-compatible spec (not even in the
    Rainer> sense that existing receivers can put messages in the
    Rainer> right bins). 

Let's be clear about what backward compatibility we're looking for.
Do we require that new senders be able to be configured to talk to old
receivers?  Or do we require that old receivers be able to put any
message from a new sender into the right place?

In particular what you're seeming to say implies that we cannot define
new transports because doing so would be backward incompatible.  I
don't think that is what we said.

If we do define a new transport, presumably both UDP and the secure
transport would be mandatory to implement.

    Rainer> So in my point of view the only option is to
    Rainer> use structured-data embedded signatures. As they do not
    Rainer> modify the message format AND work over UDP, they allow
    Rainer> old receivers to receive messages and put them into the
    Rainer> right bins while new receivers can enjoy their benefits.

This is a valid approach.  This means delaying protocol until
syslog-sign is ready.  Note that Russ, Bill Fenner and I have serious
questions about syslog-sign because it does not reuse CMS, OpenPGP or
some other format.  We would need these questions answered before it
could go forward in its current form.

You would also need to make syslog-sign mandatory to implement and
would need to believe that people wern't going to just ignore that.

    Rainer> In my point of view, anything further (like required
    Rainer> confidentiality) conflicts with the
    Rainer> backwards-compatibility approach and thus with the rest of
    Rainer> the new charter.

I'm going to ask you to do the analysis in terms of what is required
from a security standpoint.  If that analysis ends up being
incompatible with backward compatibility requirements, then we'll have
to evaluate tradeoffs.  However if there is a solution compatible both
ith security and backward compatibility, that's better.

--Sam

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 10 Jan 2006 10:52:12 +0100

> something to care about...

I know that some other mails discussed the same topic and a
misunderstanding has already been resolved about whether to support
transport-udp or not.

I would say that addressing the security concerns at the transport level
is way easier management and implementation wise than implementing
syslog-sign. And in addition they address a different problem:

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.

-- 
Bazsi

---

From: Darren Reed <[email-masked]>
Date: Tue, 10 Jan 2006 22:02:40 +1100 (EST)

> 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.

> adapting syslog-sign when the transport issues are resolved.

(1) and (2) are complimentary and one do not exclude the other
from being necessary.

Darren

---

From: Balazs Scheidler <[email-masked]>
Date: Tue, 10 Jan 2006 17:27:30 +0100

> same for using a secure protocol at either transport or application

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.

> (1) and (2) are complimentary and one do not exclude the other

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.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 10 Jan 2006 08:33:04 -0800 (PST)

Hi,

> using syslog/TLS is simple.

Agreed.  I'm trying to work up a note that documents that.

> first one as it already solves a lot of problems and will help us keep

Agreed as well.

I appreciate this input and I'll have a proposal out as soon as I can get 
it.  :)

Thanks,
Chris