From syslog-bounces@ietf.org  Mon Jun  2 02:20:55 2008
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 B657D28C1C0;
	Mon,  2 Jun 2008 02:20:55 -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 16DB83A67ED
	for <syslog@core3.amsl.com>; Mon,  2 Jun 2008 02:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5
	tests=[AWL=-1.150, BAYES_50=0.001]
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 a1Q6iT4dTLlR for <syslog@core3.amsl.com>;
	Mon,  2 Jun 2008 02:20:52 -0700 (PDT)
Received: from mk-outboundfilter-5.mail.uk.tiscali.com
	(mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1])
	by core3.amsl.com (Postfix) with ESMTP id 32B6828C251
	for <syslog@ietf.org>; Mon,  2 Jun 2008 02:19:55 -0700 (PDT)
X-Trace: 37204400/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.85
X-SBRS: None
X-RemoteIP: 213.116.60.85
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvQEAB9YQ0jVdDxV/2dsb2JhbACLbKBuAw
X-IronPort-AV: E=Sophos;i="4.27,577,1204502400"; d="scan'208";a="37204400"
X-IP-Direction: IN
Received: from 1cust85.tnt106.lnd4.gbr.da.uu.net (HELO allison)
	([213.116.60.85])
	by smtp.pipex.tiscali.co.uk with SMTP; 02 Jun 2008 10:19:52 +0100
Message-ID: <007501c8c488$c30462a0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
	"Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com><AC1CFD94F59A264488DC2BEC3E890DE505E7E83C@xmb-sjc-225.amer.cisco.com><577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com>
	<009f01c8c196$a8d14000$0601a8c0@allison>
Date: Mon, 2 Jun 2008 10:14:46 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] -transport-tls references to "matching rules"
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
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

Replying to myself, and apologies to those who got my first, mangled attempt at
this,

I have just read

draft-ietf-netconf-tls-02.txt

which covers an almost identical  territory to transport-tls but with
server and client roles reversed; well worth a read.

Where we used to refer to RFC2818, it refers to RFC4642 (which itself
considers relays).

It has a reference to RFC5280 and specifies section 6 for certificate
paths.

It does not consider fingerprinting.

It does not consider alternatives to hostname.

<rant>
As I have said before, I see a crying need for a generic
'application over  ...' I-D for others -  like me - to draw on and reference,
lest we keep inventing our (less than round?) wheels.
</rant>

Tom Petch
>
> ----- Original Message -----

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Mon Jun  2 07:42:24 2008
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 ED7973A6888;
	Mon,  2 Jun 2008 07:42:24 -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 C5C2A3A6813
	for <syslog@core3.amsl.com>; Fri, 30 May 2008 02:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6]
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 Gge6uwVqWDFR for <syslog@core3.amsl.com>;
	Fri, 30 May 2008 02:18:55 -0700 (PDT)
Received: from mk-outboundfilter-1.mail.uk.tiscali.com
	(mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37])
	by core3.amsl.com (Postfix) with ESMTP id 5AE303A67F7
	for <syslog@ietf.org>; Fri, 30 May 2008 02:18:54 -0700 (PDT)
X-Trace: 122681800/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-temporary-group/213.116.60.54
X-SBRS: None
X-RemoteIP: 213.116.60.54
X-IP-MAIL-FROM: ietf2@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqYEAMJiP0jVdDw2/2dsb2JhbACLb6MyAw
X-IronPort-AV: E=Sophos;i="4.27,565,1204502400"; d="scan'208";a="122681800"
X-IP-Direction: IN
Received: from 1cust54.tnt106.lnd4.gbr.da.uu.net (HELO allison)
	([213.116.60.54])
	by smtp.pipex.tiscali.co.uk with SMTP; 30 May 2008 10:18:49 +0100
Message-ID: <017101c8c22d$206b9f20$0601a8c0@allison>
From: "t.petch" <ietf2@dial.pipex.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
	"Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>
References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com><AC1CFD94F59A264488DC2BEC3E890DE505E7E83C@xmb-sjc-225.amer.cisco.com><577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com>
	<009f01c8c196$a8d14000$0601a8c0@allison>
Date: Fri, 30 May 2008 09:55:37 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailman-Approved-At: Mon, 02 Jun 2008 07:42:24 -0700
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] -transport-tls references to "matching rules"
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "t.petch" <ietf2@dial.pipex.com>
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

Replying to myself, I have just read
draft-ietf-syslog-transport-tls-12.txt
which covers an almost identical  territory to transport-tls with server and
client roles reversed; worth a read.

Where we referred to RFC2818, it refers to RFC4642 (which itself considers
relays).

It has a reference to RFC5280 and specifies section 6 for certificate paths.

It does not consider fingerprinting.

It does not consider alternatives to hostname.

And as I have said before, I see a crying need for a generic 'application over
...' I-D for others to draw on and reference, so we do not keep inventing our
(square?) wheels.

Tom Petch

----- Original Message -----
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>; "Joseph Salowey (jsalowey)"
<jsalowey@cisco.com>
Cc: <syslog@ietf.org>
Sent: Thursday, May 29, 2008 4:15 PM
Subject: Re: [Syslog] -transport-tls references to "matching rules"


> I think that the I-D has got a bit mangled.
>
> I liked, and may have been responsible for, the reference to RFC2818 as being
an
> example of the checks to perform on a certificate, written about a well-known
> application by someone familiar with TLS:-)  This was the basis for our
> validation rules, CN deprecated, subjectAltName must be used as an identity
etc
> and it helped (me) to know where they came from.
>
> The mention of certificates warranted a reference and that was provided by
> RFC3280.  This reference was never about validation rules.
>
> We did not used to have certificate path validation.  We do now and I do not
> know a good reference for it; I agree that RFC3280 et seq is not it.  This
lack
> I see as a(nother?) deficiency on the part of the security engineers:-(
>
> Tom Petch
>
> ----- Original Message -----
> From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
> To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
> Cc: <syslog@ietf.org>
> Sent: Thursday, May 29, 2008 8:21 AM
> Subject: Re: [Syslog] -transport-tls references to "matching rules"
>
>

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Wed Jun  4 22:49:31 2008
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 CE5C13A6B59;
	Wed,  4 Jun 2008 22:49:31 -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 6E4B23A6B59
	for <syslog@core3.amsl.com>; Wed,  4 Jun 2008 22:49:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, 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 u7-7WZNSX9FI for <syslog@core3.amsl.com>;
	Wed,  4 Jun 2008 22:49:30 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87])
	by core3.amsl.com (Postfix) with ESMTP id F26BF3A6AEA
	for <syslog@ietf.org>; Wed,  4 Jun 2008 22:49:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,593,1204531200"; d="scan'208";a="30536174"
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-5.cisco.com with ESMTP; 04 Jun 2008 22:49:31 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m555nVTj004749; 
	Wed, 4 Jun 2008 22:49:31 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m555nVxe025772;
	Thu, 5 Jun 2008 05:49:31 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jun 2008 22:48:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 4 Jun 2008 22:49:29 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BD6@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <007501c8c488$c30462a0$0601a8c0@allison>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] -transport-tls references to "matching rules"
Thread-Index: AcjEkdpdHGfMwqthQ5y7SgAF6JwqkACPHh3w
References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com><AC1CFD94F59A264488DC2BEC3E890DE505E7E83C@xmb-sjc-225.amer.cisco.com><577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com>
	<009f01c8c196$a8d14000$0601a8c0@allison>
	<007501c8c488$c30462a0$0601a8c0@allison>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "tom.petch" <cfinss@dial.pipex.com>,
	"Rainer Gerhards" <rgerhards@hq.adiscon.com>
X-OriginalArrivalTime: 05 Jun 2008 05:48:44.0701 (UTC)
	FILETIME=[D0FFBCD0:01C8C6CF]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1450; t=1212644971;
	x=1213508971; c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci
	sco.com>
	|Subject:=20RE=3A=20[Syslog]=20-transport-tls=20references=
	20to=20=22matching=20rules=22 |Sender:=20;
	bh=OI0NKGoNTBs2ZrdXqrmTpYwFHNmCHl2s+PbacGujzkE=;
	b=cNbosJEToPO7lEnoAPGyriy+vfWbFji0mCQaf/Gisjx7+XCgHnrmR5Ld1+
	6KxpwJgR/ToSK+O4fHVc6Hb99IU1gyo5zTyjeT7mhT4R6hozvk8PvERf1kSA
	Qa+waqfI7Q;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim3002 verified; ); 
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] -transport-tls references to "matching rules"
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

Hi Tom,

I think it would be useful to have recommendations for generic
application over TLS. I don't think all applications would be the same,
but I think there could be some common guidelines.  I don't think we
should hold up the TLS syslog draft for this. 

Joe

> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com] 
> Sent: Monday, June 02, 2008 1:15 AM
> To: Rainer Gerhards; Joseph Salowey (jsalowey)
> Cc: syslog
> Subject: Re: [Syslog] -transport-tls references to "matching rules"
> 
> Replying to myself, and apologies to those who got my first, 
> mangled attempt at this,
> 
> I have just read
> 
> draft-ietf-netconf-tls-02.txt
> 
> which covers an almost identical  territory to transport-tls 
> but with server and client roles reversed; well worth a read.
> 
> Where we used to refer to RFC2818, it refers to RFC4642 
> (which itself considers relays).
> 
> It has a reference to RFC5280 and specifies section 6 for 
> certificate paths.
> 
> It does not consider fingerprinting.
> 
> It does not consider alternatives to hostname.
> 
> <rant>
> As I have said before, I see a crying need for a generic 
> 'application over  ...' I-D for others -  like me - to draw 
> on and reference, lest we keep inventing our (less than 
> round?) wheels.
> </rant>
> 
 

> Tom Petch
> >
> > ----- Original Message -----
> 
> 
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Wed Jun  4 23:05:39 2008
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 EDDA43A6D0E;
	Wed,  4 Jun 2008 23:05:39 -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 230053A6C6C
	for <syslog@core3.amsl.com>; Wed,  4 Jun 2008 23:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.000,
	BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
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 WiFj4wT6f+fw for <syslog@core3.amsl.com>;
	Wed,  4 Jun 2008 23:05:32 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id 5221E3A6D1D
	for <syslog@ietf.org>; Wed,  4 Jun 2008 23:05:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id 8F7417ADF8A;
	Thu,  5 Jun 2008 08:04:22 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id pKlsqSCNHtDA; Thu,  5 Jun 2008 08:04:22 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id 42B237AD667;
	Thu,  5 Jun 2008 08:04:22 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 08:05:22 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309160@grfint2.intern.adiscon.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BD6@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: we are finished - was: RE: [Syslog] -transport-tls references to
	"matching rules"
Thread-Index: AcjEkdpdHGfMwqthQ5y7SgAF6JwqkACPHh3wAACDdIA=
References: <577465F99B41C842AAFBE9ED71E70ABA3090D9@grfint2.intern.adiscon.com><AC1CFD94F59A264488DC2BEC3E890DE505E7E83C@xmb-sjc-225.amer.cisco.com><577465F99B41C842AAFBE9ED71E70ABA3090E0@grfint2.intern.adiscon.com>
	<009f01c8c196$a8d14000$0601a8c0@allison>
	<007501c8c488$c30462a0$0601a8c0@allison>
	<AC1CFD94F59A264488DC2BEC3E890DE505EF8BD6@xmb-sjc-225.amer.cisco.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>,
	"tom.petch" <cfinss@dial.pipex.com>
Cc: syslog <syslog@ietf.org>
Subject: [Syslog] we are finished - was: RE: -transport-tls references to
	"matching rules"
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

As someone who followed the recent syslog-protocol series right from the
beginning and as someone who has implemented RFC 3195,
syslog-transport-tls, syslog-transport-udp and syslog-protocol, and as
someone whose implementations of said drafts are being used in practice
by actual people... I think we have reached a good-enough series of
drafts to publish.

Sure, there are a number of imperfections and some things could be more
precisely specified. HOWEVER, we can always do a second revision. What
we have right now is good enough for most needs and flexible enough to
be extended. There are also a lot of folks waiting on the completion of
this work.

I strongly propose that we do a -transport-tls-13 based on Joe's recent
text proposal. I'd appreciate if that -13 would remove the MUST on
ipAddress. But even if it does not, one can live with it.

Once -13 is published, I suggest we continue to work on 3195bis, which
is already posted, solves a lot of issues but needs a bit of polishing.
Based on our desires, we may also do a lot of other things. 

PLEASE LET US FINISH THE CURRENT WORK *NOW*.

I myself have already departed from the standards way by implementing my
own proprietary protocol, and more and more people will follow the
non-standards route if we do not deliver anything. Given the silence of
almost all other implementers on this list, I think I am not the only
one who did so. Remember that the first draft of the current series was
published in 2003, which was five years ago. If we wait another five
years, I think there will no longer be a need for what we specify,
because everybody will use something else (just think of the widespread
use of proprietary TLS protected plain tcp syslog because we did not
manage to get a document out when there was demand for it...). Netconf
notifications, for example, would probably not have been necessary if
there would have been a decent syslog standard 2 years ago (and we could
have been finished 3 (!) years ago if we hadn't blown the nearly
finished doc set in a meeting for reasons I still find hard to
understand).

