From wwwrun@core3.amsl.com Tue Sep 1 07:46:56 2009 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CF86F28C74C; Tue, 1 Sep 2009 07:46:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090901144656.CF86F28C74C@core3.amsl.com> Date: Tue, 1 Sep 2009 07:46:56 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-sign (Signed syslog Messages) to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 14:46:56 -0000 The IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Signed syslog Messages ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-27.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6411&rfc_flag=0 From clonvick@cisco.com Tue Sep 1 08:05:37 2009 Return-Path: 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 BD9DC28C79F for ; Tue, 1 Sep 2009 08:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 T67mIVRYDRQD for ; Tue, 1 Sep 2009 08:05:36 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D00D528C81B for ; Tue, 1 Sep 2009 08:04:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAInUnEqrR7PD/2dsb2JhbADFDIhBAZAABYQb X-IronPort-AV: E=Sophos;i="4.44,312,1249257600"; d="scan'208";a="41903699" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 01 Sep 2009 15:01:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n81F1CuN008525 for ; Tue, 1 Sep 2009 08:01:12 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n81F1Cjq010182 for ; Tue, 1 Sep 2009 15:01:12 GMT Date: Tue, 1 Sep 2009 08:01:12 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1434; t=1251817272; x=1252681272; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20[Syslog]=20Last=20Call=3A=20draft-ietf-syslog-s ign=20(Signed=20syslog=20Messages)=0A=20to=20Proposed=20Stan dard=20(fwd) |Sender:=20; bh=vWGU+LyCREJosoUKAx2D5ehD3o7Tq9oZ7gLjZMG83W4=; b=hGCL3QyDiFuh86LlTa4uvHa4d42DqvZ4U/b7Q1tTARNMRUoxbQC9rKgHQn 03UdTqs/nux8MgoijPNcLgYK0GM0uCH9J4xLJK2ciAY2yYn/ppSj0ONurjnu yr/vqhqFaC; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Syslog] Last Call: draft-ietf-syslog-sign (Signed syslog Messages) to Proposed Standard (fwd) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 15:05:37 -0000 Hi Folks, Here's the latest draft and we're now officially into IETF Last Call on syslog-sign. Please review and send comments to ietf@ietf.org. Many thanks, Chris ---------- Forwarded message ---------- Date: Tue, 1 Sep 2009 07:46:56 -0700 (PDT) From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-sign (Signed syslog Messages) to Proposed Standard The IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Signed syslog Messages ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-27.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=6411&rfc_flag=0 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Wed Sep 2 08:46:58 2009 Return-Path: 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 2C2EC28C12E for ; Wed, 2 Sep 2009 08:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, J_CHICKENPOX_82=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 dcAUn--EXb7r for ; Wed, 2 Sep 2009 08:46:57 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 669A428C62C for ; Wed, 2 Sep 2009 08:46:31 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id bmZy1c0020EZKEL53rl4tN; Wed, 02 Sep 2009 15:45:04 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id brly1c0030UQ6dC3Mrlyzk; Wed, 02 Sep 2009 15:45:58 +0000 From: "David Harrington" To: Date: Wed, 2 Sep 2009 11:45:57 -0400 Message-ID: <01bd01ca2be4$766b1eb0$0202fea9@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcorExf4XIOK1HKURmCWyn6oYTBtcQA0IHwA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] Last Call: draft-ietf-syslog-sign (Signed syslog Messages)to Proposed Standard X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 15:46:58 -0000 Hi, Chris just posted an email pointing out that we are in Last Call on syslog-sign. If you want to make comments, please follow the instructions in the Last Call announcement (below). Do NOT just send them to the syslog mailing list. The discussion now belongs on the IETF list. You have until September 15 to make comments there. dbh -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of The IESG Sent: Tuesday, September 01, 2009 10:47 AM To: IETF-Announce Cc: syslog@ietf.org Subject: [Syslog] Last Call: draft-ietf-syslog-sign (Signed syslog Messages)to Proposed Standard The IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Signed syslog Messages ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-09-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-27.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa g=6411&rfc_flag=0 _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From ietfdbh@comcast.net Wed Sep 9 11:15:36 2009 Return-Path: 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 6B27B28C237 for ; Wed, 9 Sep 2009 11:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_20=-0.74, SUBJ_ALL_CAPS=2.077] 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 tU9ZdrRg6pcE for ; Wed, 9 Sep 2009 11:15:35 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5FF423A6987 for ; Wed, 9 Sep 2009 11:15:35 -0700 (PDT) Received: from OMTA16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA06.westchester.pa.mail.comcast.net with comcast id egLX1c0061uE5Es56iG1eg; Wed, 09 Sep 2009 18:16:01 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA16.westchester.pa.mail.comcast.net with comcast id eiMd1c0060UQ6dC3ciMdUh; Wed, 09 Sep 2009 18:21:37 +0000 From: "David Harrington" To: Date: Wed, 9 Sep 2009 14:16:07 -0400 Message-ID: <010601ca3179$9a3ccc40$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcoxXoC8U4BDXJf/QD+jeudIxR/N6wAGvRQw Subject: [Syslog] NOMCOM 2009-2010 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 18:15:36 -0000 Hi, the NOMCOM Call for Nominations is still open and the NOMCOM would like to see more nominations. Please consider volunteering if you want to make a leadership contribution to the IETF. There details are here: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06510.ht ml David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From root@core3.amsl.com Tue Sep 15 10:45:01 2009 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 83C043A6A24; Tue, 15 Sep 2009 10:45:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090915174501.83C043A6A24@core3.amsl.com> Date: Tue, 15 Sep 2009 10:45:01 -0700 (PDT) Cc: syslog@ietf.org Subject: [Syslog] WG Action: RECHARTER: Security Issues in Network Event Logging (syslog) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 17:45:01 -0000 The Security Issues in Network Event Logging (syslog) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Security Issues in Network Event Logging (syslog) --------------------------------------------------- Current Status: Active Working Group Chairs: * Chris Lonvick (clonvick@cisco.com) * David Harrington (ietfdbh@comcast.net) Security Area Directors: * Tim Polk (tim.polk@nist.gov) * Pasi Eronen (pasi.eronen@nokia.com) Security Area Advisor: * Pasi Eronen (pasi.eronen@nokia.com) Mailing Lists: General Discussion: syslog@ietf.org To Subscribe: syslog-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/syslog Description of Working Group: Syslog has been a de-facto standard for logging system events for long time. The syslog WG recently completed standardization of the syslog protocol (RFC 5424), secure transport of the syslog protocol over TLS (RFC 5425), and non-secure transport over UDP (RFC 5426). The WG under this charter will standardize a DTLS transport for syslog, providing a secure transport for syslog messages in cases where a connection-less transport is desired. The threats that this WG will primarily address are modification, disclosure, and masquerade. A secondary threat is message stream modification. These are consistent with those addressed in RFC 5425. Draft-feng-syslog-transport-dtls is already similar to RFC 5425 in this respect, so this draft will become the starting point for the WG document, which the WG will adjust as needed, and merge desired features from other sources, such as draft-petch-gerhards-syslog-transport-dtls, draft-hardaker-isms-dtls-tm, and draft-seggelmann-tls-dtls-heartbeat. The WG will also complete the ongoing work to specify a standardized mechanism for signing syslog messages (draft-ietf-syslog-sign). Goals and Milestones: Oct 2009 Submit a document that defines a message signing and ordering mechanism to the IESG for consideration as a PROPOSED STANDARD Mar 2010 Submit Syslog DTLS Transport Mapping to the IESG for consideration as a PROPOSED STANDARD From ericko0@yahoo.com Thu Sep 17 23:33:40 2009 Return-Path: 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 728C93A6AB9 for ; Thu, 17 Sep 2009 23:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Q5HdJ4IEkonb for ; Thu, 17 Sep 2009 23:33:39 -0700 (PDT) Received: from web45508.mail.sp1.yahoo.com (web45508.mail.sp1.yahoo.com [68.180.197.116]) by core3.amsl.com (Postfix) with SMTP id F1F1B3A6A53 for ; Thu, 17 Sep 2009 23:33:38 -0700 (PDT) Received: (qmail 84565 invoked by uid 60001); 18 Sep 2009 06:34:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253255668; bh=YcdjeFFvA8iz2He0JXzPzkGNFtJ+Mffgfk4wEn0DLb8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RWC5dxByG6EjP4el8AExZLilTGwdERRIIMOtUMCmFP4Y2yr9yUKkTe7/GAT6fUV6DjwNvaqB/cR5ntIHKGnOIUENJOoJX+UDGzoAyazp0NomdW4rSCjm0dMgBmMpu9xstgSw/J/5PnXCq7bloIjzu/42Sl1537ilm3196kvP+2Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ubFNVE1NxdWAE+xETN66k9CZLDcLNwIRRY8qQmUrlqU60lbeZPjAW9I0IELuICZAltTIQgChY81DCavMSRgaRj8KB30XGLs9ezY2G7VxTMHzAh8e47vYEsmG216YRkkrxPv288SXJUs26kmkbx/6QkR2kLKPhw8yfBAkBuM0jic=; Message-ID: <587230.84105.qm@web45508.mail.sp1.yahoo.com> X-YMail-OSG: oHADBLAVM1mmsg3A.6UvOWC9G5G3A6jX4mRmLqxUHQgLW7_.b5nOvJ5xpOkYDH.rSrfs.ZiF9aA_28aZWMTnCmfgzDajixYNE5R7qqibTBoM6vy7OHPLM_ryHEEVJ5yojxFoMuNXh.7Ot0vdWI0zrmIATdQLKE7sK0.bUsdxrHv5XSCj46vEtrGmV37COuAMo3o.jFMazLTQRUHSyy..R8c54sqOcnnO0SXRP06WYHKQsGQiWl8- Received: from [68.106.217.192] by web45508.mail.sp1.yahoo.com via HTTP; Thu, 17 Sep 2009 23:34:27 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> Date: Thu, 17 Sep 2009 23:34:27 -0700 (PDT) From: Erick O To: "tom.petch" , Gerhard Muenz , syslog@ietf.org, ipfix@ietf.org, tls@ietf.org In-Reply-To: <000401ca111a$3bb01da0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1333662422-1253255667=:84105" X-Mailman-Approved-At: Fri, 18 Sep 2009 08:09:14 -0700 Cc: Michael Tuexen , Daniel Mentz Subject: Re: [Syslog] [TLS] Missing dead peer detection in DTLS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 06:33:40 -0000 --0-1333662422-1253255667=:84105 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: tom.petch =0ATo: Gerhard Muenz ; syslog@ietf.org; = ipfix@ietf.org; tls@ietf.org=0ACc: Michael Tuexen ; = Daniel Mentz =0ASent: Thursday, July 30, 2009 2:44:11 AM= =0ASubject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS=0A=0AGer= hard=0A=0AThank you for pointing this out; it had escaped me.=0A=0AWhat I h= ad thought though was that the lack of flow control with DTLS over UDP=0Ais= a problem, and that the lack of this with syslog over UDP led the syslog R= FC=0A[RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as m= ight be=0Aexpected, syslog over UDP.=0A=0AThis in turn led me to expect tha= t syslog over DTLS over UDP would not be=0Aacceptable to the IESG, rather t= hat syslog over DTLS over SCTP would become the=0ARECOMMENDED transport.=0A= =0ASo; several thoughts.=0A=0AThis is an update to the extensions RFC, RFC4= 366, which itself is being updated=0Aby the TLS working group (hence my add= ition of them to the list) and I would=0Amuch rather have one extensions RF= C rather than several.=A0 This is a good concept=0Aand fills a need; perhap= s the TLS working group would take this on.=0A=0AFlow control remains an is= sue which I do not think that this extension=0Aaddresses.=0A=0AIs this a se= curity exposure? or just, like syslog over UDP, an inconvenient=0Atruth?=0A= =0AThe petch-gerhards draft allows the recipient of the unidirectional flow= to=0Ainitiate the DTLS 'connection', and so enables it to re-establish the= connection=0Awhen anything goes wrong.=A0 This would seem an alternative t= o consider.=0A=0ATom Petch=0A=0A----- Original Message -----=0AFrom: "Gerha= rd Muenz" =0ATo: ; = =0ACc: "Michael Tuexen" ; "Robin Seggelmann"=0A; "Daniel Mentz" =0ASent: Tuesday, J= uly 28, 2009 10:41 AM=0ASubject: [Syslog] Missing dead peer detection in DT= LS=0A=0A=0AHi,=0A=0AThis mail goes to the ipfix and syslog mailing lists in= order to=0Asummarize the common issues regarding DTLS.=0A=0AIPFIX specifie= s support of DTLS as mandatory for transport over UDP and=0ASCTP in RFC5101= . In SYSLOG, it is intended to standardize DTLS for=0Atransport over UDP.= =0A=0AIn IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and = we=0Awill have a first implementation of IPFIX-over-DTLS/SCTP very soon.=0A= During this implementation effort, we found that the current=0Aspecificatio= n of DTLS/UDP has a severe flaw when used with=0Aunidirectional protocols (= like IPFIX): The sender cannot recognize if=0Athe receiver has crashed and = lost the DTLS state.=0A=0AWe discuss this issue in a draft:=0Ahttp://tools.= ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00=0Ahttp://www.ietf.o= rg/proceedings/75/slides/ipfix-6.pdf=0A=0AI've had a look at draft-feng-sys= log-transport-dtls-01 and=0Adraft-petch-gerhards-syslog-transport-dtls-02. = It seems that this=0Aproblem has not yet been covered, although the problem= should be the=0Asame for SYSLOG.=0A=0AAs a solution, the DTLS Heartbeat Ex= tension has been proposed very recently:=0Ahttp://tools.ietf.org/html/draft= -seggelmann-tls-dtls-heartbeat-00=0AA feature patch for OpenSSL is availabl= e:=0Ahttp://sctp.fh-muenster.de/dtls-patches.html#features=0A=0ASo, I think= that we should support this standardization initiative as it=0Asolves our = problem. For IPFIX and SYSLOG over DTLS/UDP, we then can=0Aspecify that the= DTLS Heartbeat Extension MUST be implemented.=0A=0ADan suggested to have a= single document solving the DTLS issues=0Aregarding unidirectional protoco= ls. I think that such a document is not=0Aneeded if we have DTLS Heartbeat = Extension.=0A=0ARegards,=0AGerhard=0A=0ADipl.-Ing. Gerhard M=FCnz=0AChair f= or Network Architectures and Services (I8)=0ADepartment of Informatics=0ATe= chnische Universit=E4t M=FCnchen=0ABoltzmannstr. 3, 85748 Garching bei M=FC= nchen, Germany=0APhone:=A0 +49 89 289-18008=A0 =A0 =A0 Fax: +49 89 289-1803= 3=0AE-mail: muenz@net.in.tum.de=A0 =A0 WWW: http://www.net.in.tum.de/~muenz= =0A=0A=0A=0A_______________________________________________=0ATLS mailing l= ist=0ATLS@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/tls=0A=0A=0A=0A = --0-1333662422-1253255667=:84105 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom: tom.petch <cfinss@dial.pipex.com>
To: Gerhard Muenz <muenz@net.in.tum.de>; syslog@iet= f.org; ipfix@ietf.org; tls@ietf.org
Cc: Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz = <mentz@in.tum.de>
Sent: Thursday, July 30, 2009 2:44:11 AM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in= DTLS

