Re: [Syslog] Document shepherd report of AD concerns

<Pasi.Eronen@nokia.com> Mon, 19 May 2008 08:34 UTC

Return-Path: <syslog-bounces@ietf.org>
X-Original-To: syslog-archive@megatron.ietf.org
Delivered-To: ietfarch-syslog-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF6E73A6AA4; Mon, 19 May 2008 01:34:44 -0700 (PDT)
X-Original-To: syslog@core3.amsl.com
Delivered-To: syslog@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA3D28C136 for <syslog@core3.amsl.com>; Mon, 19 May 2008 01:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.349
X-Spam-Level:
X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXHIAepzVW6x for <syslog@core3.amsl.com>; Mon, 19 May 2008 01:34:43 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id E26113A6861 for <syslog@ietf.org>; Mon, 19 May 2008 01:34:42 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4J8Wv6b005902; Mon, 19 May 2008 03:34:37 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:34:27 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 11:34:27 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 19 May 2008 11:34:25 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72A53500@vaebe104.NOE.Nokia.com>
In-Reply-To: <OF52AAC207.4C0FE54D-ON8525744B.005AA24A-8525744B.005D28CC@agfa.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Syslog] Document shepherd report of AD concerns
Thread-Index: Aci3df/fv9kzp8M3Rt6hSBuImU1MOACEr6vQ
References: <030101c8b762$75f61a40$0601a8c0@allison> <OF52AAC207.4C0FE54D-ON8525744B.005AA24A-8525744B.005D28CC@agfa.com>
From: Pasi.Eronen@nokia.com
To: robert.horn@agfa.com
X-OriginalArrivalTime: 19 May 2008 08:34:27.0325 (UTC) FILETIME=[263E02D0:01C8B98B]
X-Nokia-AV: Clean
Cc: syslog@ietf.org
Subject: Re: [Syslog] Document shepherd report of AD concerns
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

Robert,

We're not attempting to specify policies that deployments are required
to use; we're specifying minimal requirements for management interfaces
to allow interoperability. Such work does belong in the IETF.

Best regards,
Pasi

> -----Original Message-----
> From: ext robert.horn@agfa.com [mailto:robert.horn@agfa.com] 
> Sent: 16 May, 2008 19:58
> To: tom.petch
> Cc: ietfdbh@comcast.net; Eronen Pasi (Nokia-NRC/Helsinki); 
> syslog; syslog-bounces@ietf.org
> 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
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog