>>>>> "Rainer" == Rainer Gerhards <[EMAIL PROTECTED]> 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.
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