Gerhard

Thank you for pointing this out; it had = escaped me.

What I had thought though was that the lack of flow cont= rol with DTLS over UDP
is a problem, and that the lack of this with sysl= og over UDP led the syslog RFC
[RFC5424] to make syslog over TLS the REC= OMMENDED transport, not, as might be
expected, syslog over UDP.

T= his in turn led me to expect that syslog over DTLS over UDP would not be
acceptable to the IE= SG, rather that syslog over DTLS over SCTP would become the
RECOMMENDED = transport.

So; several thoughts.

This is an update to the ext= ensions RFC, RFC4366, which itself is being updated
by the TLS working g= roup (hence my addition of them to the list) and I would
much rather hav= e one extensions RFC rather than several.  This is a good concept
a= nd fills a need; perhaps the TLS working group would take this on.

F= low control remains an issue which I do not think that this extension
ad= dresses.

Is this a security exposure? or just, like syslog over UDP,= an inconvenient
truth?

The petch-gerhards draft allows the recip= ient of the unidirectional flow to
initiate the DTLS 'connection', and s= o enables it to re-establish the connection
when anything goes wrong.&nb= sp; This would seem an alternative to consider.

Tom Petch

----- Original Message -----
From: "Gerhard Muenz" <= muenz@net.in.tum.de>
To: <syslog@ietf.org>; <ipfix@ietf.org&= gt;
Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robi= n Seggelmann"
<seggelmann@fh-muenster.de>; "D= aniel Mentz" <mentz@in.tum.de>
Sent: Tuesday, July 28, 2009 10:41 A= M
Subject: [Syslog] Missing dead peer detection in DTLS


