Subject: RE: [Syslog] Re: Threat model and charter

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 11 Jan 2006 16:15:46 +0100

> I'm concerned that your analysis seems to be based on what is easy to
> implement.

Well, I have to admit that in the world of syslog people vote with their
feet. If it is not easy to implement (better said: deploy), the majority
will not deploy it. Maybe I have a false impression, but I think I am
not totally wrong.

Security is only as secure as people actually use it. Just think about
the nice yellow "post it" notes below the keyboards where all these
strong passwords that nobody can remember are being kept. Is it really a
good thing to have a multitude of strong passwords that leads to people
resort to easily accessible, totally insecure paper notes? Wouldn't it
be better to have fewer and not so totally strong passwords, but ones
that are actually used as designed? I know there can be a lot said in
this regard - I do not want to go into the specifics here. My point is
that security is only as good as it is being accepted by the typical
user. Stronger security might actually turn out to be weaker when you
look at how it is actually *used*.

> We also need to do the analysis of what security is actually required
> by syslog deployments.
> If the ansers are different, we'll have to deal with that.

I thought we are doing this by refering to the sections in RFC 3164 and
syslog-protocol-16. Do you think we need to elaborate more on the
potential threats? If so, we definitely would need to reconsider that
part of the work (also in -protocol, because it should mention at least
all transport-independant threats).

> 
> But e are in a different situation if we decide to do something
> because we don't know how to do better than if we meet what we believe
> the security requirements are.

I think with TLS and certificates we can address the security threads I
mentioned. Making the use of certificates optional for operators is in
the spirit of what I said above.  I don't see any unnecessary evil in
that. After all, even seat belts are somewhat optional. So far, cars
don't force their drivers to wear them (all attempts to actually force
the driver have been circumvented by the user).

Please advise.

Rainer

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jan 2006 10:51:39 -0500

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

    >> I'm concerned that your analysis seems to be based on what is
    >> easy to implement.

    Rainer> Well, I have to admit that in the world of syslog people
    Rainer> vote with their feet. If it is not easy to implement
    Rainer> (better said: deploy), the majority will not deploy
    Rainer> it. Maybe I have a false impression, but I think I am not
    Rainer> totally wrong.

I completely agree with you here.  It is however important for us to
understand the gap between what we can implement and what we believe
people need.  If that gap exists, we'll need to consider what to do
about it.  "Document it," may well be what we decide.

    >> We also need to do the analysis of what security is actually
    >> required by syslog deployments.  If the ansers are different,
    >> we'll have to deal with that.

    Rainer> I thought we are doing this by refering to the sections in
    Rainer> RFC 3164 and syslog-protocol-16. Do you think we need to
    Rainer> elaborate more on the potential threats? If so, we
    Rainer> definitely would need to reconsider that part of the work
    Rainer> (also in -protocol, because it should mention at least all
    Rainer> transport-independant threats).

no, that documents all the threats.  It doesn't actually make a call
as to wether a particular threat is important to solve.

As an example, if integrity is not important to the way people use
syslog, we might not consider it important to provide integrity.  On
the other hand if integrity is important to how syslog is used but we
cannot find a way to deliver integrity in a manner that is useful to
people, we have to carefully consider what to do.

    >>  But e are in a different situation if we decide to do
    >> something because we don't know how to do better than if we
    >> meet what we believe the security requirements are.

    Rainer> I think with TLS and certificates we can address the
    Rainer> security threads I mentioned. Making the use of
    Rainer> certificates optional for operators is in the spirit of
    Rainer> what I said above.  I don't see any unnecessary evil in
    Rainer> that. After all, even seat belts are somewhat optional. So
    Rainer> far, cars don't force their drivers to wear them (all
    Rainer> attempts to actually force the driver have been
    Rainer> circumvented by the user).

Security is completely optional.  We understand that many people will
deploy syslog-udp without security.  That's fine.

The IESG has charged us with delivering a solution that has a
mandatory to implement mode meeting the following two criteria:

1) Meets the security requirements implied by how people use syslog.

2) Is sufficiently easy to use that it does not in practice provide
   weaker security than some other option.

For example, TLS with mandatory certificate authentication on both
sides is more secure than anonymous TLS.  However it's sufficiently
hard to use that many people will choose insecure UDP over
certificates and TLS.  Some of those same people would have chosen
anonymous TLS over secure UDP.  

So, you and Chris have made an argument that we cannot provide
integrity without decreasing the utility of our security solution.

we now need to answer the question of whether integrity should be a
security requirement.  If it should, then we need to go back to the
IESG and say we can't do what they want in an ideal world.  This is
all part of the standard closed loop between requirements analysis and
design.