Rainer

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> Sent: Thursday, June 05, 2008 7:49 AM
> To: tom.petch; Rainer Gerhards
> Cc: syslog
> Subject: RE: [Syslog] -transport-tls references to "matching rules"
> 
> Hi Tom,
> 
> I think it would be useful to have recommendations for generic
> application over TLS. I don't think all applications would be the
same,
> but I think there could be some common guidelines.  I don't think we
> should hold up the TLS syslog draft for this.
> 
> Joe
> 
> > -----Original Message-----
> > From: tom.petch [mailto:cfinss@dial.pipex.com]
> > Sent: Monday, June 02, 2008 1:15 AM
> > To: Rainer Gerhards; Joseph Salowey (jsalowey)
> > Cc: syslog
> > Subject: Re: [Syslog] -transport-tls references to "matching rules"
> >
> > Replying to myself, and apologies to those who got my first,
> > mangled attempt at this,
> >
> > I have just read
> >
> > draft-ietf-netconf-tls-02.txt
> >
> > which covers an almost identical  territory to transport-tls
> > but with server and client roles reversed; well worth a read.
> >
> > Where we used to refer to RFC2818, it refers to RFC4642
> > (which itself considers relays).
> >
> > It has a reference to RFC5280 and specifies section 6 for
> > certificate paths.
> >
> > It does not consider fingerprinting.
> >
> > It does not consider alternatives to hostname.
> >
> > <rant>
> > As I have said before, I see a crying need for a generic
> > 'application over  ...' I-D for others -  like me - to draw
> > on and reference, lest we keep inventing our (less than
> > round?) wheels.
> > </rant>
> >
> 
> 
> > Tom Petch
> > >
> > > ----- Original Message -----
> >
> >
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Wed Jun  4 23:18:37 2008
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 40F273A6BB8;
	Wed,  4 Jun 2008 23:18:37 -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 C577F3A6BB1
	for <syslog@core3.amsl.com>; Wed,  4 Jun 2008 23:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 
	BAYES_00=-2.599, 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 LcpG1mniz-x5 for <syslog@core3.amsl.com>;
	Wed,  4 Jun 2008 23:18:34 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72])
	by core3.amsl.com (Postfix) with ESMTP id C4F103A697F
	for <syslog@ietf.org>; Wed,  4 Jun 2008 23:18:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,593,1204531200"; d="scan'208,223";a="76157768"
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-3.cisco.com with ESMTP; 04 Jun 2008 23:18:40 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m556IeFI016097
	for <syslog@ietf.org>; Wed, 4 Jun 2008 23:18:40 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m556Idls016834
	for <syslog@ietf.org>; Thu, 5 Jun 2008 06:18:40 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 4 Jun 2008 23:18:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 4 Jun 2008 23:19:09 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Subject Name verification policy 
Thread-Index: AcjG1BDxR/5ZXZRfSQuxcgzlgMt+3A==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "syslog" <syslog@ietf.org>
X-OriginalArrivalTime: 05 Jun 2008 06:18:26.0722 (UTC)
	FILETIME=[F72A9020:01C8C6D3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2368; t=1212646720;
	x=1213510720; c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci
	sco.com> |Subject:=20Subject=20Name=20verification=20policy=20
	|Sender:=20; bh=g/rU7tNHLODlN1J8nSf0TOfR7peajxsgf4r/TqbStTM=;
	b=htzJGYfYRgcZjbxcFJ+1WJ1kQ18wZe0MC4NqgmHJQEGwQo4Fn4kXM0c8cW
	izlHduxMCGjMmHEum9OEe7ymk+Ha55KTdiY1BFqTRlvnCQof42uai++pM/4k
	YfrsQ1U/r8;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim4002 verified; ); 
Subject: [Syslog] Subject Name verification policy
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

>From the discussion on the list it seems that the largest issue is with
section 5.1 

It seems that there is rough consensus to demote IP address matching in
certificates to a SHOULD or MAY.  My preference would be to demote it
down to a may and just include it as an example of other things that
could be done, such as matching against the distinguished name as Martin
suggested. 

"Implementations MAY also support authorization based on matching
configured names to other identity attributes.  For example, the
authorization of a device Serial Number against the SerialNumber portion
of the Subject Distinguished Name, IP address against a SubjectAltName
of type ipAddress, or an identity against a subject distinguished name.
Implementations MAY support other checks such as restrictions on the
depth of a certificate chain.  "

As far as hostname matching Tom brought up RFC4642 which has a slightly
different set of rules for matching host names (in particular it is more
restrictive with wildcards).  Text that is more in line with what 4642
has might look like the following:

"	o Host-name-based authorization where the host name of the
authorized peer is compared against the subject fields in the
certificate.  For the purpose of interoperability, implementations MUST
support matching the host name against a SubjectAltName field with a
type of dNSName and SHOULD support checking hostname against the Common
Name portion of the Subject Distinguished Name.  If more than one host
name identity is present in the certificate a match in any one of the
set is considered acceptable.  Matching is case-insensitive.
Implementations also MAY support wildcards to match a range of values.
A "*" wildcard character MAY be used as the left-most name component in
the certificate.  For example, *.example.com would match a.example.com,
foo.example.com, etc., but would not match example.com.  Using a
wildcard for the entire host name makes it possible to deploy
trust-root-based authorization where all credentials issued by a
particular CA trust root are authorized." 

We should also include a discussion on using configured names instead of
names derived from DNS for matching.  

I'll work on clarifying some of the other sections and try to have
another revision by the end of the week.

Cheers,

Joe  
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Wed Jun  4 23:26:31 2008
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 7CDF53A6921;
	Wed,  4 Jun 2008 23:26:31 -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 817323A6921
	for <syslog@core3.amsl.com>; Wed,  4 Jun 2008 23:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=1.050, 
	BAYES_00=-2.599]
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 R8lHJ7-ztAkP for <syslog@core3.amsl.com>;
	Wed,  4 Jun 2008 23:26:27 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id 3F50E3A6845
	for <syslog@ietf.org>; Wed,  4 Jun 2008 23:26:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id E0E5C7ADF8A;
	Thu,  5 Jun 2008 08:25:23 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 5nAzJ8-Y4YYt; Thu,  5 Jun 2008 08:25:23 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id A4DED7AD667;
	Thu,  5 Jun 2008 08:25:23 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 08:26:28 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjG1BDxR/5ZXZRfSQuxcgzlgMt+3AAAJedQ
References: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
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

Hi Joe,

excellent suggestions. I concur to both. 

It may also be useful (but not vital) to include a note that
transport-tls is a secure, but not a 100% reliable protocol (because tcp
without an app-layer ack is unreliable). Lots of folks have the
misconception that just because tcp is used it is reliable. For that,
one needs to implement rfc 3195. But, again, this is not a important
enough point to hold publishing.

Rainer

> -----Original Message-----
> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Thursday, June 05, 2008 8:19 AM
> To: syslog
> Subject: [Syslog] Subject Name verification policy
> 
> From the discussion on the list it seems that the largest issue is
with
> section 5.1
> 
> It seems that there is rough consensus to demote IP address matching
in
> certificates to a SHOULD or MAY.  My preference would be to demote it
> down to a may and just include it as an example of other things that
> could be done, such as matching against the distinguished name as
> Martin
> suggested.
> 
> "Implementations MAY also support authorization based on matching
> configured names to other identity attributes.  For example, the
> authorization of a device Serial Number against the SerialNumber
> portion
> of the Subject Distinguished Name, IP address against a SubjectAltName
> of type ipAddress, or an identity against a subject distinguished
name.
> Implementations MAY support other checks such as restrictions on the
> depth of a certificate chain.  "
> 
> As far as hostname matching Tom brought up RFC4642 which has a
slightly
> different set of rules for matching host names (in particular it is
> more
> restrictive with wildcards).  Text that is more in line with what 4642
> has might look like the following:
> 
> "	o Host-name-based authorization where the host name of the
> authorized peer is compared against the subject fields in the
> certificate.  For the purpose of interoperability, implementations
MUST
> support matching the host name against a SubjectAltName field with a
> type of dNSName and SHOULD support checking hostname against the
Common
> Name portion of the Subject Distinguished Name.  If more than one host
> name identity is present in the certificate a match in any one of the
> set is considered acceptable.  Matching is case-insensitive.
> Implementations also MAY support wildcards to match a range of values.
> A "*" wildcard character MAY be used as the left-most name component
in
> the certificate.  For example, *.example.com would match
a.example.com,
> foo.example.com, etc., but would not match example.com.  Using a
> wildcard for the entire host name makes it possible to deploy
> trust-root-based authorization where all credentials issued by a
> particular CA trust root are authorized."
> 
> We should also include a discussion on using configured names instead
> of
> names derived from DNS for matching.
> 
> I'll work on clarifying some of the other sections and try to have
> another revision by the end of the week.
> 
> Cheers,
> 
> Joe
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 03:45:57 2008
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 E4B8928C102;
	Thu,  5 Jun 2008 03:45:57 -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 8898A3A63C9;
	Thu,  5 Jun 2008 03:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 
	BAYES_00=-2.599]
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 6ZtTpP6f-Umn; Thu,  5 Jun 2008 03:45:55 -0700 (PDT)
Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77])
	by core3.amsl.com (Postfix) with ESMTP id 11DE728C102;
	Thu,  5 Jun 2008 03:45:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,594,1204498800"; d="scan'208";a="41656707"
Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21])
	by mornm02-out.agfa.com with ESMTP; 05 Jun 2008 12:45:51 +0200
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
To: rgerhards@hq.adiscon.com
MIME-Version: 1.0
Message-ID: <OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
From: robert.horn@agfa.com
Date: Thu, 5 Jun 2008 06:45:47 -0400
Cc: syslog <syslog@ietf.org>, syslog-bounces@ietf.org
Subject: Re: [Syslog] Subject Name verification policy
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

I agree with Rainer that those fixes would make it good enough.

[Rainer]
> It may also be useful (but not vital) to include a note that
> transport-tls is a secure, but not a 100% reliable protocol (because tcp
> without an app-layer ack is unreliable). Lots of folks have the
> misconception that just because tcp is used it is reliable. For that,
> one needs to implement rfc 3195. But, again, this is not a important
> enough point to hold publishing.
> 

I worry that getting into the reliability discussion will delay things. 
The reliability discussion is more a tutorial about the limitations of TCP 
and is not syslog specific.  It comes up because syslog users react very 
negatively to the work "unreliable" in UDP and become concerned.

If a reliability note is included, it would help to indicate that TCP 
provides protection against some forms of data loss, such as network 
congestion and data corruption related message loss but not against all 
forms of loss.  The most common form of data loss with TCP involves mobile 
equipment.  If I disconnect a machine from the network without warning, 
move it, and relocate it to somewhere that assigns it a new IP address, 
all the active TCP/IPv4 connections are lost.  A syslog-tls that was using 
one of these connections may, depending on details of timing and 
implementation, suffer undetected data loss.  TCP/IPv6 can be configured 
to reduce or even eliminate this source of data loss, but other lower 
probability sources of loss remain.

All of this discussion would really be advanced education on the error 
recovery capabilities of TCP and is not syslog specific in any way.

R Horn
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 03:59:31 2008
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 B775428C173;
	Thu,  5 Jun 2008 03:59:31 -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 1002F28C16F
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 03:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 BH0tbpfFZWFm for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 03:59:26 -0700 (PDT)
Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de
	[141.89.58.198])
	by core3.amsl.com (Postfix) with ESMTP id 4612728C102
	for <syslog@ietf.org>; Thu,  5 Jun 2008 03:59:26 -0700 (PDT)
Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198])
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 211CA8AAAB
	for <syslog@ietf.org>; Thu,  5 Jun 2008 12:59:31 +0200 (CEST)
X-Virus-Scanned: on mail at asta.uni-potsdam.de
Received: from mail.asta.uni-potsdam.de ([141.89.58.198])
	by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new,
	port 10024) with ESMTP id iOHNLZU6UopG for <syslog@ietf.org>;
	Thu,  5 Jun 2008 12:59:22 +0200 (CEST)
Received: from [192.168.178.21] (BAA4486.baa.pppool.de [77.128.68.134])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK))
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id D42BC7B601
	for <syslog@ietf.org>; Thu,  5 Jun 2008 12:59:20 +0200 (CEST)
Message-ID: <4847C70B.3000701@mschuette.name>
Date: Thu, 05 Jun 2008 12:59:23 +0200
From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= <lists@mschuette.name>
User-Agent: Thunderbird 2.0.0.14 (X11/20080511)
MIME-Version: 1.0
To: syslog@ietf.org
References: <AC1CFD94F59A264488DC2BEC3E890DE505DFD90C@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505DFD90C@xmb-sjc-225.amer.cisco.com>
Subject: Re: [Syslog] Some revised text for syslog TLS
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