Hi,
This mail goes to the ipfix and syslog mailing lists in order to
s= ummarize the common issues regarding DTLS.

IPFIX specifies support of DTLS as mandatory= for transport over UDP and
SCTP in RFC5101. In SYSLOG, it is intended t= o standardize DTLS for
transport over UDP.

In IPFIX, we have a fi= rst implementation of IPFIX-over-DTLS/UDP, and we
will have a first impl= ementation of IPFIX-over-DTLS/SCTP very soon.
During this implementation= effort, we found that the current
specification of DTLS/UDP has a sever= e flaw when used with
unidirectional protocols (like IPFIX): The sender = cannot recognize if
the receiver has crashed and lost the DTLS state.
We discuss this issue in a draft:
http://tools.ietf.org/html/draft-= mentz-ipfix-dtls-recommendations-00
http://www.ietf.org/proceedings/75/s= lides/ipfix-6.pdf

I've had a look at draft-feng-syslog-transport-dtl= s-01 and
draft-petch-gerhards-syslog-transport-dtls-02. It seems that th= is
problem has not yet been covered, although the problem should be the
same for SYSLOG.

As a solution, the DTLS Heartbeat Extens= ion has been proposed very recently:
http://tools.ietf.org/html/draft-se= ggelmann-tls-dtls-heartbeat-00
A feature patch for OpenSSL is available:=
http://sctp.fh-muenster.de/dtls-patches.html#features

So, I thin= k that we should support this standardization initiative as it
solves ou= r problem. For IPFIX and SYSLOG over DTLS/UDP, we then can
specify that = the DTLS Heartbeat Extension MUST be implemented.

Dan suggested to h= ave a single document solving the DTLS issues
regarding unidirectional p= rotocols. I think that such a document is not
needed if we have DTLS Hea= rtbeat Extension.

Regards,
Gerhard

Dipl.-Ing. Gerhard M=FC= nz
Chair for Network Architectures and Services (I8)
Department of In= formatics
Technische Universit=E4t M=FCnchen
Boltzmannstr. 3, 85748 G= arching bei M=FCnchen, Germany
Phone:  +49 89 289-18008      Fax: +49 89 289-18033
E-mail: muenz@net.in.tum.de&= nbsp;   WWW: http://www.net.in.tum.de/~muenz



__________= _____________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

