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

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 9 Jan 2006 14:23:29 +0100

Sam, 

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

I depens on what you mean with that - if "to be configured to talk to
old receivers" means they must not use -protocol but rfc 3164 instead,
this is not what was discussed on this list (-protocol-14 had addressed
this already).

> Or do we require that old receivers be able to put any
> message from a new sender into the right place?

Not over any transport, but the core need behind the recent changes was
that -protocol/-transport-udp messages should allow an old sender to put
it into the right bin. This implies  plain text transmission.

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

This looks like I misunderstood your intension. I thought that unsecured
UDP should no longer be supported. So what you actually said is that we
can go ahead with the unsecured UDP as long as we also mandate a
(different) secure transport.

If that is the case, I am reliefed, because this is something that can
practically be done. And, yes, configuring a sender to use unsecured udp
(-transport-udp) for one target and a secured transport for another
target is definitely a good option. We just need to be able to
interoperate with the "unsecured plain text udp syslog world".

Rainer

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2006 08:35:56 -0500

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

    Rainer> This looks like I misunderstood your intension. I thought
    Rainer> that unsecured UDP should no longer be supported. 

That was not my intent.

    Rainer> So what
    Rainer> you actually said is that we can go ahead with the
    Rainer> unsecured UDP as long as we also mandate a (different)
    Rainer> secure transport.

What I said is that you need to have a mandatory-to-implement mode of
operation that meets your security goals.  You can certainly support
transport-udp.  One way to do this is to have a new secure transport.
Another way to do this (assuming you decide confidentiality need not
be a security goal) is to use something like syslog-sign.

Personally I think a new transport might be more important than
syslog-sign but so long as the WG clearly articulates its security
goals, those goals make sense, and the wg then meets the goals, the
preference between syslog-sign and transport is a WG matter.

Also, I agree that you have described the threats to syslog in
adequate detail already; the question is which threats do you want
toaddress.  You do need to explain that in your documents and you need
to justify that decision.

So, how much needs to be done for the charter?  Well, I'd like text
added to the deliverable for -protocol noting that it will require a
secure mode of operation.  If you are going to decide that syslog-sign
is the right path, then you should add text about that to the charter.
I don't think you need to choose a transport before chartering,
although I caution that transport wars are a good way to lose WG
momentum; look at the ISMS work over the past few IETFs for an
example.

--Sam

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 9 Jan 2006 15:40:46 +0100

Sam

I was about to say that we were getting into useful detail but that we could
sort out the charter without it, but you seem to saying not.  That is, I was
hoping that where the charter says

     The goal of this working group is to address the security and integrity
problems
it might say
    The goal of this working group is to identify the security problems, perform
a threat analysis and document a solution to the perceived threats,

without committing us to either a -sign or a secure transport approach (and yes,
we did start the transport wars, some time ago, with SSH v TLS:-(

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Jan 2006 10:53:37 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> without committing us to either a -sign or a secure transport
    Tom> approach (and yes, we did start the transport wars, some time
    Tom> ago, with SSH v TLS:-(

I really think that you need to identify your deliverables in the
charter.  Either sign is or is not a critical path deliverable.
(Similarly, if you go the transport route, you need a critical path
deliverable of a secure transport.)

--Sam