In some email I received from Chris M. Lonvick, sie wrote:
[...]
> >Second, I would like to propose to discuss an alternative "secure syslog",
> >especially for "small" systems. This could be a "syslog-mac", it could be a
> >kerborized one(if that is "small"), it could be something else.  I have to
> >think about it more. But I'm willing to do so.
> >
> >But I don't know iff this can be done within our charter (Chris, can you
> >answer this question?)
> 
> I feel sure that we can proceed if others are interested
> in doing so.  I would ask everyone to think about this
> before we agree, however.  If the proposed alternative
> "syslog-mac" were to be much simpler than syslog-sign,
> would people prefer to implement that rather than doing
> the harder work to implement syslog-sign?  
> 
> I'm a bit undecided on this as well.  On one hand, I'd
> like to say that syslog-sign has the attributes that we
> want.  If we start doing other things, then we may
> reduce the importance of that work.  If the proposed 
> alternative "syslog-mac" were to be much simpler than 
> syslog-sign, would people prefer to implement that rather 
> than doing the harder work to implement syslog-sign?  On 
> the other hand, I'd like solutions that work and that will 
> be implemented.  It does sound like "syslog-mac" may have 
> qualities that would appeal to people working on low-end 
> devices.  

I hate to say it, but I have no compassion for people working with
"small" devices.  The capabilities of even the smallest devices is
now much greater than it was 20 or even 10 years ago, to a point
where RISC cpu's with more memory than there was hard disk space
fit into something you can hold in one hand.  We need to be upping
the ante for people who want to play, not because of technology but
because that is what's required to play safely and securely.

There is no watered down version of AES for "slow devices", apart
from the capability to choose keys of varying sizes, starting at
128bits.

If you want to generate insecure syslog messages then do so, but
do not pretend to make them secure by asking for a watered down
version of something that makes them secure.

Darren
(That was in response to the original question more so than Chris's comments)

Reply via email to