=0A=0A --0-1333662422-1253255667=:84105-- From tuexen@fh-muenster.de Thu Sep 17 23:58:20 2009 Return-Path: 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 032503A6AF0; Thu, 17 Sep 2009 23:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.545 X-Spam-Level: **** X-Spam-Status: No, score=4.545 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_35=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1] 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 Mp8YwjhvWzhN; Thu, 17 Sep 2009 23:58:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 24A493A6AF5; Thu, 17 Sep 2009 23:58:17 -0700 (PDT) Received: from [10.12.253.227] (unknown [212.44.18.222]) by mail-n.franken.de (Postfix) with ESMTP id 45C981C0B462B; Fri, 18 Sep 2009 08:59:07 +0200 (CEST) Message-Id: From: Michael Tuexen To: Erick O In-Reply-To: <587230.84105.qm@web45508.mail.sp1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 18 Sep 2009 07:59:06 +0100 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Fri, 18 Sep 2009 08:09:25 -0700 Cc: ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog@ietf.org, tls@ietf.org Subject: Re: [Syslog] [TLS] Missing dead peer detection in DTLS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 06:58:20 -0000 Hi Eric, See a comment in-line. Best regards Michael On Sep 18, 2009, at 7:34 AM, Erick O wrote: > > > From: tom.petch > To: Gerhard Muenz ; syslog@ietf.org; = ipfix@ietf.org=20 > ; tls@ietf.org > Cc: Michael Tuexen ; Daniel Mentz = > > Sent: Thursday, July 30, 2009 2:44:11 AM > Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS > > Gerhard > > Thank you for pointing this out; it had escaped me. > > What I had thought though was that the lack of flow control with =20 > DTLS over UDP > is a problem, and that the lack of this with syslog over UDP led the =20= > syslog RFC > [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as =20= > might be > expected, syslog over UDP. > > This in turn led me to expect that syslog over DTLS over UDP would =20 > not be > acceptable to the IESG, rather that syslog over DTLS over SCTP would =20= > become the > RECOMMENDED transport. > > So; several thoughts. > > This is an update to the extensions RFC, RFC4366, which itself is =20 > being updated > by the TLS working group (hence my addition of them to the list) and =20= > I would > much rather have one extensions RFC rather than several. This is a =20= > good concept > and fills a need; perhaps the TLS working group would take this on. > > Flow control remains an issue which I do not think that this extension > addresses. There can be only one HB in flight, so this extension neither overloads the receiver nor the network. Times are exponentially back offed. So for the messages introduced in this ID, we have a simple congestion and flow control. > > Is this a security exposure? or just, like syslog over UDP, an =20 > inconvenient > truth? > > The petch-gerhards draft allows the recipient of the unidirectional =20= > flow to > initiate the DTLS 'connection', and so enables it to re-establish =20 > the connection > when anything goes wrong. This would seem an alternative to consider. > > Tom Petch > > ----- Original Message ----- > From: "Gerhard Muenz" > To: ; > Cc: "Michael Tuexen" ; "Robin Seggelmann" > ; "Daniel Mentz" > Sent: Tuesday, July 28, 2009 10:41 AM > Subject: [Syslog] Missing dead peer detection in DTLS > > > Hi, > > This mail goes to the ipfix and syslog mailing lists in order to > summarize the common issues regarding DTLS. > > IPFIX specifies support of DTLS as mandatory for transport over UDP =20= > and > SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for > transport over UDP. > > In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and =20= > we > will have a first implementation of IPFIX-over-DTLS/SCTP very soon. > During this implementation effort, we found that the current > specification of DTLS/UDP has a severe flaw when used with > unidirectional protocols (like IPFIX): The sender cannot recognize if > the receiver has crashed and lost the DTLS state. > > We discuss this issue in a draft: > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00 > http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf > > I've had a look at draft-feng-syslog-transport-dtls-01 and > draft-petch-gerhards-syslog-transport-dtls-02. It seems that this > problem has not yet been covered, although the problem should be the > same for SYSLOG. > > As a solution, the DTLS Heartbeat Extension has been proposed very =20 > recently: > http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00 > A feature patch for OpenSSL is available: > http://sctp.fh-muenster.de/dtls-patches.html#features > > So, I think that we should support this standardization initiative =20 > as it > solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we then can > specify that the DTLS Heartbeat Extension MUST be implemented. > > Dan suggested to have a single document solving the DTLS issues > regarding unidirectional protocols. I think that such a document is =20= > not > needed if we have DTLS Heartbeat Extension. > > Regards, > Gerhard > > Dipl.-Ing. Gerhard M=FCnz > Chair for Network Architectures and Services (I8) > Department of Informatics > Technische Universit=E4t M=FCnchen > Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany > Phone: +49 89 289-18008 Fax: +49 89 289-18033 > E-mail: muenz@net.in.tum.de WWW: http://www.net.in.tum.de/~muenz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ericko0@yahoo.com Fri Sep 18 07:32:45 2009 Return-Path: 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 AD16128C159 for ; Fri, 18 Sep 2009 07:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sxr9byNG723m for ; Fri, 18 Sep 2009 07:32:44 -0700 (PDT) Received: from web45505.mail.sp1.yahoo.com (web45505.mail.sp1.yahoo.com [68.180.197.89]) by core3.amsl.com (Postfix) with SMTP id 4C24428C153 for ; Fri, 18 Sep 2009 07:32:44 -0700 (PDT) Received: (qmail 12143 invoked by uid 60001); 18 Sep 2009 14:33:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253284416; bh=lVozXTdlBLPkpbDDpLmxEPtffK+xfgF1EIC9zDHbS3I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=P1ohhFdpejNmntXUkmqjF3W+HlnIUuzQ1hiMubxc/pVZbAmiyUucXlBQqqPGRV1nQmHEoITTjjhtmc+XUmEtkVnuYSAz+dlfuAznyCl+eY4elwSRP9VNC/u8FZHH2T2fsAvPHIRCRGZISRK85gDSBDiEF/HivyFpLuhwvPCh3sY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2jEgCsFPLj7VqqoE+Nxmoa90PRTWZP5hJCbTMDgf2ahGhFv0mIT8nkGqDJnNM0wV33ik/jVMdQ10rRdueeZ+FGkyECTMZsoIv9UR7mW04b42+VvFfN+Nbo8UGHwK2hBlMQFJDK7tNOv4PE6h+sV0hGYPo1IwI1P3sNe3oYhZs2I=; Message-ID: <443305.4608.qm@web45505.mail.sp1.yahoo.com> X-YMail-OSG: bS2GhIUVM1kVy.LhlrRoJDT8VgmWKcvgKPjKrTAo4vvD9INZp2ct_WTKM31dWxq.J1iB9wCKjziyqSjMld6NLpsRO54WaMreQ9xhypDvVDrythoBGx0BO9fcJnb1C1Tmogb_Zr931_CD2q9kGdJPKcfw847On9y0Tm6wY7879tbHv2gEd3f1.VGP1YQ9F2p__3vr.kFRA2Nrl_otFzu3np4684WJMUchwpnAPaxElpspXXVvKr0- Received: from [68.106.217.192] by web45505.mail.sp1.yahoo.com via HTTP; Fri, 18 Sep 2009 07:33:36 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> Date: Fri, 18 Sep 2009 07:33:36 -0700 (PDT) From: Erick O To: Michael Tuexen In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1490659396-1253284416=:4608" X-Mailman-Approved-At: Fri, 18 Sep 2009 08:09:25 -0700 Cc: ipfix@ietf.org, Daniel Mentz , Gerhard Muenz , syslog@ietf.org, tls@ietf.org Subject: Re: [Syslog] [TLS] Missing dead peer detection in DTLS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 14:32:45 -0000 --0-1490659396-1253284416=:4608 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: Michael Tuexen =0ATo: Erick O =0ACc: tom.petch ; Gerhard Muenz ; syslog@ietf.org; i= pfix@ietf.org; tls@ietf.org; Daniel Mentz =0ASent: Thursda= y, September 17, 2009 11:59:06 PM=0ASubject: Re: [TLS] [Syslog] Missing dea= d peer detection in DTLS=0A=0AHi Eric,=0A=0ASee a comment in-line.=0A=0ABes= t regards=0AMichael=0A=0AOn Sep 18, 2009, at 7:34 AM, Erick O wrote:=0A=0A>= =0A> =0A> From: tom.petch =0A> To: Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0A> Cc: = Michael Tuexen ; Daniel Mentz =0A> = Sent: Thursday, July 30, 2009 2:44:11 AM=0A> Subject: Re: [TLS] [Syslog] Mi= ssing dead peer detection in DTLS=0A> =0A> Gerhard=0A> =0A> Thank you for p= ointing this out; it had escaped me.=0A> =0A> What I had thought though was= that the lack of flow control with DTLS over UDP=0A> is a problem, and tha= t the lack of this with syslog over UDP led the syslog RFC=0A> [RFC5424] to= make syslog over TLS the RECOMMENDED transport, not, as might be=0A> expec= ted, syslog over UDP.=0A> =0A> This in turn led me to expect that syslog ov= er DTLS over UDP would not be=0A> acceptable to the IESG, rather that syslo= g over DTLS over SCTP would become the=0A> RECOMMENDED transport.=0A> =0A> = So; several thoughts.=0A> =0A> This is an update to the extensions RFC, RFC= 4366, which itself is being updated=0A> by the TLS working group (hence my = addition of them to the list) and I would=0A> much rather have one extensio= ns RFC rather than several.=A0 This is a good concept=0A> and fills a need;= perhaps the TLS working group would take this on.=0A> =0A> Flow control re= mains an issue which I do not think that this extension=0A> addresses.=0ATh= ere can be only one HB in flight, so this extension neither overloads=0Athe= receiver nor the network. Times are exponentially back offed.=0ASo for the= messages introduced in this ID, we have a simple congestion=0Aand flow con= trol.=0A> =0A> Is this a security exposure? or just, like syslog over UDP, = an inconvenient=0A> truth?=0A> =0A> The petch-gerhards draft allows the rec= ipient of the unidirectional flow to=0A> initiate the DTLS 'connection', an= d so enables it to re-establish the connection=0A> when anything goes wrong= .=A0 This would seem an alternative to consider.=0A> =0A> Tom Petch=0A> =0A= > ----- Original Message -----=0A> From: "Gerhard Muenz" =0A> To: ; =0A> Cc: "Michael Tuexen" ; "Robin Seggelmann"=0A> ; = "Daniel Mentz" =0A> Sent: Tuesday, July 28, 2009 10:41 AM= =0A> Subject: [Syslog] Missing dead peer detection in DTLS=0A> =0A> =0A> Hi= ,=0A> =0A> This mail goes to the ipfix and syslog mailing lists in order to= =0A> summarize the common issues regarding DTLS.=0A> =0A> IPFIX specifies s= upport of DTLS as mandatory for transport over UDP and=0A> SCTP in RFC5101.= In SYSLOG, it is intended to standardize DTLS for=0A> transport over UDP.= =0A> =0A> In IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, = and we=0A> will have a first implementation of IPFIX-over-DTLS/SCTP very so= on.=0A> During this implementation effort, we found that the current=0A> sp= ecification of DTLS/UDP has a severe flaw when used with=0A> unidirectional= protocols (like IPFIX): The sender cannot recognize if=0A> the receiver ha= s crashed and lost the DTLS state.=0A> =0A> We discuss this issue in a draf= t:=0A> http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00= =0A> http://www.ietf.org/proceedings/75/slides/ipfix-6.pdf=0A> =0A> I've ha= d a look at draft-feng-syslog-transport-dtls-01 and=0A> draft-petch-gerhard= s-syslog-transport-dtls-02. It seems that this=0A> problem has not yet been= covered, although the problem should be the=0A> same for SYSLOG.=0A> =0A> = As a solution, the DTLS Heartbeat Extension has been proposed very recently= :=0A> http://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00=0A>= A feature patch for OpenSSL is available:=0A> http://sctp.fh-muenster.de/d= tls-patches.html#features=0A> =0A> So, I think that we should support this = standardization initiative as it=0A> solves our problem. For IPFIX and SYSL= OG over DTLS/UDP, we then can=0A> specify that the DTLS Heartbeat Extension= MUST be implemented.=0A> =0A> Dan suggested to have a single document solv= ing the DTLS issues=0A> regarding unidirectional protocols. I think that su= ch a document is not=0A> needed if we have DTLS Heartbeat Extension.=0A> = =0A> Regards,=0A> Gerhard=0A> =0A> Dipl.-Ing. Gerhard M=FCnz=0A> Chair for = Network Architectures and Services (I8)=0A> Department of Informatics=0A> T= echnische Universit=E4t M=FCnchen=0A> Boltzmannstr. 3, 85748 Garching bei M= =FCnchen, Germany=0A> Phone:=A0 +49 89 289-18008=A0 =A0 =A0 Fax: +49 89 289= -18033=0A> E-mail: muenz@net.in.tum.de=A0 =A0 WWW: http://www.net.in.tum.de= /~muenz=0A> =0A> =0A> =0A> _______________________________________________= =0A> TLS mailing list=0A> TLS@ietf.org=0A> https://www.ietf.org/mailman/lis= tinfo/tls=0A> =0A> _______________________________________________=0A> TLS = mailing list=0A> TLS@ietf.org=0A> https://www.ietf.org/mailman/listinfo/tls= =0A=0A=0A --0-1490659396-1253284416=:4608 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom: Michael Tuexen <tuexen@fh-muenster.de>
To: Erick O <ericko0@yahoo.com>
Cc: tom.petch <cfinss@dial.pipex.co= m>; Gerhard Muenz <muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ie= tf.org; tls@ietf.org; Daniel Mentz <mentz@in.tum.de>
Sent: Thursday, September 17, 2009 11:59= :06 PM
Subject: Re: [TLS= ] [Syslog] Missing dead peer detection in DTLS

Hi Eric,
See a comment in-line.

Best regards
Michael

On Sep 18, 2= 009, at 7:34 AM, Erick O wrote:

>
>
> From: tom.pet= ch <cfinss@dial.pipex.com>
> To: Gerhard Muenz <<= A href=3D"mailto:muenz@net.in.tum.de" ymailto=3D"mailto:muenz@net.in.tum.de"= >muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org
> Cc= : Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz <= ;ment= z@in.tum.de>
> Sent: Thursday, July 30, 2009 2:44:11 AM
>= ; Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS
> <= BR>> Gerhard
>
> Thank you for pointing this out; it had es= caped me.
>
> What I had thought though was that the lack of f= low control with DTLS over UDP
> is a problem, and that the lack of t= his with syslog over UDP led the syslog RFC
> [RFC5424] to make syslog over TLS the = RECOMMENDED transport, not, as might be
> expected, syslog over UDP.<= BR>>
> This in turn led me to expect that syslog over DTLS over U= DP would not be
> acceptable to the IESG, rather that syslog over DTL= S over SCTP would become the
> RECOMMENDED transport.
>
>= ; So; several thoughts.
>
> This is an update to the extension= s RFC, RFC4366, which itself is being updated
> by the TLS working gr= oup (hence my addition of them to the list) and I would
> much rather= have one extensions RFC rather than several.  This is a good concept<= BR>> and fills a need; perhaps the TLS working group would take this on.=
>
> Flow control remains an issue which I do not think that t= his extension
> addresses.
There can be only one HB in flight, so = this extension neither overloads
the receiver nor the network. Times are exponentially back offed.
So for the messages introduced in t= his ID, we have a simple congestion
and flow control.
>
> I= s this a security exposure? or just, like syslog over UDP, an inconvenient<= BR>> truth?
>
> The petch-gerhards draft allows the recipie= nt of the unidirectional flow to
> initiate the DTLS 'connection', an= d so enables it to re-establish the connection
> when anything goes w= rong.  This would seem an alternative to consider.
>
> To= m Petch
>
> ----- Original Message -----
> From: "Gerhar= d Muenz" <muenz@net.in.tum.de>
> To: <syslog@ietf.org&= gt;; <ipfix@ietf.org>
> Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robin Seggelmann"
> <seggelmann@fh-muenster.de>; "Daniel Mentz" <mentz@in.tum.de>
> Sent: Tuesday, July 28, 2009 10:41 AM
> Subject: [Syslo= g] Missing dead peer detection in DTLS
>
>
> Hi,
>= ;
> This mail goes to the ipfix and syslog mailing lists in order to=
> summarize the common issues regarding DTLS.
>
> IPFIX= specifies support of DTLS as mandatory for transport over UDP and
> = SCTP in RFC5101. In SYSLOG, it is intended to standardize DTLS for
> = transport over UDP.
>
> In IPFIX, we have a first implementati= on of IPFIX-over-DTLS/UDP, and we
> will have a first implementation = of IPFIX-over-DTLS/SCTP very soon.
> During this implementation effort,= we found that the current
> specification of DTLS/UDP has a severe f= law when used with
> unidirectional protocols (like IPFIX): The sende= r cannot recognize if
> the receiver has crashed and lost the DTLS st= ate.
>
> We discuss this issue in a draft:
> http://tool= s.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00
> http://ww= w.ietf.org/proceedings/75/slides/ipfix-6.pdf
>
> I've had a lo= ok at draft-feng-syslog-transport-dtls-01 and
> draft-petch-gerhards-= syslog-transport-dtls-02. It seems that this
> problem has not yet be= en covered, although the problem should be the
> same for SYSLOG.
= >
> As a solution, the DTLS Heartbeat Extension has been proposed= very recently:
> http://tools.ietf.org/html/draft-seggelmann-tls-dtl= s-heartbeat-00
> A feature patch for OpenSSL is available:
> http://sctp.fh-muenster.de/dtls-patches.html#features>
> So, I think that we should support this standardization ini= tiative as it
> solves our problem. For IPFIX and SYSLOG over DTLS/UD= P, we then can
> specify that the DTLS Heartbeat Extension MUST be im= plemented.
>
> Dan suggested to have a single document solving= the DTLS issues
> regarding unidirectional protocols. I think that s= uch a document is not
> needed if we have DTLS Heartbeat Extension.>
> Regards,
> Gerhard
>
> Dipl.-Ing. Gerhar= d M=FCnz
> Chair for Network Architectures and Services (I8)
> = Department of Informatics
> Technische Universit=E4t M=FCnchen
>= ; Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany
> Phone:&nbs= p; +49 89 289-18008      Fax: +49 89 289-18033
> E-mai= l: muenz@net.in.tum.de   = ; WWW: http://www.net.in.tum.de/~muenz
>
>
>
> _= ______________________________________________
> TLS mailing list
= > TLS@ie= tf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>= ; _______________________________________________
> TLS mailing list<= BR>> TLS= @ietf.org
> https://www.ietf.org/mailman/listinfo/tls


=0A=0A --0-1490659396-1253284416=:4608-- From ericko0@yahoo.com Fri Sep 18 07:34:37 2009 Return-Path: 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 BB6C73A6AD1 for ; Fri, 18 Sep 2009 07:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4XQzz9fHBH+o for ; Fri, 18 Sep 2009 07:34:36 -0700 (PDT) Received: from web45513.mail.sp1.yahoo.com (web45513.mail.sp1.yahoo.com [68.180.197.161]) by core3.amsl.com (Postfix) with SMTP id 8D9FA28C14C for ; Fri, 18 Sep 2009 07:34:19 -0700 (PDT) Received: (qmail 86955 invoked by uid 60001); 18 Sep 2009 14:35:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253284501; bh=SUzTzHgOCjuEy3oqHBcQkhQezJKIqueeqWA3odmEQqQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GAcQXG3roDDwhULVkRMbn2npqLuphKdVBRM5+Pcr5FBcb6pT7vJk+lqW2jeb8hoFSHCwdEsnvPdDnqLw86W92Lpbo567tmIjeBOAQRC4HSqbxl/rGWVvWwM6d+GoDhDORJeVtbmZSWDzpQajttBPvFD+G7/KBpFXFCHCGIrnmk8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SANlV6NukQvMrMzpha83yqgnz656DBnxjraxKaIh2X5zjDkYayr0MVAjrg0a9cP7U5BsYb4KTeCLOtd1PugwL9bGTqzQxzR3KtgJCgJBmxRSV1vPO4rS/CyNzGbpVGncjBnaNVOPa3phEeW2RoE5ZeUz1xTo6HqCpO2InS9wjFw=; Message-ID: <176544.85122.qm@web45513.mail.sp1.yahoo.com> X-YMail-OSG: sgmRthsVM1nZbDYq.OOGwKz2gk06ppjs839F_BTlK2vI8QqRj15y.8FGgppHol9ypWdvE7dXBav.6qLZCfZtnrMdicQIkn2UTB3qx0HNi2UyyFz_6FmvJr_QLl_wedqfGIjcANkvhAaUsGaorrmrE4.0x55I6Of2ddBfCYdq5.jasCE.zSO5GnMkcvtAAIBoPT9GZ33pl._QOn3iZahn4p1Jc05iNKbWNywqa6FZDn9R Received: from [68.106.217.192] by web45513.mail.sp1.yahoo.com via HTTP; Fri, 18 Sep 2009 07:35:00 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <587230.84105.qm@web45508.mail.sp1.yahoo.com> Date: Fri, 18 Sep 2009 07:35:00 -0700 (PDT) From: Erick O To: Erick O , "tom.petch" , Gerhard Muenz , syslog@ietf.org, ipfix@ietf.org, tls@ietf.org In-Reply-To: <587230.84105.qm@web45508.mail.sp1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-859172981-1253284500=:85122" X-Mailman-Approved-At: Fri, 18 Sep 2009 08:09:25 -0700 Cc: Michael Tuexen , Daniel Mentz Subject: Re: [Syslog] [TLS] Missing dead peer detection in DTLS X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 14:34:37 -0000 --0-859172981-1253284500=:85122 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0A=0A=0A=0A________________________________=0AFrom: Erick O =0ATo: tom.petch ; Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0ACc: Michael Tue= xen ; Daniel Mentz =0ASent: Thursda= y, September 17, 2009 11:34:27 PM=0ASubject: Re: [TLS] [Syslog] Missing dea= d peer detection in DTLS=0A=0A=0A=0A=0A=0A=0A=0A___________________________= _____=0AFrom: tom.petch =0ATo: Gerhard Muenz ; syslog@ietf.org; ipfix@ietf.org; tls@ietf.org=0ACc: Michael= Tuexen ; Daniel Mentz =0ASent: Thu= rsday, July 30, 2009 2:44:11 AM=0ASubject: Re: [TLS] [Syslog] Missing dead = peer detection in DTLS=0A=0AGerhard=0A=0AThank you for pointing this out; i= t had escaped me.=0A=0AWhat I had thought though was that the lack of flow = control with DTLS over UDP=0Ais a problem, and that the lack of this with s= yslog over UDP led the syslog RFC=0A[RFC5424] to make syslog over TLS the R= ECOMMENDED transport, not, as might be=0Aexpected, syslog over UDP.=0A=0ATh= is in turn led me to expect that syslog over DTLS over UDP would not be=0Aa= cceptable to the IESG, rather that syslog over DTLS over SCTP would become = the=0ARECOMMENDED transport.=0A=0ASo; several thoughts.=0A=0AThis is an upd= ate to the extensions RFC, RFC4366, which itself is being updated=0Aby the = TLS working group (hence my addition of them to the list) and I would=0Amuc= h rather have one extensions RFC rather than several.=A0 This is a good con= cept=0Aand fills a need; perhaps the TLS working group would take this on.= =0A=0AFlow control remains an issue which I do not think that this extensio= n=0Aaddresses.=0A=0AIs this a security exposure? or just, like syslog over = UDP, an inconvenient=0Atruth?=0A=0AThe petch-gerhards draft allows the reci= pient of the unidirectional flow to=0Ainitiate the DTLS 'connection', and s= o enables it to re-establish the connection=0Awhen anything goes wrong.=A0 = This would seem an alternative to consider.=0A=0ATom Petch=0A=0A----- Origi= nal Message -----=0AFrom: "Gerhard Muenz" =0ATo: ; =0ACc: "Michael Tuexen" ; "Robin Seggelmann"=0A; "Daniel Mentz" =0ASent: Tuesday, July 28, 2009 10:41 AM=0ASubject: [Syslog] Mis= sing dead peer detection in DTLS=0A=0A=0AHi,=0A=0AThis mail goes to the ipf= ix and syslog mailing lists in order to=0Asummarize the common issues regar= ding DTLS.=0A=0AIPFIX specifies support of DTLS as mandatory for transport = over UDP and=0ASCTP in RFC5101. In SYSLOG, it is intended to standardize DT= LS for=0Atransport over UDP.=0A=0AIn IPFIX, we have a first implementation = of IPFIX-over-DTLS/UDP, and we=0Awill have a first implementation of IPFIX-= over-DTLS/SCTP very soon.=0ADuring this implementation effort, we found tha= t the current=0Aspecification of DTLS/UDP has a severe flaw when used with= =0Aunidirectional protocols (like IPFIX): The sender cannot recognize if=0A= the receiver has crashed and lost the DTLS state.=0A=0AWe discuss this issu= e in a draft:=0Ahttp://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommend= ations-00=0Ahttp://www.ietf.org/proceedings/75/slides/ipfix-6.pdf=0A=0AI've= had a look at draft-feng-syslog-transport-dtls-01 and=0Adraft-petch-gerhar= ds-syslog-transport-dtls-02. It seems that this=0Aproblem has not yet been = covered, although the problem should be the=0Asame for SYSLOG.=0A=0AAs a so= lution, the DTLS Heartbeat Extension has been proposed very recently:=0Ahtt= p://tools.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00=0AA feature = patch for OpenSSL is available:=0Ahttp://sctp.fh-muenster.de/dtls-patches.h= tml#features=0A=0ASo, I think that we should support this standardization i= nitiative as it=0Asolves our problem. For IPFIX and SYSLOG over DTLS/UDP, w= e then can=0Aspecify that the DTLS Heartbeat Extension MUST be implemented.= =0A=0ADan suggested to have a single document solving the DTLS issues=0Areg= arding unidirectional protocols. I think that such a document is not=0Aneed= ed if we have DTLS Heartbeat Extension.=0A=0ARegards,=0AGerhard=0A=0ADipl.-= Ing. Gerhard M=FCnz=0AChair for Network Architectures and Services (I8)=0AD= epartment of Informatics=0ATechnische Universit=E4t M=FCnchen=0ABoltzmannst= r. 3, 85748 Garching bei M=FCnchen, Germany=0APhone:=A0 +49 89 289-18008=A0= =A0 =A0 Fax: +49 89 289-18033=0AE-mail: muenz@net.in.tum.de=A0 =A0 WWW: ht= tp://www.net.in.tum.de/~muenz=0A=0A=0A=0A__________________________________= _____________=0ATLS mailing list=0ATLS@ietf.org=0Ahttps://www.ietf.org/mail= man/listinfo/tls=0A=0A=0A --0-859172981-1253284500=:85122 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

=0A

=0A
=0A
=0AFrom= : Erick O <ericko0@yahoo.com>
To: tom.petch <cfinss@dial.pipex.com>; Gerhard= Muenz <muenz@net.in.tum.de>; syslog@ietf.org; ipfix@ietf.org; tls@ie= tf.org
Cc: Michael Tuexe= n <tuexen@fh-muenster.de>; Daniel Mentz <mentz@in.tum.de>
Sent: Thursday, September 17,= 2009 11:34:27 PM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS

=0A=
=0A

=0A

=0A
=0A
=0AFrom: t= om.petch <cfinss@dial.pipex.com>
To: Gerhard Muenz <muenz@net.in.tum.de>; syslog@ietf.o= rg; ipfix@ietf.org; tls@ietf.org
Cc= : Michael Tuexen <tuexen@fh-muenster.de>; Daniel Mentz <= ;mentz@in.tum.de>
Sent: Thursday, July 30, 2009 2:44:11 AM
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DT= LS

Gerhard

Thank you for pointing this out; it had esc= aped me.

What I had thought though was that the lack of flow control= with DTLS over UDP
is a problem, and that the lack of this with syslog = over UDP led the syslog RFC
[RFC5424] to make syslog over TLS the RECOMM= ENDED transport, not, as might be
expected, syslog over UDP.

This= in turn led me to expect that syslog over DTLS over UDP would not be
acceptable to the IE= SG, rather that syslog over DTLS over SCTP would become the
RECOMMENDED = transport.

So; several thoughts.

This is an update to the ext= ensions RFC, RFC4366, which itself is being updated
by the TLS working g= roup (hence my addition of them to the list) and I would
much rather hav= e one extensions RFC rather than several.  This is a good concept
a= nd fills a need; perhaps the TLS working group would take this on.

F= low control remains an issue which I do not think that this extension
ad= dresses.

Is this a security exposure? or just, like syslog over UDP,= an inconvenient
truth?

The petch-gerhards draft allows the recip= ient of the unidirectional flow to
initiate the DTLS 'connection', and s= o enables it to re-establish the connection
when anything goes wrong.&nb= sp; This would seem an alternative to consider.

Tom Petch

----- Original Message -----
From: "Gerhard Muenz" <muenz@net.in.tum.de>
To: <syslog@ietf.org>; <= ipfix@ietf.org>
Cc: "Michael Tuexen" <tuexen@fh-muenster.de>; "Robin Seggelmann"
<seggelmann@fh-muenster.de>= ; "Daniel Mentz" <mentz@in.tum.de>
S= ent: Tuesday, July 28, 2009 10:41 AM
Subject: [Syslog] Missing dead peer detection in DTLS


Hi,=

This mail goes to the ipfix and syslog mailing lists in order tosummarize the common issues regarding DTLS.

IPFIX specifies support= of DTLS as mandatory for transport over UDP and
SCTP in RFC5101. In SYS= LOG, it is intended to standardize DTLS for
transport over UDP.

I= n IPFIX, we have a first implementation of IPFIX-over-DTLS/UDP, and we
w= ill have a first implementation of IPFIX-over-DTLS/SCTP very soon.
Durin= g this implementation effort, we found that the current
specification of= DTLS/UDP has a severe flaw when used with
unidirectional protocols (lik= e IPFIX): The sender cannot recognize if
the receiver has crashed and lo= st the DTLS state.

We discuss this issue in a draft:
http://tools= .ietf.org/html/draft-mentz-ipfix-dtls-recommendations-00
http://www.ietf= .org/proceedings/75/slides/ipfix-6.pdf

I've had a look at draft-feng-syslog-transport-dtls-01 and
draft-petch-gerhards-syslog-tra= nsport-dtls-02. It seems that this
problem has not yet been covered, alt= hough the problem should be the
same for SYSLOG.

As a solution, t= he DTLS Heartbeat Extension has been proposed very recently:
http://tool= s.ietf.org/html/draft-seggelmann-tls-dtls-heartbeat-00
A feature patch f= or OpenSSL is available:
http://sctp.fh-muenster.de/dtls-patches.html#fe= atures

So, I think that we should support this standardization initi= ative as it
solves our problem. For IPFIX and SYSLOG over DTLS/UDP, we t= hen can
specify that the DTLS Heartbeat Extension MUST be implemented.
Dan suggested to have a single document solving the DTLS issues
re= garding unidirectional protocols. I think that such a document is not
ne= eded if we have DTLS Heartbeat Extension.

Regards,
Gerhard
Dipl.-Ing. Gerhard M=FCnz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universit=E4t M= =FCnchen
Boltzmannstr. 3, 85748 Garching bei M=FCnchen, Germany
Phone= :  +49 89 289-18008      Fax: +49 89 289-18033
E-mai= l: muenz@net.in.tum.de    W= WW: http://www.net.in.tum.de/~muenz



________________________= _______________________
TLS mailing list
TLS@ietf= .org
https://www.ietf.org/mailman/listinfo/tls


=0A=0A=0A=0A --0-859172981-1253284500=:85122--