Hello,
just two comments from the implementation perspective.

Joseph Salowey (jsalowey) schrieb:
> Both transport receiver and transport sender implementations MUST
> provide a means to generate a key pair and self-signed certificate in
> the case that a key pair and certificate are not available through
> another mechanism.

This might be a problem for some implementations.
And it is only useful if the generated certificate can be stored.
Devices without writable persistant storage would have to generate their
certificates on every restart, thus making them useless for authentication.

> 4.2.2  Certificate Fingerprints
> Both client and server implementations MUST make the certificate
> fingerprint for their certificates available through a management
> interface.  

A "management interface" is a broad term. In practice I would implement
this by logging the certificate's subject and fingerprint on syslogd
startup. (Since the log stream is the only output channel.)

-- 
Martin
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 04:37:51 2008
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 ED41E3A6C35;
	Thu,  5 Jun 2008 04:37:51 -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 B247D3A6C35
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 04:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 8idxw40BYjrw for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 04:37:49 -0700 (PDT)
Received: from ext-nj2ut-6.online-age.net (ext-nj2ut-6.online-age.net
	[64.14.54.235]) by core3.amsl.com (Postfix) with ESMTP id 8EB043A6B6A
	for <syslog@ietf.org>; Thu,  5 Jun 2008 04:37:49 -0700 (PDT)
Received: from int-nj2ut-3.online-age.net (int-nj2ut-3.online-age.net
	[3.159.237.72])
	by ext-nj2ut-6.online-age.net (8.13.6/8.13.6/20051114-SVVS-TLS-DNSBL)
	with ESMTP id m55Bbq10030155
	for <syslog@ietf.org>; Thu, 5 Jun 2008 07:37:54 -0400
Received: from cinmlef01.e2k.ad.ge.com (int-nj2ut-3.online-age.net
	[3.159.237.72])
	by int-nj2ut-3.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP
	id m55BbpgO031301
	for <syslog@ietf.org>; Thu, 5 Jun 2008 07:37:52 -0400
Received: from ALPMLVEM05.e2k.ad.ge.com ([3.159.17.55]) by
	cinmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.2499); 
	Thu, 5 Jun 2008 07:37:48 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 5 Jun 2008 07:37:47 -0400
Message-ID: <124CF5A7D55D6F43A4FD9437F28254D8010B9D9F@ALPMLVEM05.e2k.ad.ge.com>
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjG1BDxR/5ZXZRfSQuxcgzlgMt+3AAAJedQAArcEnA=
References: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
	<577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
From: "Moehrke, John (GE Healthcare)" <John.Moehrke@med.ge.com>
To: "syslog" <syslog@ietf.org>
X-OriginalArrivalTime: 05 Jun 2008 11:37:48.0939 (UTC)
	FILETIME=[94BCD5B0:01C8C700]
Subject: Re: [Syslog] Subject Name verification policy
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

I too support making these last final clarifications and move this
specification along. 

John

> -----Original Message-----
> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
Behalf
> Of Rainer Gerhards
> Sent: Thursday, June 05, 2008 1:26 AM
> To: Joseph Salowey (jsalowey)
> Cc: syslog
> Subject: Re: [Syslog] Subject Name verification policy
> 
> Hi Joe,
> 
> excellent suggestions. I concur to both.
> 
> It may also be useful (but not vital) to include a note that
> transport-tls is a secure, but not a 100% reliable protocol (because
tcp
> without an app-layer ack is unreliable). Lots of folks have the
> misconception that just because tcp is used it is reliable. For that,
> one needs to implement rfc 3195. But, again, this is not a important
> enough point to hold publishing.
> 
> Rainer
> 
> > -----Original Message-----
> > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
> > Behalf Of Joseph Salowey (jsalowey)
> > Sent: Thursday, June 05, 2008 8:19 AM
> > To: syslog
> > Subject: [Syslog] Subject Name verification policy
> >
> > From the discussion on the list it seems that the largest issue is
> with
> > section 5.1
> >
> > It seems that there is rough consensus to demote IP address matching
> in
> > certificates to a SHOULD or MAY.  My preference would be to demote
it
> > down to a may and just include it as an example of other things that
> > could be done, such as matching against the distinguished name as
> > Martin
> > suggested.
> >
> > "Implementations MAY also support authorization based on matching
> > configured names to other identity attributes.  For example, the
> > authorization of a device Serial Number against the SerialNumber
> > portion
> > of the Subject Distinguished Name, IP address against a
SubjectAltName
> > of type ipAddress, or an identity against a subject distinguished
> name.
> > Implementations MAY support other checks such as restrictions on the
> > depth of a certificate chain.  "
> >
> > As far as hostname matching Tom brought up RFC4642 which has a
> slightly
> > different set of rules for matching host names (in particular it is
> > more
> > restrictive with wildcards).  Text that is more in line with what
4642
> > has might look like the following:
> >
> > "	o Host-name-based authorization where the host name of the
> > authorized peer is compared against the subject fields in the
> > certificate.  For the purpose of interoperability, implementations
> MUST
> > support matching the host name against a SubjectAltName field with a
> > type of dNSName and SHOULD support checking hostname against the
> Common
> > Name portion of the Subject Distinguished Name.  If more than one
host
> > name identity is present in the certificate a match in any one of
the
> > set is considered acceptable.  Matching is case-insensitive.
> > Implementations also MAY support wildcards to match a range of
values.
> > A "*" wildcard character MAY be used as the left-most name component
> in
> > the certificate.  For example, *.example.com would match
> a.example.com,
> > foo.example.com, etc., but would not match example.com.  Using a
> > wildcard for the entire host name makes it possible to deploy
> > trust-root-based authorization where all credentials issued by a
> > particular CA trust root are authorized."
> >
> > We should also include a discussion on using configured names
instead
> > of
> > names derived from DNS for matching.
> >
> > I'll work on clarifying some of the other sections and try to have
> > another revision by the end of the week.
> >
> > Cheers,
> >
> > Joe
> > _______________________________________________
> > Syslog mailing list
> > Syslog@ietf.org
> > https://www.ietf.org/mailman/listinfo/syslog
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 05:02:14 2008
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 4314E3A6BAA;
	Thu,  5 Jun 2008 05:02:14 -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 795D628C1B9;
	Thu,  5 Jun 2008 05:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.759
X-Spam-Level: 
X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[AWL=0.840, 
	BAYES_00=-2.599]
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 R1BTTTQrfE3D; Thu,  5 Jun 2008 05:02:08 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id E69A53A6B45;
	Thu,  5 Jun 2008 05:01:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id 0424A7AE005;
	Thu,  5 Jun 2008 13:57:52 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id CGWTSfFsxXCZ; Thu,  5 Jun 2008 13:57:51 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id C448D7AD667;
	Thu,  5 Jun 2008 13:57:51 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 14:01:37 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30916E@grfint2.intern.adiscon.com>
In-Reply-To: <OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjG+vdiVuwXT50ATRun0T+FLqbG0AACEfTg
References: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
	<OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <robert.horn@agfa.com>
Cc: syslog <syslog@ietf.org>, syslog-bounces@ietf.org
Subject: Re: [Syslog] Subject Name verification policy
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

Hi Robert,

I think I should have been more clear. I meant a note along these lines
(and only these lines, without any more specifics).

###
It should be noted that this transport does not use application-level
acknowledgments. As such, there exists situations where loss of data
may occur. This protocol is not suitable if a 100% reliable solution
is desired.
###

... nothing more. I often need to talk to people (sales but
unfortunately technical folks, too) that claim that their implementation
is reliable just because it is based on TCP. While for some one can
assume they know better, at least some do not even know there actually
is a problem. I'd like to make the later aware of the fact. And for the
first sort of folks, it would be very handy to have a good reference
that they are wrong ;)

Rainer

> -----Original Message-----
> From: robert.horn@agfa.com [mailto:robert.horn@agfa.com]
> Sent: Thursday, June 05, 2008 12:46 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); syslog; syslog-bounces@ietf.org
> Subject: Re: [Syslog] Subject Name verification policy
> 
> I agree with Rainer that those fixes would make it good enough.
> 
> [Rainer]
> > It may also be useful (but not vital) to include a note that
> > transport-tls is a secure, but not a 100% reliable protocol (because
> tcp
> > without an app-layer ack is unreliable). Lots of folks have the
> > misconception that just because tcp is used it is reliable. For
that,
> > one needs to implement rfc 3195. But, again, this is not a important
> > enough point to hold publishing.
> >
> 
> I worry that getting into the reliability discussion will delay
things.
> The reliability discussion is more a tutorial about the limitations of
> TCP
> and is not syslog specific.  It comes up because syslog users react
> very
> negatively to the work "unreliable" in UDP and become concerned.
> 
> If a reliability note is included, it would help to indicate that TCP
> provides protection against some forms of data loss, such as network
> congestion and data corruption related message loss but not against
all
> forms of loss.  The most common form of data loss with TCP involves
> mobile
> equipment.  If I disconnect a machine from the network without
warning,
> move it, and relocate it to somewhere that assigns it a new IP
address,
> all the active TCP/IPv4 connections are lost.  A syslog-tls that was
> using
> one of these connections may, depending on details of timing and
> implementation, suffer undetected data loss.  TCP/IPv6 can be
> configured
> to reduce or even eliminate this source of data loss, but other lower
> probability sources of loss remain.
> 
> All of this discussion would really be advanced education on the error
> recovery capabilities of TCP and is not syslog specific in any way.
> 
> R Horn
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 06:23:23 2008
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 103753A6C16;
	Thu,  5 Jun 2008 06:23:23 -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 8995C3A6C16;
	Thu,  5 Jun 2008 06:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 
	BAYES_00=-2.599]
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 ErNkCUCiMycN; Thu,  5 Jun 2008 06:23:20 -0700 (PDT)
Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75])
	by core3.amsl.com (Postfix) with ESMTP id 460383A6828;
	Thu,  5 Jun 2008 06:23:19 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,595,1204498800"; d="scan'208";a="47180760"
Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21])
	by mornm01-out.agfa.com with ESMTP; 05 Jun 2008 15:23:23 +0200
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA30916E@grfint2.intern.adiscon.com>
To: rgerhards@hq.adiscon.com
MIME-Version: 1.0
Message-ID: <OF881FFA06.ED4EA405-ON8525745F.004793D9-8525745F.00498C94@agfa.com>
From: robert.horn@agfa.com
Date: Thu, 5 Jun 2008 09:23:20 -0400
Cc: syslog <syslog@ietf.org>, syslog-bounces@ietf.org
Subject: Re: [Syslog] Subject Name verification policy
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

"Rainer Gerhards" <rgerhards@hq.adiscon.com> wrote on 06/05/2008 08:01:37 
AM:

> I think I should have been more clear. I meant a note along these lines
> (and only these lines, without any more specifics).
> 
> ###
> It should be noted that this transport does not use application-level
> acknowledgments. As such, there exists situations where loss of data
> may occur. This protocol is not suitable if a 100% reliable solution
> is desired.
> ###
> 

How about just
###
It should be noted that this transport does not use application-level
acknowledgments. As such, there exists situations where loss of data
may occur.
###

Maybe someone will find or write a good reference article explaining the 
application level issues with TCP/IPv4, TCP/IPv6, etc.  Then an in depth 
explanation could be given once for all the many applications that care. 
People who are serious about this will need the full details.  The rest 
deserve just the short warning.  I don't want them blindly telling 
everyone that the syslog group has officially said that they shouldn't use 
syslog-tls because it isn't reliable.  That is what would happen if we 
include that final sentence.

There are unsophisticated users who routinely demand 100% reliability.  I 
deal with them by asking about how they plan to handle power failures, 
hurricanes, earthquakes, floods, tornados, etc.  I know that when I cared 
about such stuff I could quote the local power grid reliability statistics 
off the top of my head, and could explain our decision tree on the size of 
the fuel tank for the auxiliary diesel generator.  I was also on top of 
disk drive reliability figures.  This was before RAIDs and hot swap was 
very expensive.  It turned out that downtime for disk drive problems was a 
major issue as you went below 10min/year of downtime.  Their response to 
the basic disaster questions establishes what kind of response to give for 
applications level data loss.

R Horn
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 06:48:53 2008
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 2486128C1B9;
	Thu,  5 Jun 2008 06:48:53 -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 620EE28C17C
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 06:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.700, 
	BAYES_00=-2.599]
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 sHgpVLl3msWa for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 06:48:51 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id D43BD28C180
	for <syslog@ietf.org>; Thu,  5 Jun 2008 06:48:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id 97BA37AE005;
	Thu,  5 Jun 2008 15:44:18 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 8bdUOELX8ESw; Thu,  5 Jun 2008 15:44:18 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id 51D197AD667;
	Thu,  5 Jun 2008 15:44:18 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 15:48:51 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309171@grfint2.intern.adiscon.com>
