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 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, May 16, 2008 12:58 PM > To: tom.petch > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; syslog; > [EMAIL PROTECTED] > 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 [email protected] https://www.ietf.org/mailman/listinfo/syslog
