[Syslog] MUST is for implementers, not users.

["David Harrington" <[e-mail]>]

Hi,

speaking as a contributor ...

I do not believe we should be trying to standardize policy. Policy is
a deployment issue, not an implementation issue.

Our goal should be to provide a mandatory-to-implement mechanism that
operators can enable if desired to protect their messages.

Whether the mechanism is enabled or disabled by default is a decision
that operator/purchasers should discuss with the implemeter/vendors.
It should not be a requirement of the protocol, or the IESG.

There are multiple environments that use syslog. I do not think it is
important to solve the security of syslog messages for environments
where there is no knowledgeable operator. If the operator of a SOHO
device is not clueful enough to cut-and-paste a fingerprint, I doubt
they are clueful enough (or motivated enough) to interpret system
logs. 

I think the OpSec WG is a much better place to discuss policies and
best current practices for logging, including default security
settings. 

This WG should focus only on the mandatory-to-implement security
mechanisms to make it possible for users to address, in a stndardized
manner, security issues in system logging. MUST is for implementers,
not users.

David Harrington
[e-mail]
[e-mail]
[e-mail]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Friday, May 16, 2008 12:58 PM
> To: tom.petch
> Cc: [e-mail]; [e-mail]; syslog; 
> [e-mail]
> Subject: Re: [Syslog] Document shepherd report of AD concerns
> 
> >[tom.petch]
> > <rant>
> > Fundamentally, someone else should be doing this, a policies in 
> > security working
> > group, perhaps a spinoff from pkix or tls (which I know ekr 
> will reject 
> out of
> > hand:-).  We are the wrong people, IMO, to be proposing 
> resolutions to 
> such
> > questions; it should be being done for us by those whose 
> primary role is
> > security, not network management.
> > </rant>
> >
> 
> I wasn't part of that group, but I am part of the policy 
> world.  It makes 
> sense for the syslog group to jointly with some policy people 
> propose that 
> "this is a reasonable risk analysis for the use cases that drive our

> protocol".  The purpose of this risk analysis is the 
> derivation of the 
> underlying protocol requirements.  But then, it is just the protocol

> requirements that remain normative.  The risk analysis lives on for 
> reviewers, so that they have context, and for future users so 
> that they 
> can assess whether their real world implementation risks are 
> significantly 
> different.  If the real world is different, it just means 
> that you need to 
> re-assess whether syslog-tls will meet your needs, will need 
> some extra 
> mitigations, or whatever.  This keeps the policy and risk assessment

> portion non-normative.  So when I review something like this 
> for policy I 
> want to see the analysis, but not see it become normative.
> 
> Real normative policy work does not belong in SDOs at all.  
> It belongs in 
> legislatures, regulatory groups, and business management.  
> I've seen far 
> too many efforts (past and present) where people attempt to 
> use SDOs to 
> bypass the public political process.  They think that making 
> it standard 
> lets them bypass the ugly and difficult problems of dealing with the

> parliamentary process.  It doesn't work.  It just means that 
> the standards 
> become inconsistent with laws and regulations.  That means that 
> implementations become inconsistent.  The SDO policy thought needs
to 
> reflect instead the consideration "what are the range of potential 
> policies that will apply" and make sure that the protocol is able to

> support the bulk of those policies.  The extra from the IESG 
> seems to be 
> that there be some reasonable baseline policy that is a 
> reasonable subset 
> of the bulk of the policies, and mandate that at least that much be 
> supported.
> 
> That's where I end up with the basic notion of having the various 
> certificate stores, some sort of certificate store management, and 
> protocol enforcement of certificate verification.  That 
> leaves a baseline 
> mandatory policy assumption that there will be bidirectional 
> certificate 
> verification within the protocol.  All the rest of policy becomes
the 
> rules around certificate stores and store management.  Those 
> don't belong 
> in syslog standard beyond the requirement that they exist 
> somehow.  Yes, I 
> wish there were more agreement on the policies and the 
> resulting needs for 
> stores and store management.  I can see syslog contributing 
> it's use cases 
> and examples to those needs.  I don't see it incorporating 
> them into the 
> standard, or being the right group to define them.
> 
> I would not divorce the policy work completely.  Most of the
security 
> policy work in SDOs has been dealing with human identity 
> management for 
> various authentication and authorization purposes.  That is a very 
> different application than syslog.  Those use cases do not 
> map well onto 
> the automated machine logging application.
> 
> R Horn
> 

_______________________________________________
Syslog mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/syslog