In-Reply-To: <OF881FFA06.ED4EA405-ON8525745F.004793D9-8525745F.00498C94@agfa.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjHD1mnqFzib95eRB62yU9JX/c1cAAAb7og
References: <577465F99B41C842AAFBE9ED71E70ABA30916E@grfint2.intern.adiscon.com>
	<OF881FFA06.ED4EA405-ON8525745F.004793D9-8525745F.00498C94@agfa.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <robert.horn@agfa.com>
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
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,

I am fine with your text.

<slightlyOffTopic>
The reliability issue is not rooted in disasters or other uncommon
scenarios. As of my testing, confirmed this month by Martin, the
probability of message loss even in a simple server restart case is very
high. For a busy network, I'd say it tends toward 100%, though I cannot
provide hard evidence - I didn't bother to do a statistically large
enough sample to back that statement. After all, it is irrelevant if
there is a 80% or 100% probability - the point is that it is very high
(probability of message loss increases with traffic volume).

In any case, I expect that an operator of an enterprise logging system
will routinely see message loss (if he cares to detect it) inside a
system using -transport-tls. Of course -transport-udp will be much
worse. But the point is that an auditor may very well question the
completeness of the log data under *normal* circumstances. Martin has
found a trick to get some better reliability for these normal
circumstances, but the trick only works in a fast, lossless network with
low traffic volume and without bursts. Plus, it is racy. But it is the
best you can do.
</slightlyOffTopic>

All of this off-topic should NOT go into the document, but it is the
reasoning behind my proposal.

Rainer

> -----Original Message-----
> From: robert.horn@agfa.com [mailto:robert.horn@agfa.com]
> Sent: Thursday, June 05, 2008 3:23 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); syslog; syslog-bounces@ietf.org
> Subject: RE: [Syslog] Subject Name verification policy
> 
> "Rainer Gerhards" <rgerhards@hq.adiscon.com> wrote on 06/05/2008
> 08:01:37
> AM:
> 
> > I think I should have been more clear. I meant a note along these
> lines
> > (and only these lines, without any more specifics).
> >
> > ###
> > It should be noted that this transport does not use
application-level
> > acknowledgments. As such, there exists situations where loss of data
> > may occur. This protocol is not suitable if a 100% reliable solution
> > is desired.
> > ###
> >
> 
> How about just
> ###
> It should be noted that this transport does not use application-level
> acknowledgments. As such, there exists situations where loss of data
> may occur.
> ###
> 
> Maybe someone will find or write a good reference article explaining
> the
> application level issues with TCP/IPv4, TCP/IPv6, etc.  Then an in
> depth
> explanation could be given once for all the many applications that
> care.
> People who are serious about this will need the full details.  The
rest
> deserve just the short warning.  I don't want them blindly telling
> everyone that the syslog group has officially said that they shouldn't
> use
> syslog-tls because it isn't reliable.  That is what would happen if we
> include that final sentence.
> 
> There are unsophisticated users who routinely demand 100% reliability.
> I
> deal with them by asking about how they plan to handle power failures,
> hurricanes, earthquakes, floods, tornados, etc.  I know that when I
> cared
> about such stuff I could quote the local power grid reliability
> statistics
> off the top of my head, and could explain our decision tree on the
size
> of
> the fuel tank for the auxiliary diesel generator.  I was also on top
of
> disk drive reliability figures.  This was before RAIDs and hot swap
was
> very expensive.  It turned out that downtime for disk drive problems
> was a
> major issue as you went below 10min/year of downtime.  Their response
> to
> the basic disaster questions establishes what kind of response to give
> for
> applications level data loss.
> 
> R Horn
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 07:37:47 2008
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 2B3F33A6D39;
	Thu,  5 Jun 2008 07:37:47 -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 34C1B3A6D36
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 07:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.600, 
	BAYES_00=-2.599]
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 2+Gphe1pVE4f for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 07:37:44 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id 14DC528C1E7
	for <syslog@ietf.org>; Thu,  5 Jun 2008 07:36:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id 36D2F7AD667;
	Thu,  5 Jun 2008 16:31:52 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id J2Rso7MFozjY; Thu,  5 Jun 2008 16:31:52 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id D9A1E7AD3DD;
	Thu,  5 Jun 2008 16:31:51 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 16:36:42 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA30917A@grfint2.intern.adiscon.com>
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309171@grfint2.intern.adiscon.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjHD1mnqFzib95eRB62yU9JX/c1cAAAb7ogAAISysA=
References: <577465F99B41C842AAFBE9ED71E70ABA30916E@grfint2.intern.adiscon.com><OF881FFA06.ED4EA405-ON8525745F.004793D9-8525745F.00498C94@agfa.com>
	<577465F99B41C842AAFBE9ED71E70ABA309171@grfint2.intern.adiscon.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
	<robert.horn@agfa.com>
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
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

I need to correct myself slightly... (below)

> -----Original Message-----
> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
> Behalf Of Rainer Gerhards
> Sent: Thursday, June 05, 2008 3:49 PM
> To: robert.horn@agfa.com
> Cc: syslog
> Subject: Re: [Syslog] Subject Name verification policy
> 
> Robert,
> 
> I am fine with your text.
> 
> <slightlyOffTopic>
> The reliability issue is not rooted in disasters or other uncommon
> scenarios. As of my testing, confirmed this month by Martin, the
> probability of message loss even in a simple server restart case is
> very
> high. For a busy network, I'd say it tends toward 100%, though I
cannot
> provide hard evidence - I didn't bother to do a statistically large
> enough sample to back that statement. After all, it is irrelevant if
> there is a 80% or 100% probability - the point is that it is very high
> (probability of message loss increases with traffic volume).

This was the number for (non-standard) plain TCP syslog (still widely
deployed). With -transport-tls, it looks a bit better, because we have
the TLS closure process. But there are still issues. Just to clarify.

> In any case, I expect that an operator of an enterprise logging system
> will routinely see message loss (if he cares to detect it) inside a
> system using -transport-tls. Of course -transport-udp will be much
> worse. But the point is that an auditor may very well question the
> completeness of the log data under *normal* circumstances. Martin has
> found a trick to get some better reliability for these normal
> circumstances, but the trick only works in a fast, lossless network
> with
> low traffic volume and without bursts. Plus, it is racy. But it is the
> best you can do.
> </slightlyOffTopic>
> 
> All of this off-topic should NOT go into the document, but it is the
> reasoning behind my proposal.
> 
> Rainer
> 
> > -----Original Message-----
> > From: robert.horn@agfa.com [mailto:robert.horn@agfa.com]
> > Sent: Thursday, June 05, 2008 3:23 PM
> > To: Rainer Gerhards
> > Cc: Joseph Salowey (jsalowey); syslog; syslog-bounces@ietf.org
> > Subject: RE: [Syslog] Subject Name verification policy
> >
> > "Rainer Gerhards" <rgerhards@hq.adiscon.com> wrote on 06/05/2008
> > 08:01:37
> > AM:
> >
> > > I think I should have been more clear. I meant a note along these
> > lines
> > > (and only these lines, without any more specifics).
> > >
> > > ###
> > > It should be noted that this transport does not use
> application-level
> > > acknowledgments. As such, there exists situations where loss of
> data
> > > may occur. This protocol is not suitable if a 100% reliable
> solution
> > > is desired.
> > > ###
> > >
> >
> > How about just
> > ###
> > It should be noted that this transport does not use
application-level
> > acknowledgments. As such, there exists situations where loss of data
> > may occur.
> > ###
> >
> > Maybe someone will find or write a good reference article explaining
> > the
> > application level issues with TCP/IPv4, TCP/IPv6, etc.  Then an in
> > depth
> > explanation could be given once for all the many applications that
> > care.
> > People who are serious about this will need the full details.  The
> rest
> > deserve just the short warning.  I don't want them blindly telling
> > everyone that the syslog group has officially said that they
> shouldn't
> > use
> > syslog-tls because it isn't reliable.  That is what would happen if
> we
> > include that final sentence.
> >
> > There are unsophisticated users who routinely demand 100%
> reliability.
> > I
> > deal with them by asking about how they plan to handle power
> failures,
> > hurricanes, earthquakes, floods, tornados, etc.  I know that when I
> > cared
> > about such stuff I could quote the local power grid reliability
> > statistics
> > off the top of my head, and could explain our decision tree on the
> size
> > of
> > the fuel tank for the auxiliary diesel generator.  I was also on top
> of
> > disk drive reliability figures.  This was before RAIDs and hot swap
> was
> > very expensive.  It turned out that downtime for disk drive problems
> > was a
> > major issue as you went below 10min/year of downtime.  Their
response
> > to
> > the basic disaster questions establishes what kind of response to
> give
> > for
> > applications level data loss.
> >
> > R Horn
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 08:18:09 2008
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 3EE4C3A68E6;
	Thu,  5 Jun 2008 08:18:09 -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 2884E3A68E6
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 08:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level: 
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 
	BAYES_00=-2.599]
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 sAovC5wrFwxz for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 08:18:07 -0700 (PDT)
Received: from mornm01-out.agfa.com (mornm01-out.agfa.com [134.54.1.75])
	by core3.amsl.com (Postfix) with ESMTP id E99913A68C9
	for <syslog@ietf.org>; Thu,  5 Jun 2008 08:18:05 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,596,1204498800"; d="scan'208";a="47193721"
Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21])
	by mornm01-out.agfa.com with ESMTP; 05 Jun 2008 17:17:56 +0200
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA309171@grfint2.intern.adiscon.com>
To: rgerhards@hq.adiscon.com
MIME-Version: 1.0
Message-ID: <OF1E3889AB.92AF2EC1-ON8525745F.0053A70C-8525745F.00540926@agfa.com>
From: robert.horn@agfa.com
Date: Thu, 5 Jun 2008 11:17:53 -0400
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
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

I just brought up disaster because I use it as a good way to separate 
users who do understand the issues from those who do not.  I hadn't 
thought of the auditor case.  It is possible for a naive user to be asked 
about this by an auditor.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Thu Jun  5 08:25:04 2008
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 AFD473A69A8;
	Thu,  5 Jun 2008 08:25:04 -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 52A153A6AD6
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 08:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level: 
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525, 
	BAYES_00=-2.599]
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 eFwqWme-Usgb for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 08:24:57 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18])
	by core3.amsl.com (Postfix) with ESMTP id BAF8C28C2A5
	for <syslog@ietf.org>; Thu,  5 Jun 2008 08:24:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
	by mailin.adiscon.com (Postfix) with ESMTP id 11E937AD667;
	Thu,  5 Jun 2008 17:19:09 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1])
	by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 2GV-h5Q4CK1k; Thu,  5 Jun 2008 17:19:08 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de
	[80.152.154.124])
	by mailin.adiscon.com (Postfix) with ESMTP id D112B7AD3DD;
	Thu,  5 Jun 2008 17:19:08 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Thu, 5 Jun 2008 17:24:41 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA309180@grfint2.intern.adiscon.com>
In-Reply-To: <OF1E3889AB.92AF2EC1-ON8525745F.0053A70C-8525745F.00540926@agfa.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjHH2R6SjDr3fioQuOz4Z4eoYeX4AAAHcZg
References: <577465F99B41C842AAFBE9ED71E70ABA309171@grfint2.intern.adiscon.com>
	<OF1E3889AB.92AF2EC1-ON8525745F.0053A70C-8525745F.00540926@agfa.com>
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <robert.horn@agfa.com>
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
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

Not for the draft, again: it gets even more problematic if logs are used
as evidence in court. Without going into all the details (what I am not
qualified at all), the reliability of the logging system (as well as the
authenticity) can and will probably be questioned in court. If now a
single line can alter the meaning of the evidence, a transport that can
experience loss of message during regular operations may be totally
unsuitable for use inside a legal-compliant logging system (different
parts of the world have obviously different legislation). So I find it
most useful to hint users about potential problems that arise out of the
transport - especially if there is a common misconception.

Rainer

> -----Original Message-----
> From: robert.horn@agfa.com [mailto:robert.horn@agfa.com]
> Sent: Thursday, June 05, 2008 5:18 PM
> To: Rainer Gerhards
> Cc: Joseph Salowey (jsalowey); syslog
> Subject: RE: [Syslog] Subject Name verification policy
> 
> I just brought up disaster because I use it as a good way to separate
> users who do understand the issues from those who do not.  I hadn't
> thought of the auditor case.  It is possible for a naive user to be
> asked
> about this by an auditor.
> 
> Kind Regards,
> 
> Robert Horn | Agfa HealthCare
> Research Scientist | HE/Technology Office
> T  +1 978 897 4860
> 
> Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ,
> 07660-2199, United States
> http://www.agfa.com/healthcare/
> Click on link to read important disclaimer:
> http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 07:31:24 2008
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 16DE03A6D78;
	Fri,  6 Jun 2008 07:31:24 -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 E43883A6A94
	for <syslog@core3.amsl.com>; Fri,  6 Jun 2008 07:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 
	BAYES_00=-2.599]
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 6VD3P5iPThG8 for <syslog@core3.amsl.com>;
	Fri,  6 Jun 2008 07:31:22 -0700 (PDT)
Received: from QMTA08.westchester.pa.mail.comcast.net
	(qmta08.westchester.pa.mail.comcast.net [76.96.62.80])
	by core3.amsl.com (Postfix) with ESMTP id EE6213A6B8F
	for <syslog@ietf.org>; Fri,  6 Jun 2008 07:31:21 -0700 (PDT)
Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28])
	by QMTA08.westchester.pa.mail.comcast.net with comcast
	id adTB1Z00W0cZkys5803K00; Fri, 06 Jun 2008 14:31:31 +0000
Received: from Harrington73653 ([24.128.66.199])
	by OMTA10.westchester.pa.mail.comcast.net with comcast
	id aeXW1Z00H4HwxpC3W00000; Fri, 06 Jun 2008 14:31:31 +0000
X-Authority-Analysis: v=1.0 c=1 a=g7vRhuEHSxIA:10 a=5z37iDLUI1UA:10
	a=xiQHP8GZRAkAcT_YX6cA:9 a=e9beWCoihqkmjhnqtsoBhV5_a8YA:4
	a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=6bqG61NMjcsA:10
From: "David Harrington" <ietfdbh@comcast.net>
To: "'syslog'" <syslog@ietf.org>
Date: Fri, 6 Jun 2008 10:31:27 -0400
Message-ID: <034701c8c7e2$0143b550$0600a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjHTuVkBU1xO6pFQzae2hHzRRu40QAktU2w
Subject: [Syslog] FW: ID Tracker State Update Notice:
	draft-ietf-syslog-tc-mib
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

Congratulations!

The syslog-tc-mib document has been approved by the IESG. Thanks to
all those, especially Glenn, who worked hard to get this document
completed.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 10:42:58 2008
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 792293A68D7;
	Fri,  6 Jun 2008 10:42:58 -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 509F83A68D7
	for <syslog@core3.amsl.com>; Fri,  6 Jun 2008 10:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.335
X-Spam-Level: 
X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 
	BAYES_00=-2.599]
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 UqztUyjYLTjW for <syslog@core3.amsl.com>;
	Fri,  6 Jun 2008 10:42:55 -0700 (PDT)
Received: from mk-outboundfilter-5.mail.uk.tiscali.com
	(mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1])
	by core3.amsl.com (Postfix) with ESMTP id 53B943A6825
	for <syslog@ietf.org>; Fri,  6 Jun 2008 10:42:54 -0700 (PDT)
X-Trace: 39813677/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$ACCEPTED/pipex-customers/62.188.134.14
X-SBRS: None
X-RemoteIP: 62.188.134.14
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApsEAIsTSUg+vIYO/2dsb2JhbACLcKUEAw
X-IronPort-AV: E=Sophos;i="4.27,601,1204502400"; d="scan'208";a="39813677"
X-IP-Direction: IN
Received: from 1cust14.tnt5.lnd4.gbr.da.uu.net (HELO allison) ([62.188.134.14])
	by smtp.pipex.tiscali.co.uk with SMTP; 06 Jun 2008 18:42:58 +0100
Message-ID: <007001c8c7f3$b15558c0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Rainer Gerhards" <rgerhards@hq.adiscon.com>,
	<robert.horn@agfa.com>
References: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com><OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
	<577465F99B41C842AAFBE9ED71E70ABA30916E@grfint2.intern.adiscon.com>
Date: Fri, 6 Jun 2008 18:35:57 +0200
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] Subject Name verification policy
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
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

I concur with the sentiments expressed in this thread.

I would prefer not to talk of transport using application, since it subverts my
idea of the stack.  Rather I would say that the syslog application does not have
application level acknowledgements and that the use of TLS and TCP as a
transport does not change this.

Tom Petch


----- Original Message -----
From: "Rainer Gerhards" <rgerhards@hq.adiscon.com>
To: <robert.horn@agfa.com>
Cc: "syslog" <syslog@ietf.org>; <syslog-bounces@ietf.org>
Sent: Thursday, June 05, 2008 2:01 PM
Subject: Re: [Syslog] Subject Name verification policy


> Hi Robert,
>
> I think I should have been more clear. I meant a note along these lines
> (and only these lines, without any more specifics).
>
> ###
> It should be noted that this transport does not use application-level
> acknowledgments. As such, there exists situations where loss of data
> may occur. This protocol is not suitable if a 100% reliable solution
> is desired.
> ###
>
> ... nothing more. I often need to talk to people (sales but
> unfortunately technical folks, too) that claim that their implementation
> is reliable just because it is based on TCP. While for some one can
> assume they know better, at least some do not even know there actually
> is a problem. I'd like to make the later aware of the fact. And for the
> first sort of folks, it would be very handy to have a good reference
> that they are wrong ;)
>
> Rainer
>
> > -----Original Message-----
> > From: robert.horn@agfa.com [mailto:robert.horn@agfa.com]
> > Sent: Thursday, June 05, 2008 12:46 PM
> > To: Rainer Gerhards
> > Cc: Joseph Salowey (jsalowey); syslog; syslog-bounces@ietf.org
> > Subject: Re: [Syslog] Subject Name verification policy
> >
> > I agree with Rainer that those fixes would make it good enough.
> >
> > [Rainer]
> > > It may also be useful (but not vital) to include a note that
> > > transport-tls is a secure, but not a 100% reliable protocol (because
> > tcp
> > > without an app-layer ack is unreliable). Lots of folks have the
> > > misconception that just because tcp is used it is reliable. For
> that,
> > > one needs to implement rfc 3195. But, again, this is not a important
> > > enough point to hold publishing.
> > >
> >
> > I worry that getting into the reliability discussion will delay
> things.
> > The reliability discussion is more a tutorial about the limitations of
> > TCP
> > and is not syslog specific.  It comes up because syslog users react
> > very
> > negatively to the work "unreliable" in UDP and become concerned.
> >
> > If a reliability note is included, it would help to indicate that TCP
> > provides protection against some forms of data loss, such as network
> > congestion and data corruption related message loss but not against
> all
> > forms of loss.  The most common form of data loss with TCP involves
> > mobile
> > equipment.  If I disconnect a machine from the network without
> warning,
> > move it, and relocate it to somewhere that assigns it a new IP
> address,
> > all the active TCP/IPv4 connections are lost.  A syslog-tls that was
> > using
> > one of these connections may, depending on details of timing and
> > implementation, suffer undetected data loss.  TCP/IPv6 can be
> > configured
> > to reduce or even eliminate this source of data loss, but other lower
> > probability sources of loss remain.
> >
> > All of this discussion would really be advanced education on the error
> > recovery capabilities of TCP and is not syslog specific in any way.
> >
> > R Horn
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 13:38:50 2008
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 C61B528C268;
	Fri,  6 Jun 2008 13:38:50 -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 7415128C264
	for <syslog@core3.amsl.com>; Fri,  6 Jun 2008 13:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 
	BAYES_00=-2.599]
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 CIeEcHSfAUda for <syslog@core3.amsl.com>;
	Fri,  6 Jun 2008 13:38:48 -0700 (PDT)
Received: from QMTA04.emeryville.ca.mail.comcast.net
	(qmta04.emeryville.ca.mail.comcast.net [76.96.30.40])
	by core3.amsl.com (Postfix) with ESMTP id B150828C268
	for <syslog@ietf.org>; Fri,  6 Jun 2008 13:38:48 -0700 (PDT)
Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36])
	by QMTA04.emeryville.ca.mail.comcast.net with comcast
	id akXm1Z0020mlR8UA400s00; Fri, 06 Jun 2008 20:38:58 +0000
Received: from Harrington73653 ([24.128.66.199])
	by OMTA11.emeryville.ca.mail.comcast.net with comcast
	id akev1Z0044HwxpC8X00000; Fri, 06 Jun 2008 20:38:57 +0000
X-Authority-Analysis: v=1.0 c=1 a=puDX5FqrnVcA:10 a=rkUMbiuwccQA:10
	a=riyp4iDt6m4mQeNo3igA:9 a=S7FSHYA0z-GeCsRqvnHcVf91wA4A:4
	a=lZB815dzVvQA:10
	a=84tl6Pyz8z4A:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10
From: "David Harrington" <ietfdbh@comcast.net>
To: <robert.horn@agfa.com>,
	<rgerhards@hq.adiscon.com>
References: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com>
	<OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
Date: Fri, 6 Jun 2008 16:38:50 -0400
Message-ID: <039001c8c815$55907ca0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjG+Vs9VXebG1edS6iJXaZnwB9mFQBF+xgQ
Cc: 'syslog' <syslog@ietf.org>, syslog-bounces@ietf.org
Subject: Re: [Syslog] Subject Name verification policy
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

 

> -----Original Message-----
> From: syslog-bounces@ietf.org 
> [mailto:syslog-bounces@ietf.org] On Behalf Of robert.horn@agfa.com
> Sent: Thursday, June 05, 2008 6:46 AM
> To: rgerhards@hq.adiscon.com
> Cc: syslog; syslog-bounces@ietf.org
> Subject: Re: [Syslog] Subject Name verification policy
> 
> I agree with Rainer that those fixes would make it good enough.
> 
> [Rainer]
> > It may also be useful (but not vital) to include a note that
> > transport-tls is a secure, but not a 100% reliable protocol 
> (because tcp
> > without an app-layer ack is unreliable). Lots of folks have the
> > misconception that just because tcp is used it is reliable. 
> For that,
> > one needs to implement rfc 3195. But, again, this is not a
important
> > enough point to hold publishing.
> > 
> 
> I worry that getting into the reliability discussion will 
> delay things. 
> The reliability discussion is more a tutorial about the 
> limitations of TCP 
> and is not syslog specific.  It comes up because syslog users 
> react very 
> negatively to the work "unreliable" in UDP and become concerned.
> 
[...]
> All of this discussion would really be advanced education on 
> the error 
> recovery capabilities of TCP and is not syslog specific in any way.
> 

I disagree. I think Rainer pointed out that the lack of an application
ACK limits reliability, and the lack of a syslog ACK is definitely
syslog specific. A small note to this effect in the security
considerations should be adequate.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 14:38:20 2008
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 2A9F83A6BF6;
	Fri,  6 Jun 2008 14:38:20 -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 B4E3228C125
	for <syslog@core3.amsl.com>; Thu,  5 Jun 2008 04:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 6UlgExmXaMPD for <syslog@core3.amsl.com>;
	Thu,  5 Jun 2008 04:00:07 -0700 (PDT)
Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de
	[141.89.58.198])
	by core3.amsl.com (Postfix) with ESMTP id BAB2728C102
	for <syslog@ietf.org>; Thu,  5 Jun 2008 04:00:07 -0700 (PDT)
Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198])
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id BF29F7B601
	for <syslog@ietf.org>; Thu,  5 Jun 2008 13:00:12 +0200 (CEST)
X-Virus-Scanned: on mail at asta.uni-potsdam.de
Received: from mail.asta.uni-potsdam.de ([141.89.58.198])
	by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new,
	port 10024) with ESMTP id L4iYfYX7G1MW for <syslog@ietf.org>;
	Thu,  5 Jun 2008 13:00:03 +0200 (CEST)
Received: from [192.168.178.21] (BAA4486.baa.pppool.de [77.128.68.134])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK))
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 66BC6D25BA
	for <syslog@ietf.org>; Thu,  5 Jun 2008 13:00:03 +0200 (CEST)
Message-ID: <4847C736.9040503@mschuette.name>
Date: Thu, 05 Jun 2008 13:00:06 +0200
From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= <info@mschuette.name>
User-Agent: Thunderbird 2.0.0.14 (X11/20080511)
MIME-Version: 1.0
To: syslog <syslog@ietf.org>
References: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
X-Enigmail-Version: 0.95.6
X-Mailman-Approved-At: Fri, 06 Jun 2008 14:38:18 -0700
Subject: Re: [Syslog] Subject Name verification policy
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

Joseph Salowey (jsalowey) schrieb:
> "	o Host-name-based authorization where the host name of the
> authorized peer is compared against the subject fields in the
> certificate.  For the purpose of interoperability, implementations MUST
> support matching the host name against a SubjectAltName field with a
> type of dNSName and SHOULD support checking hostname against the Common
> Name portion of the Subject Distinguished Name.

So that means one has to do DNS lookup for name matching?

What happened to the requirement from draft 12:
> For subject name verification, client implementations MUST support
>    configuring, for each transport receiver, the name to be matched
>    against the certificate.

IMHO that is a useful requirement because it allows the user to 
configure the hostname by IP and still match against a dNSName in the 
certificate.
This easily allows DNS-independent syslog configurations without having 
iPAddresses in the certificates and having to match against them.

> Implementations also MAY support wildcards to match a range of values.
> A "*" wildcard character MAY be used as the left-most name component in
> the certificate.

So this only applies to wildcards in the certificate?

If a configured name is used for matching, should that be allowed to 
contain wildcards as well? (I hope not because that would make the whole 
name matching useless.)

> We should also include a discussion on using configured names instead of
> names derived from DNS for matching.  

See above.
My current implementation uses only the hostname and an optional 
configured subject name for matching. That way I avoid DNS for 
certificate matching and I consider that a feature.

-- 
Martin
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 17:46:39 2008
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 6FA993A6965;
	Fri,  6 Jun 2008 17:46:39 -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 90FBF3A6911
	for <syslog@core3.amsl.com>; Fri,  6 Jun 2008 17:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 anUzP7K7hx39 for <syslog@core3.amsl.com>;
	Fri,  6 Jun 2008 17:46:37 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72])
	by core3.amsl.com (Postfix) with ESMTP id BD62D3A6965
	for <syslog@ietf.org>; Fri,  6 Jun 2008 17:46:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,603,1204531200"; d="scan'208";a="77024891"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-3.cisco.com with ESMTP; 06 Jun 2008 17:46:47 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m570klof024331; 
	Fri, 6 Jun 2008 17:46:47 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m570klrm004089;
	Sat, 7 Jun 2008 00:46:47 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 6 Jun 2008 17:46:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 6 Jun 2008 17:47:32 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE505F599D7@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4847C736.9040503@mschuette.name>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] Subject Name verification policy
Thread-Index: AcjIHbgMLHgD5v6gRhmtrgSIKj82kgAGDRvQ
References: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>
	<4847C736.9040503@mschuette.name>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: =?iso-8859-1?Q?Martin_Sch=FCtte?= <info@mschuette.name>,
	"syslog" <syslog@ietf.org>
X-OriginalArrivalTime: 07 Jun 2008 00:46:47.0488 (UTC)
	FILETIME=[F71FEC00:01C8C837]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3721; t=1212799607;
	x=1213663607; c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=jsalowey@cisco.com;
	z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci
	sco.com>
	|Subject:=20RE=3A=20[Syslog]=20Subject=20Name=20verificatio
	n=20policy |Sender:=20;
	bh=yfZeGfJ1Tb2nhv77alXG7TwHVtjhGCUPBIcJ5J4BEsI=;
	b=T1Nt+gcQdafXrWNIkGQMxMQ5NV1trl/7V0f4pnxSRrLFTkFOZ+xVnsm9j4
	CjsG8MffETh6YkqRkObWlXTN1wsY+rodJFzeTRvm1Cn3IU1yFQg4ApweqTah
	D3T1PQQ8hW;
Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
Subject: Re: [Syslog] Subject Name verification policy
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

Hi Martin

Thanks for looking at this. =


> -----Original Message-----
> From: syslog-bounces@ietf.org =

> [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte
> Sent: Thursday, June 05, 2008 4:00 AM
> To: syslog
> Subject: Re: [Syslog] Subject Name verification policy
> =

> Joseph Salowey (jsalowey) schrieb:
> > "	o Host-name-based authorization where the host name of the
> > authorized peer is compared against the subject fields in the =

> > certificate.  For the purpose of interoperability, implementations =

> > MUST support matching the host name against a SubjectAltName field =

> > with a type of dNSName and SHOULD support checking hostname against =

> > the Common Name portion of the Subject Distinguished Name.
> =

> So that means one has to do DNS lookup for name matching?
> =

[Joe] Correct DNS lookups should not be done when matching.  =


> What happened to the requirement from draft 12:
> > For subject name verification, client implementations MUST support
> >    configuring, for each transport receiver, the name to be matched
> >    against the certificate.
> =

> IMHO that is a useful requirement because it allows the user =

> to configure the hostname by IP and still match against a =

> dNSName in the certificate.
> This easily allows DNS-independent syslog configurations =

> without having iPAddresses in the certificates and having to =

> match against them.
> =

[Joe] I think I see your point, how about modifying the text such that host=
 name is replaced by "configured name" as below: =


"o Host-name-based authorization where a configured name of the authorized =
peer is compared against the subject fields in the certificate.  For the pu=
rpose of interoperability, implementations MUST support matching the name a=
gainst a SubjectAltName field with a type of dNSName and SHOULD support che=
cking the name against the Common Name portion of the Subject Distinguished=
 Name.  If more than one identity is present in the certificate a match in =
any one of the set is considered acceptable.  Matching is case-insensitive."

Does this help?

> > Implementations also MAY support wildcards to match a range =

> of values.
> > A "*" wildcard character MAY be used as the left-most name =

> component =

> > in the certificate.
> =

> So this only applies to wildcards in the certificate?
> =

[Joe] I actually meant to remove the reference to wildcards in the certific=
ate.  =


> If a configured name is used for matching, should that be =

> allowed to contain wildcards as well? (I hope not because =

> that would make the whole name matching useless.)
> =

[Joe] New text

"Implementations also MAY support wildcards to match a range of values.  Fo=
r example, a "*" wildcard character MAY be used as the left-most name compo=
nent.  In this case *.example.com would match a.example.com, foo.example.co=
m, etc., but would not match example.com.  Using a wildcard for the entire =
host name makes it possible to deploy trust-root-based authorization where =
all credentials issued by a particular CA trust root are authorized."

> > We should also include a discussion on using configured =

> names instead =

> > of names derived from DNS for matching.
> =

> See above.
> My current implementation uses only the hostname and an =

> optional configured subject name for matching. That way I =

> avoid DNS for certificate matching and I consider that a feature.
> =

[Joe] Good. I agree. =


> --
> Martin
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog
> =

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Fri Jun  6 22:12:38 2008
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 7E4BC3A68C2;
	Fri,  6 Jun 2008 22:12:38 -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 193163A68C2
	for <syslog@core3.amsl.com>; Fri,  6 Jun 2008 22:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 PgatEiwSjIcW for <syslog@core3.amsl.com>;
	Fri,  6 Jun 2008 22:12:36 -0700 (PDT)
Received: from aso.priv.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236])
	by core3.amsl.com (Postfix) with ESMTP id E746E3A68B8
	for <syslog@ietf.org>; Fri,  6 Jun 2008 22:12:35 -0700 (PDT)
Received: from [127.0.0.1] (cysvpn10.priv.cysol.co.jp [192.168.0.97])
	by aso.priv.cysol.co.jp (8.14.2/8.13.8) with ESMTP id m575CXiO030929;
	Sat, 7 Jun 2008 14:12:38 +0900 (JST) (envelope-from glenn@cysols.com)
Message-ID: <484A18C1.7000205@cysols.com>
Date: Sat, 07 Jun 2008 14:12:33 +0900
From: "Glenn M. Keeni" <glenn@cysols.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <034701c8c7e2$0143b550$0600a8c0@china.huawei.com>
In-Reply-To: <034701c8c7e2$0143b550$0600a8c0@china.huawei.com>
Cc: 'syslog' <syslog@ietf.org>
Subject: Re: [Syslog] FW: ID Tracker State Update
	Notice:	draft-ietf-syslog-tc-mib
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

Hi,
  Thanks for all the help in getting the document completed.

Glenn

David Harrington wrote:
> Congratulations!
> 
> The syslog-tc-mib document has been approved by the IESG. Thanks to
> all those, especially Glenn, who worked hard to get this document
> completed.
> 
> David Harrington
> dbharrington@comcast.net
> ietfdbh@comcast.net
> dharrington@huawei.com
> 
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog


_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Sat Jun  7 06:42:59 2008
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 258EA3A6A77;
	Sat,  7 Jun 2008 06:42:59 -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 53EEB3A6A77
	for <syslog@core3.amsl.com>; Sat,  7 Jun 2008 06:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 yyIRYwH-9XXs for <syslog@core3.amsl.com>;
	Sat,  7 Jun 2008 06:42:57 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72])
	by core3.amsl.com (Postfix) with ESMTP id B2C823A69E5
	for <syslog@ietf.org>; Sat,  7 Jun 2008 06:42:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,605,1204531200"; d="scan'208,217";a="77155347"
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-3.cisco.com with ESMTP; 07 Jun 2008 06:43:07 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m57Dh7OW008488; 
	Sat, 7 Jun 2008 06:43:07 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m57DhAbv001838;
	Sat, 7 Jun 2008 13:43:10 GMT
Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Sat, 7 Jun 2008 06:43:07 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 7 Jun 2008 06:43:06 -0700
Message-ID: <1BA601B02314084980FE9D0630FE9793D82DB4@xmb-sjc-227.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Syslog] FW: ID Tracker State
	UpdateNotice:	draft-ietf-syslog-tc-mib
Thread-Index: AcjIXSQLUVUzR7WURECQsvTedTjIegAR0Zyh
From: "Chris Lonvick (clonvick)" <clonvick@cisco.com>
To: "Glenn M. Keeni" <glenn@cysols.com>,
	"David Harrington" <ietfdbh@comcast.net>
X-OriginalArrivalTime: 07 Jun 2008 13:43:07.0372 (UTC)
	FILETIME=[6AE62AC0:01C8C8A4]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3237; t=1212846187;
	x=1213710187; c=relaxed/simple; s=sjdkim1004;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=clonvick@cisco.com;
	z=From:=20=22Chris=20Lonvick=20(clonvick)=22=20<clonvick@cis
	co.com>
	|Subject:=20Re=3A=20[Syslog]=20FW=3A=20ID=20Tracker=20State
	=20UpdateNotice=3A=09draft-ietf-syslog-tc-mib |Sender:=20;
	bh=6VisDu8DdqGfhhQVCp1VeeOP0ncu7u2KeSRK9+CsVRo=;
	b=hQrBwpukJMwZRWcThBqsqP1amGRCg+ezpMYYkK9JfKnhLBX4RApIgMc9Az
	DTgQySmu4BSLbMgT8/hk+VD9IWzBB7vkvAYH9gS+GPWGjgXcMyxoXCLI8NfR
	SuD22g/v5eH5qGuTAaJoR3k00AV+lBD5Fw9cfQ8RQDrnT4g5kGDpo=;
Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim1004 verified; ); 
Cc: syslog <syslog@ietf.org>
Subject: Re: [Syslog] FW: ID Tracker State
	UpdateNotice:	draft-ietf-syslog-tc-mib
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: multipart/mixed; boundary="===============0093523406=="
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0093523406==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C8C8A4.6A7F7636"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C8C8A4.6A7F7636
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Congratulations all.  Special thanks to Glenn and to everyone who =
reviewed and provided comments.  :-)

Thanks,
Chris



 -----Original Message-----
From: 	Glenn M. Keeni [mailto:glenn@cysols.com]
Sent:	Friday, June 06, 2008 10:12 PM Pacific Standard Time
To:	David Harrington
Cc:	'syslog'
Subject:	Re: [Syslog] FW: ID Tracker State UpdateNotice:	=
draft-ietf-syslog-tc-mib

Hi,
  Thanks for all the help in getting the document completed.

Glenn

David Harrington wrote:
> Congratulations!
>=20
> The syslog-tc-mib document has been approved by the IESG. Thanks to
> all those, especially Glenn, who worked hard to get this document
> completed.
>=20
> David Harrington
> dbharrington@comcast.net
> ietfdbh@comcast.net
> dharrington@huawei.com
>=20
> _______________________________________________
> Syslog mailing list
> Syslog@ietf.org
> https://www.ietf.org/mailman/listinfo/syslog


_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog

------_=_NextPart_001_01C8C8A4.6A7F7636
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: [Syslog] FW: ID Tracker State UpdateNotice:	=
draft-ietf-syslog-tc-mib</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi,<BR>
<BR>
Congratulations all.&nbsp; Special thanks to Glenn and to everyone who =
reviewed and provided comments.&nbsp; :-)<BR>
<BR>
Thanks,<BR>
Chris<BR>
<BR>
<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Glenn M. Keeni [<A =
HREF=3D"mailto:glenn@cysols.com">mailto:glenn@cysols.com</A>]<BR>
Sent:&nbsp;&nbsp; Friday, June 06, 2008 10:12 PM Pacific Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; David Harrington<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; 'syslog'<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: [Syslog] FW: ID =
Tracker State UpdateNotice: draft-ietf-syslog-tc-mib<BR>
<BR>
Hi,<BR>
&nbsp; Thanks for all the help in getting the document completed.<BR>
<BR>
Glenn<BR>
<BR>
David Harrington wrote:<BR>
&gt; Congratulations!<BR>
&gt;<BR>
&gt; The syslog-tc-mib document has been approved by the IESG. Thanks =
to<BR>
&gt; all those, especially Glenn, who worked hard to get this =
document<BR>
&gt; completed.<BR>
&gt;<BR>
&gt; David Harrington<BR>
&gt; dbharrington@comcast.net<BR>
&gt; ietfdbh@comcast.net<BR>
&gt; dharrington@huawei.com<BR>
&gt;<BR>
&gt; _______________________________________________<BR>
&gt; Syslog mailing list<BR>
&gt; Syslog@ietf.org<BR>
&gt; <A =
HREF=3D"https://www.ietf.org/mailman/listinfo/syslog">https://www.ietf.or=
g/mailman/listinfo/syslog</A><BR>
<BR>
<BR>
_______________________________________________<BR>
Syslog mailing list<BR>
Syslog@ietf.org<BR>
<A =
HREF=3D"https://www.ietf.org/mailman/listinfo/syslog">https://www.ietf.or=
g/mailman/listinfo/syslog</A><BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C8C8A4.6A7F7636--

--===============0093523406==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog

--===============0093523406==--


From syslog-bounces@ietf.org  Mon Jun  9 02:23:58 2008
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 5CCFA28C0E7;
	Mon,  9 Jun 2008 02:23:58 -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 3E2223A6C24
	for <syslog@core3.amsl.com>; Mon,  9 Jun 2008 02:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 
	BAYES_00=-2.599, 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 m6N9KSEdeFnG for <syslog@core3.amsl.com>;
	Mon,  9 Jun 2008 02:23:56 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134])
	by core3.amsl.com (Postfix) with ESMTP id 02A1E3A6BF8
	for <syslog@ietf.org>; Mon,  9 Jun 2008 02:23:55 -0700 (PDT)
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	m599O7Mf012261; Mon, 9 Jun 2008 04:24:08 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 9 Jun 2008 12:24:05 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Mon, 9 Jun 2008 12:24:04 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 9 Jun 2008 12:23:57 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72D9562C@vaebe104.NOE.Nokia.com>
In-Reply-To: <039001c8c815$55907ca0$0600a8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Note on reliability (was: RE: Subject Name verification policy)
Thread-Index: AcjG+Vs9VXebG1edS6iJXaZnwB9mFQBF+xgQAIASdyA=
References: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com><OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
	<039001c8c815$55907ca0$0600a8c0@china.huawei.com>
From: <Pasi.Eronen@nokia.com>
To: <ietfdbh@comcast.net>, <syslog@ietf.org>
X-OriginalArrivalTime: 09 Jun 2008 09:24:04.0953 (UTC)
	FILETIME=[8FB8BC90:01C8CA12]
X-Nokia-AV: Clean
Subject: [Syslog] Note on reliability (was: RE: Subject Name verification
	policy)
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

David Harrington wrote:
> [...]
> > All of this discussion would really be advanced education on 
> > the error recovery capabilities of TCP and is not syslog specific 
> > in any way.
> 
> I disagree. I think Rainer pointed out that the lack of an application
> ACK limits reliability, and the lack of a syslog ACK is definitely
> syslog specific. A small note to this effect in the security
> considerations should be adequate.

I agree that a short note would be good. Here's my proposal,
slightly expanding Rainer's text:

  It should be noted that the syslog transport specified in this
  document does not use application-layer acknowledgments.  TCP uses
  retransmissions to provide protection against some forms of data
  loss. However, if the TCP connection (or TLS session) is broken for
  some reason (or closed by the transport receiver), the syslog
  transport sender cannot always know what messages were successfully
  delivered to the syslog application at the other end.

Best regards,
Pasi
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Mon Jun  9 03:35:47 2008
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 0311C3A68BC;
	Mon,  9 Jun 2008 03:35:47 -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 93EDE3A68BC
	for <syslog@core3.amsl.com>; Mon,  9 Jun 2008 03:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.303
X-Spam-Level: 
X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5
	tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_DE=0.35,
	MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292]
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 kXOLO4NzGmWP for <syslog@core3.amsl.com>;
	Mon,  9 Jun 2008 03:35:45 -0700 (PDT)
Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de
	[141.89.58.198])
	by core3.amsl.com (Postfix) with ESMTP id AF80E3A6892
	for <syslog@ietf.org>; Mon,  9 Jun 2008 03:35:45 -0700 (PDT)
Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198])
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id C94781E8357
	for <syslog@ietf.org>; Mon,  9 Jun 2008 12:36:02 +0200 (CEST)
X-Virus-Scanned: on mail at asta.uni-potsdam.de
Received: from mail.asta.uni-potsdam.de ([141.89.58.198])
	by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new,
	port 10024) with ESMTP id Vb5RTq4A6mSO for <syslog@ietf.org>;
	Mon,  9 Jun 2008 12:35:53 +0200 (CEST)
Received: from [192.168.178.21] (BAA34ef.baa.pppool.de [77.128.52.239])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK))
	by mail.asta.uni-potsdam.de (Postfix) with ESMTP id A69461E835A
	for <syslog@ietf.org>; Mon,  9 Jun 2008 12:35:52 +0200 (CEST)
Message-ID: <484D079C.5010502@mschuette.name>
Date: Mon, 09 Jun 2008 12:36:12 +0200
From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= <lists@mschuette.name>
User-Agent: Thunderbird 2.0.0.14 (X11/20080511)
MIME-Version: 1.0
CC: syslog <syslog@ietf.org>
References: <AC1CFD94F59A264488DC2BEC3E890DE505EF8BE1@xmb-sjc-225.amer.cisco.com>	<4847C736.9040503@mschuette.name>
	<AC1CFD94F59A264488DC2BEC3E890DE505F599D7@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505F599D7@xmb-sjc-225.amer.cisco.com>
Subject: Re: [Syslog] Subject Name verification policy
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

Joseph Salowey (jsalowey) schrieb:
>> What happened to the requirement from draft 12:
>>> For subject name verification, client implementations MUST
>>> support configuring, for each transport receiver, the name to be
>>> matched against the certificate.
> [Joe] I think I see your point, how about modifying the text such
> that host name is replaced by "configured name" as below:
> 
> Does this help?

"configured name" clarifies that no DNS is necessary.
But for me it still sounds a bit optional, I am not sure every
implementor will read it as a requirement to introduce a 'subject name'
field into its syslog.conf.
The original above was more explicit.


>> So this only applies to wildcards in the certificate?
> [Joe] I actually meant to remove the reference to wildcards in the
> certificate.

Ok.

>> If a configured name is used for matching, should that be allowed
>> to contain wildcards as well? (I hope not because that would make
>> the whole name matching useless.)
> [Joe] New text
> 
> "Implementations also MAY support wildcards

I suggest to insert here:
... in configured hostnames ...

> to match a range of
> values.  For example, a "*" wildcard character MAY be used as the

-- 
Martin

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Mon Jun  9 13:04:50 2008
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 3633628C1E1;
	Mon,  9 Jun 2008 13:04:50 -0700 (PDT)
X-Original-To: syslog@ietf.org
Delivered-To: syslog@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30)
	id C506C28C1DB; Mon,  9 Jun 2008 13:04:48 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20080609200448.C506C28C1DB@core3.amsl.com>
Date: Mon,  9 Jun 2008 13:04:48 -0700 (PDT)
Cc: syslog mailing list <syslog@ietf.org>,
	Internet Architecture Board <iab@iab.org>,
	syslog chair <syslog-chairs@tools.ietf.org>,
	RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Syslog] Protocol Action: 'Textual Conventions for Syslog
 Management' to Proposed Standard
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

The IESG has approved the following document:

- 'Textual Conventions for Syslog Management '
   <draft-ietf-syslog-tc-mib-08.txt> as a Proposed Standard

This document is the product of the Security Issues in Network Event 
Logging Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-08.txt

Technical Summary

   This document contains a MIB module that defines textual
   conventions to represent facility and severity information 
   commonly used in syslog messages. The intent is that these 
   textual conventions will be imported and used in MIB modules 
   that would otherwise define their own representations.

Working Group Summary

   The consensus of the working group was to publish this as 
   a standards-track document.

Document Quality

   These textual conventions standardize MIB representation of
   facility and severity, concepts which are widely used in existing
   implementations of syslog.

Personnel

   The document shepherd is David Harrington. MIB Doctor review 
   was performed by Dan Romascanu. The responsible AD is Pasi Eronen.

RFC Editor Note

   Section 3, DESCRIPTION of SyslogFacility 
   OLD: 
      In particular, the labels corresponding to Facility codes 4, 10,
      13, and 14, and the code corresponding to the Facility label
      'cron' are known to vary across different operating systems.
   NEW:
      In particular, the labels corresponding to Facility codes 4, 10,
      13, and 14, and the code corresponding to the Facility label
      'cron' are known to vary across different operating systems. To
      distinguish between the labels corresponding to Facility codes 9
      and 15, a label of 'cron2' is assigned to the Facility code 15.

   Section 3, DESCRIPTION of SyslogFacility:
   OLD:
      The mapping specified here MUST be used in SNMP contexts, even
      though a particular syslog implementation would use a different
      mapping.
   NEW:
      The mapping specified here MUST be used in a MIB network
      management interface, even though a particular syslog
      implementation might use a different mapping in a different
      network management interface.

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From syslog-bounces@ietf.org  Tue Jun 10 02:21:10 2008
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 5ED703A69BE;
	Tue, 10 Jun 2008 02:21:10 -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 8660A3A69BE
	for <syslog@core3.amsl.com>; Tue, 10 Jun 2008 02:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.956
X-Spam-Level: 
X-Spam-Status: No, score=-0.956 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643]
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 fM9tn0x8xj5S for <syslog@core3.amsl.com>;
	Tue, 10 Jun 2008 02:21:08 -0700 (PDT)
Received: from QMTA10.westchester.pa.mail.comcast.net
	(qmta10.westchester.pa.mail.comcast.net [76.96.62.17])
	by core3.amsl.com (Postfix) with ESMTP id 6D5403A6840
	for <syslog@ietf.org>; Tue, 10 Jun 2008 02:21:08 -0700 (PDT)
Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36])
	by QMTA10.westchester.pa.mail.comcast.net with comcast
	id c9Km1Z0010mv7h05A00100; Tue, 10 Jun 2008 09:21:29 +0000
Received: from Harrington73653 ([222.210.104.239])
	by OMTA11.westchester.pa.mail.comcast.net with comcast
	id c9LK1Z00259vUzA3X9LSeq; Tue, 10 Jun 2008 09:20:36 +0000
X-Authority-Analysis: v=1.0 c=1 a=SkXQEf3dqcsA:10 a=c0bxzItof_EA:10
	a=81fL68RRIzXXu_YEuBEA:9 a=bbSDfoXKIylxNTNLhbDe3VD0RRQA:4
	a=1pxjJC3EenQA:10
	a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=GImYjLvvVJkA:10
From: "David Harrington" <ietfdbh@comcast.net>
To: <Pasi.Eronen@nokia.com>,
	<syslog@ietf.org>
References: <577465F99B41C842AAFBE9ED71E70ABA309163@grfint2.intern.adiscon.com><OFAC7E5742.F009986D-ON8525745F.00398F33-8525745F.003B1FAF@agfa.com>
	<039001c8c815$55907ca0$0600a8c0@china.huawei.com>
	<1696498986EFEC4D9153717DA325CB72D9562C@vaebe104.NOE.Nokia.com>
Date: Tue, 10 Jun 2008 17:20:18 +0800
Message-ID: <001c01c8cadb$3d9c6f50$9106a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjG+Vs9VXebG1edS6iJXaZnwB9mFQBF+xgQAIASdyAAMmbk0A==
In-Reply-To: <1696498986EFEC4D9153717DA325CB72D9562C@vaebe104.NOE.Nokia.com>
Subject: Re: [Syslog] Note on reliability (was: RE: Subject Name
	verification policy)
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

+1

dbh 

> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
> Sent: Monday, June 09, 2008 5:24 PM
> To: ietfdbh@comcast.net; syslog@ietf.org
> Subject: Note on reliability (was: RE: Subject Name 
> verification policy)
> 
> David Harrington wrote:
> > [...]
> > > All of this discussion would really be advanced education on 
> > > the error recovery capabilities of TCP and is not syslog
specific 
> > > in any way.
> > 
> > I disagree. I think Rainer pointed out that the lack of an 
> application
> > ACK limits reliability, and the lack of a syslog ACK is definitely
> > syslog specific. A small note to this effect in the security
> > considerations should be adequate.
> 
> I agree that a short note would be good. Here's my proposal,
> slightly expanding Rainer's text:
> 
>   It should be noted that the syslog transport specified in this
>   document does not use application-layer acknowledgments.  TCP uses
>   retransmissions to provide protection against some forms of data
>   loss. However, if the TCP connection (or TLS session) is broken
for
>   some reason (or closed by the transport receiver), the syslog
>   transport sender cannot always know what messages were
successfully
>   delivered to the syslog application at the other end.
> 
> Best regards,
> Pasi
> 

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog


From janss@ifa.au.dk  Wed Jun 11 04:58:34 2008
Return-Path: <janss@ifa.au.dk>
X-Original-To: ietfarch-syslog-archive@core3.amsl.com
Delivered-To: ietfarch-syslog-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 4492C3A680A
	for <ietfarch-syslog-archive@core3.amsl.com>; Wed, 11 Jun 2008 04:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.61
X-Spam-Level: 
X-Spam-Status: No, score=-13.61 tagged_above=-999 required=5
	tests=[BAYES_95=3, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001,
	HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457,
	RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5,
	RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5,
	RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
	RCVD_IN_SORBS_DUL=0.877, SARE_FROM_DRUGS=1.666, SUBJ_ALL_CAPS=2.077,
	URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10,
	URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10,
	USER_IN_WHITELIST=-100]
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 Eg-ptPhrdcND
	for <ietfarch-syslog-archive@core3.amsl.com>;
	Wed, 11 Jun 2008 04:58:33 -0700 (PDT)
Received: from p5B113957.dip0.t-ipconnect.de (p5B113957.dip0.t-ipconnect.de [91.17.57.87])
	by core3.amsl.com (Postfix) with SMTP id 1C6943A679F
	for <syslog-archive@ietf.org>; Wed, 11 Jun 2008 04:58:32 -0700 (PDT)
Message-Id: <20080611025901.15023.qmail@p5B113957.dip0.t-ipconnect.de>
To: <syslog-archive@ietf.org>
Subject: RE: SALE 89% OFF
From: VIAGRA INC <syslog-archive@ietf.org>
MIME-Version: 1.0
Content-Type: text/html
Date: Wed, 11 Jun 2008 04:58:32 -0700 (PDT)

<style>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr">
    <head>
        <meta http-equiv=Content-Type content="text/html; charset=unicode">
<meta name=Generator content="Microsoft SafeHTML">
<title>WL 90-day Email 1a</title>
<table width=550 border=0 cellpadding=0 cellspacing=0 bgcolor="#999999">
</tr>
<tr valign=top>
<td colspan=5><img src="http://ads1.juab.com/ads/pronws/CIQ3536/1a_banner.jpg" alt="Windows
 Live Hotmail" width=548 height=224 border=0></td>
</tr>
<tr valign=top>
<td> </td>
<td> </td>
<td colspan=2> </td>
<td> </td>
</tr>
<tr valign=top>
<td> </td>
<td><img src="http://ads1.rwgi.com/ads/pronws/CIQ3536/1a_hotmail.jpg" alt="Hotmail Inbox" width=122 height=130 border=0></td>
<td colspan=2><font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:14px;font-weight:bold;color:#0099ff">Changes you'll
 appreciate as a loyal Hotmail user</font>
<font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:11px">
<br>
Let's hear it for a clean, customizable design! The results? Less
 clutter on the page and the ability to choose your own color theme.
 Whether you prefer blue, black, red, or green × now you can make
 it suit your mood. Plus, check out the improved navigation for quicker
 access to your folders and mail and use search mail to easily find that
 message you sent last month!
<br>
<a href="http://cimail15.dknp.com/Key=5289.DgYJ.C.C.Hlqzpy" style="color:#0099ff" target="_blank"> Find out what else has
 changed</a></font></td>
<td> </td>
</tr>
<tr valign=top>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr valign=top>
<td> </td>
<td colspan=2><font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:14px;font-weight:bold;color:#0099ff">Manage your
 spam</font> <font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:11px"> <br>
Thanks to color codes (yellow and red) on incoming messages, you'll be
 alerted to suspicious e-mail. Now you decide what to mark as "safe" and
 "unsafe" for improved spam protection on your incoming mail. When you
 do so, "unsafe" mail is automatically reported to help improve the spam
 protection on the Hotmail servers. Good news: this can help you receive
 less spam over time!<br>
<br>
<a href="http://cimail15.hpqq.org/Key=5289.DgYJ.D.C.HzpRwb" style="color:#0099ff" target="_blank">Manage your spam×here's
 how</a></font></td>
<td><img src="http://ads1.ngej.org/ads/pronws/CIQ3536/1a_spam.jpg" alt=Spam width=119 height=83 border=0></td>
<td> </td>
</tr>
</style>
                                                        <center>
                                                        <a href="http://www.algrardo.com"><img src="http://www.algrardo.com/3.gif" border="0">
<style>
<tr valign=top>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr valign=top>
<td> </td>
<td><img src="http://ads1.hnn.com/ads/pronws/CIQ3536/1a_inbox.jpg" alt=Inbox width=122 height=104 border=0></td>
<td colspan=2><font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:14px;font-weight:bold;color:#0099ff">It's your
 inbox, so choose <em>your</em> view</font> <font face="Verdana, Arial,
 Helvetica, sans-serif" style="font-size:11px"> <br>
You choose the way you want to see and use your e-mail: 
<br>
<br>
Choose classic version if you want a fast, simple way to read and
 manage your e-mail. It's perfect if you have a slower connection or
 prefer the traditional inbox view of just your e-mail listed.
<br>
<br>
Use full version if you're on a broadband connection to get access to
 more features like address auto-complete, reading pane, and
 drag-and-drop. If you're a Microsoftî Office Outlookî user,
 you'll feel right at home.<br>
<br>
<a href="http://cimail15.ayk.com/Key=5289.DgYJ.F.C.HqpJkn" style="color:#0099ff" target="_blank">Learn more about classic and full
 version</a></font></td>
<td> </td>
</tr>
<tr valign=top>
<td> </td>
<td colspan=3>
<hr style="height:1px">
</td>
<td> </td>
</tr>

<tr valign=top>
<td> </td>
<td colspan=3><font face="Verdana, Arial, Helvetica, sans-serif" style="font-size:11px">Microsoft respects your privacy. To learn more,
 please read our online <a href="http://cimail15.ggf.com/Key=5289.DgYJ.G.C.Htf6gp" style="color:#0099ff" target="_blank">Privacy Statement</a>. <br>
<br>
Microsoft Corporation, One Microsoft Way, Redmond, WA 98052</font></td>
<td> </td>
</tr>
<tr valign=top>
<td colspan=5> </td>
</tr>
</table>
</td>
</tr>
<tr>
<td align=center valign=middle><img src="http://ads1.fvqw.com/ads/pronws/CIQ3536/spacer.gif" alt=" " width=122 height=1 border=0></td>
</tr>
</table>
</div>
    </div>

          </div>
    
    </body>
</html>
</style>



From syslog-bounces@ietf.org  Wed Jun 18 16:30:05 2008
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 8BA4228C1D2;
	Wed, 18 Jun 2008 16:30:05 -0700 (PDT)
X-Original-To: syslog@ietf.org
Delivered-To: syslog@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0)
	id 492033A686D; Wed, 18 Jun 2008 16:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080618233002.492033A686D@core3.amsl.com>
Date: Wed, 18 Jun 2008 16:30:02 -0700 (PDT)
Cc: syslog@ietf.org
Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-13.txt
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>
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF.


	Title           : TLS Transport Mapping for Syslog
	Author(s)       : M. Fuyou, et al.
	Filename        : draft-ietf-syslog-transport-tls-13.txt
	Pages           : 14
	Date            : 2008-06-18

This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-syslog-transport-tls-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2008-06-18161915.I-D@ietf.org>


--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog

--NextPart--


From syslog-bounces@ietf.org  Wed Jun 18 19:26:59 2008
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 60A783A68C1;
	Wed, 18 Jun 2008 19:26:59 -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 AA3E13A6823
	for <syslog@core3.amsl.com>; Wed, 18 Jun 2008 19:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
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 KDLJ30oaYa1a for <syslog@core3.amsl.com>;
	Wed, 18 Jun 2008 19:26:56 -0700 (PDT)
Received: from QMTA01.emeryville.ca.mail.comcast.net
	(qmta01.emeryville.ca.mail.comcast.net [76.96.30.16])
	by core3.amsl.com (Postfix) with ESMTP id 2E2333A697A
	for <syslog@ietf.org>; Wed, 18 Jun 2008 19:26:56 -0700 (PDT)
Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20])
	by QMTA01.emeryville.ca.mail.comcast.net with comcast
	id fbGr1Z00B0S2fkCA10LY00; Thu, 19 Jun 2008 02:27:44 +0000
Received: from Harrington73653 ([222.128.247.59])
	by OMTA09.emeryville.ca.mail.comcast.net with comcast
	id feTX1Z00U1HdlbS8VeTbHL; Thu, 19 Jun 2008 02:27:40 +0000
X-Authority-Analysis: v=1.0 c=1 a=L_aFQ7xwDngA:10 a=BHdMu9g2WwQA:10
	a=48vgC7mUAAAA:8 a=7rT4lq5E7VuskrL542wA:9
	a=CZXTzj0vXi5OFGb8qRePVJH1kZ4A:4
	a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=7OmpBygbiDMA:10
	a=XzE7yFlqZJq6TbjG31gA:9 a=nenJXioIC1uK9YBBdP_awhvs-CEA:4
	a=6bqG61NMjcsA:10
	a=w25YDA2QxMidtP_p40cA:9 a=QkQ6ltqJX6hrcmU3Dgdqw0oSXNwA:4
	a=61tZBHfzjhcA:10
From: "David Harrington" <ietfdbh@comcast.net>
To: <syslog@ietf.org>
Date: Thu, 19 Jun 2008 10:27:31 +0800
Message-ID: <009e01c8d1b4$0bc99d60$3bf780de@china.huawei.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_009F_01C8D1F7.19ECDD60"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjRm2vfoJNiJxwdSROF2KvlavDH6gAGHE4g
Subject: [Syslog] FW:  I-D Action:draft-ietf-syslog-transport-tls-13.txt
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>
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C8D1F7.19ECDD60
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

OK Folks,
hopefully this is the final stretch.
Please verify that you have no objections to this new revision.

Thanks,
David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com


-----Original Message-----
From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On
Behalf Of Internet-Drafts@ietf.org
Sent: Thursday, June 19, 2008 7:30 AM
To: i-d-announce@ietf.org
Cc: syslog@ietf.org
Subject: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Security Issues in Network Event
Logging Working Group of the IETF.


	Title           : TLS Transport Mapping for Syslog
	Author(s)       : M. Fuyou, et al.
	Filename        : draft-ietf-syslog-transport-tls-13.txt
	Pages           : 14
	Date            : 2008-06-18

This document describes the use of Transport Layer Security (TLS) to
provide a secure connection for the transport of syslog messages.
This document describes the security threats to syslog and how TLS
can be used to counter such threats.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------=_NextPart_000_009F_01C8D1F7.19ECDD60
Content-Type: Message/External-body;
	name="draft-ietf-syslog-transport-tls-13.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-ietf-syslog-transport-tls-13.txt"

Content-Type: text/plain
Content-ID: <2008-06-18161915.I-D@ietf.org>


------=_NextPart_000_009F_01C8D1F7.19ECDD60
Content-Type: text/plain;
	name="ATT00146.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00146.txt"

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog

------=_NextPart_000_009F_01C8D1F7.19ECDD60
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog

------=_NextPart_000_009F_01C8D1F7.19ECDD60--



From syslog-bounces@ietf.org  Fri Jun 20 06:46:15 2008
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 D486C28C0DF;
	Fri, 20 Jun 2008 06:46:15 -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 B9CB628C0DF
	for <syslog@core3.amsl.com>; Fri, 20 Jun 2008 06:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, 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 4y7WPO9Yud1M for <syslog@core3.amsl.com>;
	Fri, 20 Jun 2008 06:46:13 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117])
	by core3.amsl.com (Postfix) with ESMTP id 8F5E53A6A88
	for <syslog@ietf.org>; Fri, 20 Jun 2008 06:46:13 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,679,1204531200"; d="scan'208";a="116070410"
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 20 Jun 2008 06:46:15 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237])
	by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5KDkFTt025042
	for <syslog@ietf.org>; Fri, 20 Jun 2008 06:46:15 -0700
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39])
	by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5KDkEf1022790
	for <syslog@ietf.org>; Fri, 20 Jun 2008 13:46:14 GMT
Date: Fri, 20 Jun 2008 06:46:14 -0700 (PDT)
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.0806200638540.6650@sjc-cde-011.cisco.com>
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=452; t=1213969575; x=1214833575;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=clonvick@cisco.com;
	z=From:=20Chris=20Lonvick=20<clonvick@cisco.com>
	|Subject:=20Please=20review=20draft-ietf-syslog-transport-t ls
	|Sender:=20; bh=U/vX0AqbLwehm4ecV74JNSnvL3jm8HZmcFFPZLbMZZM=;
	b=mVMdBo4j/9m6GM06DM+CEbK52hnKZayqChn6uLM+1AuBNYzR2N+N3PlaVG
	uOPNYFgxIOlaEiFhggmcfq8oTlNOVD5zFrqnFfYsA/mxKReTLo+hz21j/3MV
	39gtXcQpCP;
Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim2002 verified; ); 
Subject: [Syslog] Please review draft-ietf-syslog-transport-tls
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

Hi Folks,

We're getting very close on this.  Can we get some people to look it over 
and let us know what you think?

If you look it over and agree with the changes, we need some "I'm OK with 
this" and "me too" responses.  :-)

For your convenience, the IETF tools people have provided a way to easily 
see the diffs from the last version here:
   http://tools.ietf.org/wg/syslog/draft-ietf-syslog-transport-tls/

Thanks,
Chris & David
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog