From ietfdbh@comcast.net Wed Feb 3 12:32:12 2010 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 B392D28C1AF for ; Wed, 3 Feb 2010 12:32:12 -0800 (PST) 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=[AWL=0.000, 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 xM0eeYh2OIPC for ; Wed, 3 Feb 2010 12:32:11 -0800 (PST) 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 89B5228C1AB for ; Wed, 3 Feb 2010 12:32:11 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta08.westchester.pa.mail.comcast.net with comcast id dPDD1d0020mv7h058YYvAD; Wed, 03 Feb 2010 20:32:55 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta11.westchester.pa.mail.comcast.net with comcast id dYYv1d00E284sdk3XYYvap; Wed, 03 Feb 2010 20:32:55 +0000 From: "David Harrington" To: Date: Wed, 3 Feb 2010 15:32:54 -0500 Message-ID: <023f01caa510$105d7320$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 Thread-Index: AcqlEA/rtN7U9CYlSHeyjjG7SuaBQg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] WGLC review of draft-ietf-syslog-dtls-01 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, 03 Feb 2010 20:32:12 -0000 Hi, I have reviewed (a slightly early revision of) draft-ietf-syslog-dtls-01 and have a few comments. Almost all are purely editorial. There are a few questions about technical decisions, and some recommendations that modify RFC2119 language. I think this document is in great shape, and almost ready for submission to the IESG. section 1: s/ to secure syslog in more situations./and these can be used to secure syslog in more situations./ s/therefor/therefore/ section 5.1: s/Transports, such as UDP or DCCP/UDP and DCCP transports/ s/In such case, the/The/ Based on some advice from Lars, I recommend s/Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. / Implementations of this specification MUST support both DTLS over UDP and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but implementations of this specification MUST be prepared to support DCCP where it is available." The sentence starting "Each SYSLOG message" needs some tweaking of the English. s/by DTLS record protocol/by the DTLS record protocol/ I think the last sentence is missing a verb - are delivered. I am not sure that "assure" is the correct word choice. s/such as UDP reliability/such as UDP, reliability/ Can we be more precise than "gone down"? s/state so/state, so/ s/When TCP is used syslog over DTLS MUST NOT be used./Syslog over DTLS MUST NOT be used to secure syslog running over TCP./ s/When a secure transport/When a secure syslog transport/ section 5.2: s/allocated/allocated by IANA/ section 5.3.1. I personally prefer consistency: s/SHALL/MUST/ Some people, including some members of IESG, believe that a SHOULD should describe roughly why this is a SHOULD rather than a MUST. I am not sure I understand why this is a SHOULD rather than a MAY - what vulnerabilities does this create if it is not done? I would like to see a bit more explanation of this SHOULD. section 5.4 s/All syslog messages MUST be sent as DTLS "application data"./A syslog/dtls transport sender MUST send syslog messages as DTLS "application data"./ "The application data is defined with the following ABNF [RFC5234] expression:" I had to think about why this was here; it was not at all obvious to me. My first recommendation was s/application data/DTLS "application data"/ In thinking about it more, I think my confusion was partly because you have text about multiple or split messages between the point that says the message is sent as "application data", and the definition of the format of the application data, so my mind had "gone elsewhere". I recommend taking the discussion of multiple/split messages and put that into 5.4.1, as part of the discussion of message size and dtls records. I think that will make it more obvious that the ABNF is there to describe the format of the "application data". s/be contained/are contained/ s/be transferred in/is split into/ section 5.4.1 s/The message length is/The message length (MSG-LEN) is/ I think it would be helpful to point out the DTLS maximum limits for UDP and DCCP transports, since those are the syslog/dtls mandatory to implement transports. If a syslog message exceeds the maximum for the transport used, will DTLS automatically split the message into multiple records? That was the impression I got from the 5.4 discussion of multiple/split messages. I think it is important to describe this because there are other standards in progress (IHE, sipclf) with very large application data that are considering using syslog as a transport, and if DTLS will make a bad transport for applications with large messages, we might want to make that explicit. section 7 why do we request the same port#? There can be multiple syslog sources on a device (e.g. in a Windows environment). Can this shared port# make things harder to work (or to configure for non-default ports)? good work! Thanks, dbh David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From ietfdbh@comcast.net Wed Feb 3 13:37:56 2010 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 E1C6F3A6B4A for ; Wed, 3 Feb 2010 13:37:55 -0800 (PST) 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 NBqN0skejPhD for ; Wed, 3 Feb 2010 13:37:55 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 8C4953A6B47 for ; Wed, 3 Feb 2010 13:37:55 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id dRBT1d00A0ldTLk55ZcuLM; Wed, 03 Feb 2010 21:36:54 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta04.westchester.pa.mail.comcast.net with comcast id dZdf1d00Q284sdk3QZdfDb; Wed, 03 Feb 2010 21:37:40 +0000 From: "David Harrington" To: "'Wes Hardaker'" , , "'Joseph Salowey \(jsalowey\)'" , Date: Wed, 3 Feb 2010 16:37:38 -0500 Message-ID: <024f01caa519$1bd2b680$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 Thread-Index: AcqlGRs1IIhVu5u9SPm0fld2OU5iGQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] syslog/dtls and snmp/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: Wed, 03 Feb 2010 21:37:56 -0000 Hi, I quickly looked at the two documents for differences. I found a few I thought might deserve discussion: -- DoS -- syslog: Implementations MUST support the denial of service countermeasures defined by DTLS. When these countermeasures are enabled, the transport receiver responds with a DTLS Hello Verify Request containing a cookie. snmp: DTLS Transport Model server implementations MUST support DTLS cookies. Implementations are not required to perform the stateless cookie exchange for every DTLS handshake, but in environments where an overload on server side resources is detectable by the implementation it is RECOMMENDED that the cookie exchange is utilized by the implementation. My impression is that syslog allows an admin to enable this as a deployment option; tlstm seems to depend on the implementation. (and I have difficulty knowing how an implementation will know if overlaod on server side is detectable, unless it is doing the detection itself.) 1) Is enable/disable capability a MUST implement for DTLS cookie exchange? 2) Should tlstm recognize whether it is enabled/disabled? 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in syslog when the implementation can detect an overload on server resources? 4) in syslog, would it be better to specify the actions of the DTLS entity rather than "the transport receiver"? Does the draft spell out clearly whether the "transport receiver" is the DTLS client or DTLS server? When a syslog entity can act as both sender and receiver, what is that implementation REQUIRED to support in terms of DTLS client and DTLS server? I didn't see that in the text prior to section 5.3.1; should this be made clear in the terminology section? Should there be mandatory-to-implement text about this? -- DCCP -- syslog/dtls supports the dccp transport: As the Internet best runs on the basis of appropriate resource sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this document. For systems where DCCP is either not available or not usable (such as the afformentioned situation), DTLS over UDP is also defined. In those circumstances where reliability or ordering is important, SYSLOG over TLS is appropriate. Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution. and DTLS can run over multiple transports. Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. and When TCP is used syslog over DTLS MUST NOT be used. If a secure transport is required with TCP then the appropriate mechanism is syslog over TLS. although we are discussing: Based on some advice from Lars, I recommend s/Implementations of this specification MUST support DTLS over UDP and SHOULD support DTLS over DCCP [RFC5238]. / Implementations of this specification MUST support both DTLS over UDP and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but implementations of this specification MUST be prepared to support DCCP where it is available." I notice DCCP is not mentioned by TLSTM. I'm not sure how much extra work it would take to add DCCP support to snmp/dtls. -- ports -- Since DTLS can run over DCCP, tlstm might want to define a domain for that while you're at it (or not). -- cipher suites -- syslog: Implementations MUST support DTLS 1.1 [RFC4347] and MUST support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. tsltm: does not define a mandatory-to-implement cipher suite. Could this impact interoperability? I know this is one of those points that keeps getting discussed. 1) A mandatory-to-implement cipher suite ensures that different implementations will have at least one suite that cna be used for interoperability. 2) But doesn't DTLS already define mandatory-to-implement cipher suites? Do we need to do that here as well? Isn't it inherited from DTLS? How's this for a discussion starter? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From root@core3.amsl.com Wed Feb 3 17:15:02 2010 Return-Path: X-Original-To: syslog@ietf.org Delivered-To: syslog@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C713B3A6985; Wed, 3 Feb 2010 17:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100204011502.C713B3A6985@core3.amsl.com> Date: Wed, 3 Feb 2010 17:15:02 -0800 (PST) Cc: syslog@ietf.org Subject: [Syslog] I-D Action:draft-ietf-syslog-dtls-01.txt 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: Thu, 04 Feb 2010 01:15:02 -0000 --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 : Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog Author(s) : J. Salowey, et al. Filename : draft-ietf-syslog-dtls-01.txt Pages : 17 Date : 2010-02-03 This document describes the transport of syslog messages over DTLS (Datagram Transport Level Security). It provides a secure transport for syslog messages in cases where a connection-less transport is desired. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-01.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-dtls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-02-03170256.I-D@ietf.org> --NextPart-- From ietfdbh@comcast.net Thu Feb 4 07:27:50 2010 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 5D5DF3A6C11 for ; Thu, 4 Feb 2010 07:27:50 -0800 (PST) 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=[AWL=0.000, 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 fftQCS363B0z for ; Thu, 4 Feb 2010 07:27:49 -0800 (PST) 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 75DA73A6C4E for ; Thu, 4 Feb 2010 07:27:49 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id dnPS1d00116LCl05ArUc2H; Thu, 04 Feb 2010 15:28:36 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta06.westchester.pa.mail.comcast.net with comcast id drUc1d00l284sdk3SrUctD; Thu, 04 Feb 2010 15:28:36 +0000 From: "David Harrington" To: Date: Thu, 4 Feb 2010 10:28:35 -0500 Message-ID: <02a901caa5ae$b7b05680$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 Thread-Index: Aca9eshA1FDihlvYTnG5mJ3d+GHqgACfNhRgACiX1iCHyiJOEA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: [Syslog] Working Group Last Call: draft-ietf-syslog-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: Thu, 04 Feb 2010 15:27:50 -0000 Hi, This message officially starts the Syslog Working Group Last Call for the following document: Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-01.txt The Working Group Last Call for this document will end February 19. To help get this document reviewed throughly, we are seeking volunteers to review the documents for the following special reviews: 1) Spelling and grammar, 2) boilerplates and reference review, 3) security review The chairs want to see a minimum number of content reviews before we submit the documents to the IESG. If you review the document and it looks fine, please post a statement that you have reviewed and found the document acceptable. Obviously, it if does not look acceptable please identify your objections, preferably with suggested text that would make it acceptable. Thanks, David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net co-chair, Syslog WG From j.schoenwaelder@jacobs-university.de Fri Feb 5 01:33:50 2010 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 CF16E3A69B9; Fri, 5 Feb 2010 01:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ygOCArbTI+wg; Fri, 5 Feb 2010 01:33:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 40E453A6880; Fri, 5 Feb 2010 01:33:49 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 635DCC003F; Fri, 5 Feb 2010 10:34:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e4k68XijfgbA; Fri, 5 Feb 2010 10:34:36 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2B9CAC0006; Fri, 5 Feb 2010 10:34:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9B4CA103F3B0; Fri, 5 Feb 2010 10:34:23 +0100 (CET) Date: Fri, 5 Feb 2010 10:34:23 +0100 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100205093423.GA41873@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , "isms@ietf.org" , "'Joseph Salowey (jsalowey)'" , "syslog@ietf.org" References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "syslog@ietf.org" , "isms@ietf.org" , 'Wes Hardaker' Subject: Re: [Syslog] [Isms] syslog/dtls and snmp/dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 09:33:50 -0000 On Wed, Feb 03, 2010 at 10:37:38PM +0100, David Harrington wrote: > -- DoS -- > > syslog: > Implementations MUST support > the denial of service countermeasures defined by DTLS. When these > countermeasures are enabled, the transport receiver responds with a > DTLS Hello Verify Request containing a cookie. > snmp: > DTLS Transport > Model server implementations MUST support DTLS cookies. > > Implementations are not required to perform the stateless > cookie > exchange for every DTLS handshake, but in environments where an > overload on server side resources is detectable by the > implementation it is RECOMMENDED that the cookie exchange is > utilized by the implementation. > > My impression is that syslog allows an admin to enable this as a > deployment option; tlstm seems to depend on the implementation. (and I > have difficulty knowing how an implementation will know if overlaod on > server side is detectable, unless it is doing the detection itself.) > 1) Is enable/disable capability a MUST implement for DTLS cookie > exchange? > 2) Should tlstm recognize whether it is enabled/disabled? > 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in > syslog when the implementation can detect an overload on server > resources? > 4) in syslog, would it be better to specify the actions of the DTLS > entity rather than "the transport receiver"? Does the draft spell out > clearly whether the "transport receiver" is the DTLS client or DTLS > server? When a syslog entity can act as both sender and receiver, what > is that implementation REQUIRED to support in terms of DTLS client and > DTLS server? I didn't see that in the text prior to section 5.3.1; > should this be made clear in the terminology section? Should there be > mandatory-to-implement text about this? I suggest that some DTLS expert suggests text that is adequate. It seems to me that the ISMS text is better than the SYSLOG text but I am not too deeply involved in DTLS matters. > -- DCCP -- > > syslog/dtls supports the dccp transport: > As the Internet best runs on the basis of appropriate resource > sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this > document. For systems where DCCP is either not available or not > usable (such as the afformentioned situation), DTLS over UDP is > also > defined. In those circumstances where reliability or ordering is > important, SYSLOG over TLS is appropriate. Syslog over TLS does > not > provide application layer acknowledgements and therefore is not a > fully reliable solution. > and > DTLS can run over multiple transports. Implementations of this > specification MUST support DTLS over UDP and SHOULD support DTLS > over > DCCP [RFC5238]. > and > When TCP is used syslog over DTLS MUST NOT be used. If a secure > transport is required with TCP then the appropriate mechanism is > syslog over TLS. > > although we are discussing: > Based on some advice from Lars, I recommend > s/Implementations of this specification MUST support DTLS over UDP and > SHOULD support DTLS over DCCP [RFC5238]. / > Implementations of this specification MUST support both DTLS over UDP > and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but > implementations of this specification MUST be prepared to support DCCP > where it is available." > > I notice DCCP is not mentioned by TLSTM. > I'm not sure how much extra work it would take to add DCCP support to > snmp/dtls. Nobody ever asked for DCCP and I am reluctant to start new efforts to add DCCP support. SNMP runs over UDP for more than 20 years and for a single CG-CR transport, transactions are pretty much stop-and-wait (multi-threaded retrievals like those described in RFC 1187 never really took off because they spoil the caching on typical agents). SYSLOG is quite different here since it is fire-and-forget and as such a SYSLOG sender will never adapt to the speed of the network. In other words, unless Lars raises a flag that SNMP over UDP is not acceptable anymore after 20+ years of deployment, I am reluctant to add explicit text concerning DCCP. And if Lars successfully raises a flag that SNMP over UDP is not acceptable anymore, we do have a bigger problem to solve. > -- ports -- > > Since DTLS can run over DCCP, tlstm might want to define a domain for > that while you're at it (or not). The ISMS WG never asked for DCCP and unless the IESG requires us to add DCCP support, I do not think we need to do this. > -- cipher suites -- > > syslog: > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support > the > mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. > tsltm: > does not define a mandatory-to-implement cipher suite. > > Could this impact interoperability? I know this is one of those points > that keeps getting discussed. > 1) A mandatory-to-implement cipher suite ensures that different > implementations will have at least one suite that cna be used for > interoperability. > 2) But doesn't DTLS already define mandatory-to-implement cipher > suites? Do we need to do that here as well? Isn't it inherited from > DTLS? This was discussed in the ISMS WG and I think we concluded that the TLS specs define mandatory to implement cipher suites and that it is counter productive to have our own list since we want to pick up new mandatory cipher suites in case TLS specs move on because e.g. a cipher is broken. In short, it is the job of the TLS specs to define mandatory to implement ciphers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Fri Feb 5 06:58:14 2010 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 2FEBF3A6DC8; Fri, 5 Feb 2010 06:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 VA+g4XNROCbl; Fri, 5 Feb 2010 06:58:13 -0800 (PST) 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 5331B3A6C05; Fri, 5 Feb 2010 06:58:12 -0800 (PST) X-Trace: 236593456/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.10/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.10 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMGAD/Ba0s+vGkK/2dsb2JhbACCJoVViQHGaQyCRIICBA X-IronPort-AV: E=Sophos;i="4.49,413,1262563200"; d="scan'208";a="236593456" X-IP-Direction: IN Received: from 1cust10.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.10]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Feb 2010 14:58:59 +0000 Message-ID: <022b01caa66b$4bbd7760$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" , "David Harrington" References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> Date: Fri, 5 Feb 2010 14:56:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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@ietf.org, isms@ietf.org, 'Wes Hardaker' Subject: Re: [Syslog] [Isms] syslog/dtls and snmp/dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 14:58:14 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" Sent: Friday, February 05, 2010 10:34 AM > On Wed, Feb 03, 2010 at 10:37:38PM +0100, David Harrington wrote: > > > -- DoS -- > > > > syslog: > > Implementations MUST support > > the denial of service countermeasures defined by DTLS. When these > > countermeasures are enabled, the transport receiver responds with a > > DTLS Hello Verify Request containing a cookie. > > snmp: > > DTLS Transport > > Model server implementations MUST support DTLS cookies. > > > > Implementations are not required to perform the stateless > > cookie > > exchange for every DTLS handshake, but in environments where an > > overload on server side resources is detectable by the > > implementation it is RECOMMENDED that the cookie exchange is > > utilized by the implementation. > > > > My impression is that syslog allows an admin to enable this as a > > deployment option; tlstm seems to depend on the implementation. (and I > > have difficulty knowing how an implementation will know if overlaod on > > server side is detectable, unless it is doing the detection itself.) > > 1) Is enable/disable capability a MUST implement for DTLS cookie > > exchange? As Robert said, it is a SHOULD in RFC4347 which I think enough. > > 2) Should tlstm recognize whether it is enabled/disabled? > > 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in > > syslog when the implementation can detect an overload on server > > resources? see above > > 4) in syslog, would it be better to specify the actions of the DTLS > > entity rather than "the transport receiver"? No. SNMP subdivides the solution space into many more pieces, introducing EOPs, ASIs, etc in order to do so. syslog takes a much simpler view of what the implementer needs to be told, and I think there is no merit in subdividing the stack further. Once started, where do you stop? Adding tlstm section 5.5.1?:-) > > Does the draft spell out > > clearly whether the "transport receiver" is the DTLS client or DTLS > > server? syslog-dtls 5.2. Port Assignment A SYSLOG transport sender is always a DTLS client and a transport receiver is always a DTLS server. > > When a syslog entity can act as both sender and receiver, what > > is that implementation REQUIRED to support in terms of DTLS client and > > DTLS server? I didn't see that in the text prior to section 5.3.1; > > should this be made clear in the terminology section? Should there be > > mandatory-to-implement text about this? > > I suggest that some DTLS expert suggests text that is adequate. It > seems to me that the ISMS text is better than the SYSLOG text but I am > not too deeply involved in DTLS matters. > > > -- DCCP -- > > > > syslog/dtls supports the dccp transport: > > As the Internet best runs on the basis of appropriate resource > > sharing, SYSLOG over DTLS over DCCP [RFC5238] is defined in this > > document. For systems where DCCP is either not available or not > > usable (such as the afformentioned situation), DTLS over UDP is > > also > > defined. In those circumstances where reliability or ordering is > > important, SYSLOG over TLS is appropriate. Syslog over TLS does > > not > > provide application layer acknowledgements and therefore is not a > > fully reliable solution. > > and > > DTLS can run over multiple transports. Implementations of this > > specification MUST support DTLS over UDP and SHOULD support DTLS > > over > > DCCP [RFC5238]. > > and > > When TCP is used syslog over DTLS MUST NOT be used. If a secure > > transport is required with TCP then the appropriate mechanism is > > syslog over TLS. > > > > although we are discussing: > > Based on some advice from Lars, I recommend > > s/Implementations of this specification MUST support DTLS over UDP and > > SHOULD support DTLS over DCCP [RFC5238]. / > > Implementations of this specification MUST support both DTLS over UDP > > and DTLS over DCCP [RFC5238]. DCCP support itself is not a MUST, but To follow a sentence saying this is a MUST with one that says it is not does not seem like an improvement to me. > > implementations of this specification MUST be prepared to support DCCP > > where it is available." > > > > I notice DCCP is not mentioned by TLSTM. > > I'm not sure how much extra work it would take to add DCCP support to > > snmp/dtls. > > Nobody ever asked for DCCP and I am reluctant to start new efforts to > add DCCP support. SNMP runs over UDP for more than 20 years and for a > single CG-CR transport, transactions are pretty much stop-and-wait > (multi-threaded retrievals like those described in RFC 1187 never > really took off because they spoil the caching on typical > agents). SYSLOG is quite different here since it is fire-and-forget > and as such a SYSLOG sender will never adapt to the speed of the > network. In other words, unless Lars raises a flag that SNMP over UDP > is not acceptable anymore after 20+ years of deployment, I am > reluctant to add explicit text concerning DCCP. And if Lars > successfully raises a flag that SNMP over UDP is not acceptable > anymore, we do have a bigger problem to solve. agree > > -- ports -- > > > > Since DTLS can run over DCCP, tlstm might want to define a domain for > > that while you're at it (or not). > > The ISMS WG never asked for DCCP and unless the IESG requires us to > add DCCP support, I do not think we need to do this. > > > -- cipher suites -- > > > > syslog: > > Implementations MUST support DTLS 1.1 [RFC4347] and MUST support > > the > > mandatory to implement cipher suite, which is > > TLS_RSA_WITH_AES_128_CBC_SHA. > > tsltm: > > does not define a mandatory-to-implement cipher suite. > > > > Could this impact interoperability? I know this is one of those points > > that keeps getting discussed. > > 1) A mandatory-to-implement cipher suite ensures that different > > implementations will have at least one suite that cna be used for > > interoperability. > > 2) But doesn't DTLS already define mandatory-to-implement cipher > > suites? Do we need to do that here as well? Isn't it inherited from > > DTLS? > > This was discussed in the ISMS WG and I think we concluded that the > TLS specs define mandatory to implement cipher suites and that it is > counter productive to have our own list since we want to pick up new > mandatory cipher suites in case TLS specs move on because e.g. a > cipher is broken. In short, it is the job of the TLS specs to define > mandatory to implement ciphers. The counter argument is twofold. One is that the (D)TLS specs move on in a world of their own, probably leading edge and out of this world for many users thereof. Thus the recent discussions on renegotiation have highlighted how many people are using SSL and how many implementations do not conform to the enhancements introduced in TLS1.0 ie (a part of) the real world is 11 years behind the cryptographic experts. Including the current received wisdom gives a sanity check. Second, users have to go find it, they have to navigate their way through the RFC chain, understanding that RFC are never re-issued but may be superseded, so if they want the latest view, they need to consult and understand rfc-index. What I am hinting at here is that my experience of the syslog list is very different to that on eg OPSAWG or isms; the former has less of the IETF culture, more of people doing their own thing and needing a little steer in the right direction. I did survey the then current specs of application-over-TLS for this and found that some do, some don't, and that 'do' seemed right for syslog. Tom Petch > /js From Robert.Story@cobham.com Thu Feb 4 18:08:32 2010 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 CF2653A6BF0; Thu, 4 Feb 2010 18:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Xzwxrs2X5tQt; Thu, 4 Feb 2010 18:08:31 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id AD1293A6A5E; Thu, 4 Feb 2010 18:08:31 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o1529DRR024783; Thu, 4 Feb 2010 20:09:13 -0600 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o1529CXa030099; Thu, 4 Feb 2010 20:09:13 -0600 Received: from sparta.com ([190.234.20.253]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 21:09:12 -0500 Date: Thu, 4 Feb 2010 21:09:03 -0500 From: Robert Story To: "David Harrington" Message-ID: <20100204210903.329b595a@sparta.com> In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> Organization: SPARTA X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/R.u15V3AUgmoLwrMVHyvy4m"; protocol="application/pgp-signature" X-OriginalArrivalTime: 05 Feb 2010 02:09:12.0480 (UTC) FILETIME=[35B9D200:01CAA608] X-Mailman-Approved-At: Mon, 08 Feb 2010 09:56:16 -0800 Cc: syslog@ietf.org, isms@ietf.org, 'Wes Hardaker' Subject: Re: [Syslog] [Isms] syslog/dtls and snmp/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, 05 Feb 2010 02:08:33 -0000 --Sig_/R.u15V3AUgmoLwrMVHyvy4m Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 3 Feb 2010 16:37:38 -0500 David wrote: DH> syslog: DH> Implementations MUST support DH> the denial of service countermeasures defined by DTLS. When these DH> countermeasures are enabled, the transport receiver responds with a DH> DTLS Hello Verify Request containing a cookie. =20 DH> snmp: DH> DTLS Transport DH> Model server implementations MUST support DTLS cookies. DH>=20 DH> Implementations are not required to perform the stateless DH> cookie DH> exchange for every DTLS handshake, but in environments where an DH> overload on server side resources is detectable by the DH> implementation it is RECOMMENDED that the cookie exchange is DH> utilized by the implementation. DH>=20 DH> My impression is that syslog allows an admin to enable this as a DH> deployment option; tlstm seems to depend on the implementation. Hmm... DTLS says that cookies MUST be supported, so it seems like simply mentioning that admins can enabled it, as opposed to only RECOMMENDING it under special circumstances, would bring the two in line. DH> 1) Is enable/disable capability a MUST implement for DTLS cookie DH> exchange? Does syslog have this MUST, or simply a mention of 'when it is enabled' implying it is configurable? I agree that parity would be good, and it would be nice for it to be configurable. DH> Since DTLS can run over DCCP, tlstm might want to define a domain for DH> that while you're at it (or not). Couldn't hurt to add a domain and say implementations MAY support DCCP, but I don't think it's worth it if it's going to hold up the document. DH> Could this impact interoperability? I know this is one of those points DH> that keeps getting discussed.=20 DH> 1) A mandatory-to-implement cipher suite ensures that different DH> implementations will have at least one suite that cna be used for DH> interoperability.=20 DH> 2) But doesn't DTLS already define mandatory-to-implement cipher DH> suites? Do we need to do that here as well? Isn't it inherited from DH> DTLS? I vote for 2, that we inherit from DTLS... --=20 Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) --Sig_/R.u15V3AUgmoLwrMVHyvy4m Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEARECAAYFAktrfcIACgkQ7/fVLLY1mnh6hACgiRRcpS9SSps4asYAhBVPW9vk R/8An2GVtTrOBBoruD9HmS0cHd5lpj0r =bivQ -----END PGP SIGNATURE----- --Sig_/R.u15V3AUgmoLwrMVHyvy4m-- From jhutz@cmu.edu Fri Feb 5 21:17:58 2010 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 EB72B3A6914; Fri, 5 Feb 2010 21:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 RK0vPQ-Gz12Z; Fri, 5 Feb 2010 21:17:56 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 9341628C0D9; Fri, 5 Feb 2010 21:17:55 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o165IYO6021828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 00:18:35 -0500 (EST) Date: Sat, 06 Feb 2010 00:18:34 -0500 From: Jeffrey Hutzelman To: "tom.petch" , Juergen Schoenwaelder , David Harrington Message-ID: <4AD43B85C08C08969E7BB71E@MINBAR.FAC.CS.CMU.EDU> In-Reply-To: <23259_1265381948_o15Ex76K028706_022b01caa66b$4bbd7760$0601a8c0@allison> References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> <23259_1265381948_o15Ex76K028706_022b01caa66b$4bbd7760$0601a8c0@allison> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 X-Mailman-Approved-At: Mon, 08 Feb 2010 09:56:16 -0800 Cc: syslog@ietf.org, isms@ietf.org, jhutz@cmu.edu Subject: Re: [Syslog] [Isms] syslog/dtls and snmp/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: Sat, 06 Feb 2010 05:17:58 -0000 --On Friday, February 05, 2010 02:56:59 PM +0100 "tom.petch" wrote: >> Nobody ever asked for DCCP and I am reluctant to start new efforts to >> add DCCP support. SNMP runs over UDP for more than 20 years and for a >> single CG-CR transport, transactions are pretty much stop-and-wait >> (multi-threaded retrievals like those described in RFC 1187 never >> really took off because they spoil the caching on typical >> agents). SYSLOG is quite different here since it is fire-and-forget >> and as such a SYSLOG sender will never adapt to the speed of the >> network. In other words, unless Lars raises a flag that SNMP over UDP >> is not acceptable anymore after 20+ years of deployment, I am >> reluctant to add explicit text concerning DCCP. And if Lars >> successfully raises a flag that SNMP over UDP is not acceptable >> anymore, we do have a bigger problem to solve. > > agree As do I From wjhns1@hardakers.net Mon Feb 8 09:22:27 2010 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 002093A7247; Mon, 8 Feb 2010 09:22:26 -0800 (PST) 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 buBPDQsSCqq4; Mon, 8 Feb 2010 09:22:26 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id E79C23A720D; Mon, 8 Feb 2010 09:21:56 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 2AA4B980DB; Mon, 8 Feb 2010 09:21:49 -0800 (PST) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> Date: Mon, 08 Feb 2010 09:21:48 -0800 In-Reply-To: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 3 Feb 2010 16:37:38 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 08 Feb 2010 09:56:16 -0800 Cc: syslog@ietf.org, isms@ietf.org, 'Wes Hardaker' Subject: Re: [Syslog] syslog/dtls and snmp/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: Mon, 08 Feb 2010 17:22:27 -0000 >>>>> On Wed, 3 Feb 2010 16:37:38 -0500, "David Harrington" said: [cut to just the ISMS document's wording:] DH> DTLS Transport Model server implementations MUST support DTLS DH> cookies. DH> Implementations are not required to perform the stateless cookie DH> exchange for every DTLS handshake, but in environments where an DH> overload on server side resources is detectable by the DH> implementation it is RECOMMENDED that the cookie exchange is DH> utilized by the implementation. [And your comments:] DH> My impression is that syslog allows an admin to enable this as a DH> deployment option; tlstm seems to depend on the implementation. (and I DH> have difficulty knowing how an implementation will know if overlaod on DH> server side is detectable, unless it is doing the detection itself.) DH> Actually, we require it to be implemented but we're rather flexible on how it's actually used. Intentionally. I decided that there wouldn't be problems if different implementations did different things. Some implementations could have it configurable; others could do automatic detection, etc. So we certainly support the same case that syslog is doing, but we also allow implementations more flexibility. I don't believe this impacts interoperability of our base protocol. DH> 1) Is enable/disable capability a MUST implement for DTLS cookie DH> exchange? Not currently. DH> 2) Should tlstm recognize whether it is enabled/disabled? That's diving into protocol layers we said we wouldn't dive into. Specifically, I was requested not mention DTLS specific protocol message types in the document (like the syslog/DTLS document does). DH> 3) Would it be better to RECOMMEND or REQUIRE the cookie exchange in DH> syslog when the implementation can detect an overload on server DH> resources? Then that would prohibit an implementation from doing a runtime on/off/maybe setting. So personally, no, I don't see the need. But I also don't feel strongly about it. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Mon Feb 8 09:23:18 2010 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 57A2C28C156; Mon, 8 Feb 2010 09:23:18 -0800 (PST) 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 Cm725qfWbd-o; Mon, 8 Feb 2010 09:23:17 -0800 (PST) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BEBCC28C140; Mon, 8 Feb 2010 09:23:10 -0800 (PST) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id F210D9806D; Mon, 8 Feb 2010 09:23:18 -0800 (PST) From: Wes Hardaker To: David Harrington Organization: Sparta References: <024f01caa519$1bd2b680$0600a8c0@china.huawei.com> <20100205093423.GA41873@elstar.local> Date: Mon, 08 Feb 2010 09:23:18 -0800 In-Reply-To: <20100205093423.GA41873@elstar.local> (Juergen Schoenwaelder's message of "Fri, 5 Feb 2010 10:34:23 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 08 Feb 2010 09:56:16 -0800 Cc: "syslog@ietf.org" , "isms@ietf.org" , 'Wes Hardaker' Subject: Re: [Syslog] syslog/dtls and snmp/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: Mon, 08 Feb 2010 17:23:18 -0000 >>>>> On Fri, 5 Feb 2010 10:34:23 +0100, Juergen Schoenwaelder said: >> -- cipher suites -- JS> This was discussed in the ISMS WG and I think we concluded that the JS> TLS specs define mandatory to implement cipher suites and that it is JS> counter productive to have our own list since we want to pick up new JS> mandatory cipher suites in case TLS specs move on because e.g. a JS> cipher is broken. In short, it is the job of the TLS specs to define JS> mandatory to implement ciphers. I agree; that's my recollection too (and one I agree with). -- Wes Hardaker Cobham Analytic Solutions From cfinss@dial.pipex.com Sat Feb 13 11:08:00 2010 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 87A493A7740 for ; Sat, 13 Feb 2010 11:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 o81Xtjtq80Ia for ; Sat, 13 Feb 2010 11:07:59 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 76FE63A709E for ; Sat, 13 Feb 2010 11:07:59 -0800 (PST) X-Trace: 293410273/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.79/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.79 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQHAJqHdks+vGRP/2dsb2JhbACBeCyFKYk4iw+6UAyCOoIVBA X-IronPort-AV: E=Sophos;i="4.49,468,1262563200"; d="scan'208";a="293410273" X-IP-Direction: IN Received: from 1cust79.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.79]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Feb 2010 19:09:20 +0000 Message-ID: <001601caacd7$91d238e0$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , "syslog" References: <02a901caa5ae$b7b05680$0600a8c0@china.huawei.com> Date: Sat, 13 Feb 2010 19:07:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Subject: Re: [Syslog] Working Group Last Call: draft-ietf-syslog-dtls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2010 19:08:00 -0000 David I looked at boilerplates and this I-D does not conform to Guidelines to Authors of Internet-Drafts dated 9 February 2010. The copyright, " Copyright (c) YYYY IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." must precede the 'Internet-Draft Boilerplate' and note that there is an extra 'Simplified' in it compared with the I-D. And there is an additional /ietf/ in the very first URL in the I-D as it stands which is also now an .html and no longer a .txt. I am not sure what you are looking for with References; my experience is that xml2rfc does a better job than I ever do:-( But, as I have said before, 2914 and 5405 are no longer referenced in the body of the I-D. The references all exist and are not obsoleted and I agree with the division of Normative and Informative. Tom Petch ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, February 04, 2010 4:28 PM Subject: [Syslog] Working Group Last Call: draft-ietf-syslog-dtls > Hi, > > This message officially starts the Syslog Working Group Last Call for > the following document: > > Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog > http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-01.txt > > The Working Group Last Call for this document will end February 19. > > To help get this document reviewed throughly, we are seeking > volunteers to review the documents for the following special reviews: > 1) Spelling and grammar, > 2) boilerplates and reference review, > 3) security review > > The chairs want to see a minimum number of content reviews before we > submit the documents to the IESG. If you review the document and it > looks fine, please post a statement that you have reviewed and found > the document acceptable. Obviously, it if does not look acceptable > please identify your objections, preferably with suggested text that > would make it acceptable. > > Thanks, > David Harrington > dharrington@huawei.com > dbharrington@comcast.net > ietfdbh@comcast.net > co-chair, Syslog WG From ietfdbh@comcast.net Sun Feb 14 06:34:25 2010 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 4108328C0E7 for ; Sun, 14 Feb 2010 06:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 sAHRIgy4rZUc for ; Sun, 14 Feb 2010 06:34:24 -0800 (PST) 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 329D528C0E2 for ; Sun, 14 Feb 2010 06:34:23 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta10.westchester.pa.mail.comcast.net with comcast id hq2M1d0030Fqzac5AqbrYY; Sun, 14 Feb 2010 14:35:51 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta08.westchester.pa.mail.comcast.net with comcast id hqbr1d001284sdk3Uqbr3k; Sun, 14 Feb 2010 14:35:51 +0000 From: "David Harrington" To: "'tom.petch'" , "'syslog'" References: <02a901caa5ae$b7b05680$0600a8c0@china.huawei.com> <001601caacd7$91d238e0$0601a8c0@allison> Date: Sun, 14 Feb 2010 09:35:50 -0500 Message-ID: <0ac301caad83$0119ceb0$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 In-Reply-To: <001601caacd7$91d238e0$0601a8c0@allison> Thread-Index: Acqs4A8hWXawxz3BSYWLnAGi7MChfwAos5kw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Syslog] Working Group Last Call: draft-ietf-syslog-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: Sun, 14 Feb 2010 14:34:25 -0000 Thank you Tom, for doing this review of the references and boilerplate. Working group, we need more reviews, please. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Saturday, February 13, 2010 1:08 PM > To: David Harrington; syslog > Subject: Re: [Syslog] Working Group Last Call: draft-ietf-syslog-dtls > > David > > I looked at boilerplates and this I-D does not conform to > Guidelines to Authors of Internet-Drafts > dated 9 February 2010. > > The copyright, > " Copyright (c) YYYY IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with > respect to this document. Code Components extracted from this > document must include Simplified BSD License text as > described in > Section 4.e of the Trust Legal Provisions and are > provided without > warranty as described in the Simplified BSD License." > > must precede the 'Internet-Draft Boilerplate' and note that > there is an extra > 'Simplified' in it compared with the I-D. > > And there is an additional /ietf/ in the very first URL in > the I-D as it stands > which is also now an .html and no longer a .txt. > > I am not sure what you are looking for with References; my > experience is that > xml2rfc does a better job than I ever do:-( > > But, as I have said before, 2914 and 5405 are no longer > referenced in the body > of > the I-D. The references all exist and are not obsoleted and I > agree with the > division of Normative and Informative. > > Tom Petch > > > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, February 04, 2010 4:28 PM > Subject: [Syslog] Working Group Last Call: draft-ietf-syslog-dtls > > > > Hi, > > > > This message officially starts the Syslog Working Group > Last Call for > > the following document: > > > > Datagram Transport Layer Security (DTLS) Transport Mapping > for Syslog > > http://www.ietf.org/internet-drafts/draft-ietf-syslog-dtls-01.txt > > > > The Working Group Last Call for this document will end February 19. > > > > To help get this document reviewed throughly, we are seeking > > volunteers to review the documents for the following > special reviews: > > 1) Spelling and grammar, > > 2) boilerplates and reference review, > > 3) security review > > > > The chairs want to see a minimum number of content reviews before we > > submit the documents to the IESG. If you review the document and it > > looks fine, please post a statement that you have reviewed and found > > the document acceptable. Obviously, it if does not look acceptable > > please identify your objections, preferably with suggested text that > > would make it acceptable. > > > > Thanks, > > David Harrington > > dharrington@huawei.com > > dbharrington@comcast.net > > ietfdbh@comcast.net > > co-chair, Syslog WG > > From aokmians@cisco.com Fri Feb 19 14:15:31 2010 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 20EDC3A6F85 for ; Fri, 19 Feb 2010 14:15:31 -0800 (PST) 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 MtA8RCNxZsth for ; Fri, 19 Feb 2010 14:15:30 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 087023A7B77 for ; Fri, 19 Feb 2010 14:15:30 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACKdfkurR7H+/2dsb2JhbACbCXOmeJdxhGcEgxU X-IronPort-AV: E=Sophos;i="4.49,506,1262563200"; d="scan'208";a="485669358" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2010 22:15:13 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1JMFCoW015905 for ; Fri, 19 Feb 2010 22:15:13 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Feb 2010 16:15:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Feb 2010 16:15:07 -0600 Message-ID: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please review draft-ietf-syslog-dtls-01 thread-index: AcqxpCcomlhxtwQ7RNeNlVcnm583ygADG3Iw References: From: "Anton Okmyanskiy (aokmians)" To: X-OriginalArrivalTime: 19 Feb 2010 22:15:13.0231 (UTC) FILETIME=[01E0ADF0:01CAB1B1] Subject: [Syslog] Please review draft-ietf-syslog-dtls-01 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, 19 Feb 2010 22:15:31 -0000 Hi! Chris asked me to review this draft. Comments below.=20 Section 1 "DTLS has been mapped onto different transports (i.e. UDP [RFC0768] and DCCP [RFC4340] ), to secure syslog in more situations." AO: Remove " to secure syslog in more situation". This paragraph is giving a general overview of DTLS and it is independent of syslog. Otherwise, reader is confused into thinking that DTLS was mapped as described for the benefit of syslog.=20 "For systems where DCCP is either not available or not usable (such as the aforementioned situation)," AO: Don't see any "aforementioned situation" in text or don't get the reference. "In those circumstances where reliability or ordering is important, SYSLOG over TLS is appropriate." AO: This would be best moved to end of first paragraph where Syslog over TLS is introduced.=20 "Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution." AP: Same comment as above. This criticism leaves a question as to whether the newly defined mapping solves this problem. If not, it should be pointed out as a drawback of both mappings, not just TLS. Possibly, best addressed elsewhere in a Reliability section. Section 2 "A "DTLS client" is an application that can initiate a DTLS Client Hello to a server." AO: Further in the document we have... " The transport sender initiates a DTLS connection by sending a DTLS Client Hello to the transport receiver. "A SYSLOG transport sender is always a DTLS client and a transport receiver is always a DTLS server." AO: Why do we need 4 terms then? If they are equivalent, may be best to just add further description to transport sender/receiver and stick them? =20 Section 3 " The security requirements for Syslog are discussed in [RFC5425]." AO: Suggest changing to: " The security requirements for Syslog are discussed in Section 2 of [RFC5425] and apply to this transport mapping." Section 5.3.1 " The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data." AO: Which exact fields of the certificate? Surely not entire certificate. Maybe full DN + SubjectAltName + AuthorityKeyIdentifier? Section 5.4.1 The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. AO: SHOULD NOT or MUST NOT? When mapping onto different transports, DTLS has different record size limitations. AO: Can we mention limitations with UDP and DCCP here, so people don't have to dig and do the math on extra size header overhead? =20 Anton. From rfgraveman@gmail.com Fri Feb 19 21:06:47 2010 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 C08C63A8041 for ; Fri, 19 Feb 2010 21:06:47 -0800 (PST) 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 3pOKPmYwG85A for ; Fri, 19 Feb 2010 21:06:47 -0800 (PST) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id DF2783A7B0D for ; Fri, 19 Feb 2010 21:06:46 -0800 (PST) Received: by iwn29 with SMTP id 29so13733iwn.31 for ; Fri, 19 Feb 2010 21:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7FHMkzPZeVwNbX9aBIaImDOEHMZfuUqpaWh4fVtweL4=; b=Za/v1FcZgKER7pdmdTJLKq1bESu1SVh250MFlvMjpBAI/DX9NO6Vz/eNKMoojE1EDj KQ4fKqbyG6zg9A9zzxEO3TYy33fP3gzOy8PZgKz74R1TOdGVo1Mc/M+RTlLOZb0JT9HJ 05R3NafLkvLMWbOyk7u444KKwH2FtMkDw7RD0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=B0Z7UtV3IvcNwq8IBjacs6LfPyJcP5HLWRfJVGUBYiy4niSidc/Rdoek0gk1Y+d6Wx 3VNVM8EE0TSOkTIR2WeMm+tCBy5Ah5JEn8TxkFsjZCxN90AL7AbwaLyzcaReDd3cx/R2 Y0k19l3GNojRPjWHu2Ob4PbRS6+ToIhP8cR4I= MIME-Version: 1.0 Received: by 10.231.151.207 with SMTP id d15mr2129504ibw.44.1266642513384; Fri, 19 Feb 2010 21:08:33 -0800 (PST) In-Reply-To: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> Date: Sat, 20 Feb 2010 00:08:33 -0500 Message-ID: <45c8c21a1002192108y2a8a2036u2d45a5723728b727@mail.gmail.com> From: Richard Graveman To: syslog@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 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: Sat, 20 Feb 2010 05:06:47 -0000 > Chris asked me to review this draft. =A0Comments below. Likewise. Glad to look at it. Sorry for the lateness of these comments. I think the draft is in good shape, and, in view of the comments already posted, ready to go to the AD after one more pass. I have not followed this work, because the applications with which I am involved already implement RFCs 4301-4303-4306. These seem to me to provide all of the same security coverage, and there is reluctance to add another security suite. (Taking this another step, the same goes for syslog over TCP in my case.) Just a few comments: 1. RFC 5746 updates DTLS, so it is worth a normative reference. 2. Last week, at Fast Software Encryption, Xiaoyun Wang estimated that SHA-1 collisions would be found within one to two years, so perhaps one of the AES-based MACs or combined modes is a safer mandatory-to- implemement cipher suite. AES-without-SHA is also a smaller crypto- footprint for constrained devices. (Of course, collisions do not necessaril= y compromise HMACs, but ...) 3. The Introduction states that a high rate of lost packets is a reason for using UDP. It is also a reason for using TCP. 4. Do relays guarantee ordering? I thought timestamps (or syslog-sign) was all one had to go on. 5. In Section 5.1, paragraph 2, sentence 2, a word or two may be missing: " ... may not be able to assure ..."? 6. Then, also in 5.1: "When TCP is used syslog over DTLS MUST NOT be used." Well, I have not seen much discussion of this, but does anything say that I cannot use TCP for some syslog messages and UDP for others? 7. Why have pre-shared keys as an alternative to certificates been rejected? Richard Graveman RFG Security, LLC rfg@acm.org From j.schoenwaelder@jacobs-university.de Mon Feb 22 08:53:10 2010 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 D9DE13A8400 for ; Mon, 22 Feb 2010 08:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 07DrWow6fJfG for ; Mon, 22 Feb 2010 08:53:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 63CE03A8405 for ; Mon, 22 Feb 2010 08:53:09 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A2EFC0011 for ; Mon, 22 Feb 2010 17:55:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IcVr25B9rSkB; Mon, 22 Feb 2010 17:55:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02C41C0003; Mon, 22 Feb 2010 17:55:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4DC88108F6F4; Mon, 22 Feb 2010 17:54:48 +0100 (CET) Date: Mon, 22 Feb 2010 17:54:48 +0100 From: Juergen Schoenwaelder To: syslog@ietf.org Message-ID: <20100222165448.GB14118@elstar.local> Mail-Followup-To: syslog@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Syslog] js review of draft-ietf-syslog-dtls-01.txt X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 16:53:11 -0000 Hi, Chris Lonvick asked me to review draft-ietf-syslog-dtls-01 and here are my comments. I believe the document is not yet ready for the IESG and needs at least one update to improve on a number of details. For sake of simplicity, I will quote the relevant part of the ID and then comment it. The datagram transport layer security protocol (DTLS) [RFC4347] is designed to meet the requirements of applications that need secure datagram transport, by combining UDP transport with TLS security. DTLS has been mapped onto different transports (i.e. UDP [RFC0768] and DCCP [RFC4340] ), to secure syslog in more situations. I think ", to secure syslog in more situations" serves no value here. important, SYSLOG over TLS is appropriate. Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution. I do not understand why the last sentence is here. The purpose of this document should be to define SYSLOG over DTLS and not to discuss the properties of other SYSLOG transports. The term "connection" used in this document is used to refer to a secure association between transport sender and transport receiver that permits the transmission of one or more SYSLOG messages within the lifetime of the connection. Do we need this term "connection"? There is a potential for confusion, e.g. the abstract talks about "connection-less transport" and hence there are multiple meanings of "connection" in place. If we need the term, we should perhaps call it a "DTLS connection" and make sure we use the full term everywhere. Also "secure association between transport sender and transport receiver" can be anything secure, not particularly DTLS - was that the intention? Syslog messages are secured in a hop-by-hop manner. The security requirements for Syslog are discussed in [RFC5425]. I believe this is not quite right. Signed SYSLOG messages seem to provide end-to-end authentication, contradicting the first sentence. My reading of Section 3 of RFC 5425 (you might want to be explicit) is that it talks primarily about requirements for secure SYSLOG transports and not SYSLOG per se. TLS typically uses certificates [RFC5280] to authenticate peers. I am not sure why this sentence is there. I suggest to remove it. 5.3.1. Certificate-Based Authentication I suggest to either drop this headline or make this 5.4 instead of 5.3.1, flattening the structure of the document. But I have no strong opinion about this. OK, I just figured out it this document is following the structure of RFC 5425. Perhaps should should be mentioned somewhere explicitly (if that is a reasonable organization, which could also be discussed). Both transport receiver and transport sender implementations MUST provide 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. I do not know the idea behind this requirement is or how I comply to it. Is this expressing a requirement for the management interface of the box? Or is the idea that this is used in some automated fashion (which likely does not make sense but would be harmful if read this way). The transport receiver and transport sender SHOULD provide mechanisms to record the end-entity certificate for the purpose of correlating it with the sent or received data. What is an end-entity certificate? And how do I correlate sent or received data? The message length is the octet count of the SYSLOG-MSG in the SYSLOG-FRAME. A transport receiver MUST use the message length to delimit a syslog message. There is no upper limit for a message length per se. As stated in [RFC4347], each DTLS record must fit within a single DTLS datagram. When mapping onto different transports, DTLS has different record size limitations. The application implementer SHOULD determine the maximum record size allowed by DTLS protocol running over the transport in use. The message size SHOULD NOT exceed the DTLS maximum record size limitation of 2^14 bytes. The text in 5.4 said the following: [...] It is possible that multiple syslog messages be contained in one DTLS record, or that a syslog message be transferred in multiple DTLS records. This seems to be contradictory. If I can fragment a syslog message over multiple DTLS records, why should a message not exceed the DTLS maximum record size? So do we do fragmentation / reassembly of syslog messages, yes or no? If yes, perhaps some text should be added discussing the implications (delivery of DTLS records is not reliable). [...] Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify. Is it our job to define this? Does DTLS not specify how to handle such DTLS alerts? Syslog applications SHOULD be implemented in a manner that permits administrators, as a matter of local policy, to select the cryptographic level and authentication options they desire. What is "cryptographic level"? If this refers to the selection of crypto algorithms, isn't this implementation SHOULD generally true for crypto protocols and isn't DTLS designed to do this? Is it needed to spell this out here? [...] An exiting DTLS session MUST NOT be reused if its protection does not match the minimum policy requirements of the new SYSLOG over DTLS session request. I am not sure what "reuse" means here. Some more explanation is needed to understand this concept of reuse. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Tue Feb 23 07:02:05 2010 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 846353A83C0 for ; Tue, 23 Feb 2010 07:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 U2cv+gq5ncyG for ; Tue, 23 Feb 2010 07:02:04 -0800 (PST) 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 258E228C122 for ; Tue, 23 Feb 2010 07:02:04 -0800 (PST) X-Trace: 241770661/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.84/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.84 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAGAPl8g0s+vGlU/2dsb2JhbACBeIVUiRKLIL1WDYRfBA X-IronPort-AV: E=Sophos;i="4.49,526,1262563200"; d="scan'208";a="241770661" X-IP-Direction: IN Received: from 1cust84.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.84]) by smtp.pipex.tiscali.co.uk with SMTP; 23 Feb 2010 15:04:05 +0000 Message-ID: <001f01cab490$edc6cec0$0601a8c0@allison> From: "tom.petch" To: "Anton Okmyanskiy \(aokmians\)" , References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> Date: Tue, 23 Feb 2010 14:53:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:02:05 -0000 Hi Anton, inline Tom Petch ----- Original Message ----- From: "Anton Okmyanskiy (aokmians)" To: Sent: Friday, February 19, 2010 11:15 PM Subject: [Syslog] Please review draft-ietf-syslog-dtls-01 > Chris asked me to review this draft. Comments below. > > Section 1 > > "DTLS has been mapped onto different transports (i.e. UDP [RFC0768] and > DCCP [RFC4340] ), to secure syslog in more situations." > > AO: Remove " to secure syslog in more situation". This paragraph is > giving a general overview of DTLS and it is independent of syslog. > Otherwise, reader is confused into thinking that DTLS was mapped as > described for the benefit of syslog. What I find that phrase adds is a justification for syslog over DTLS to exist; it caters for situations where the TCP problems alluded to in the previous paragraph are an issue; perhaps rephrase it as "which makes it possible to secure applications such as syslog in a greater variety of situations". > "For systems where DCCP is either not available or not usable (such as > the aforementioned situation)," > > AO: Don't see any "aforementioned situation" in text or don't get the > reference. Again, I think that this harks back to para 2 which puts the case for UDP and implicitly against DCCP. > "In those circumstances where reliability or ordering is important, > SYSLOG over TLS is appropriate." > > AO: This would be best moved to end of first paragraph where Syslog over > TLS is introduced. Yup > "Syslog over TLS does not provide application layer acknowledgements and > therefore is not a fully reliable solution." > > AP: Same comment as above. This criticism leaves a question as to > whether the newly defined mapping solves this problem. If not, it should > be pointed out as a drawback of both mappings, not just TLS. Possibly, > best addressed elsewhere in a Reliability section. No, it does not change the application layer protocol, and this is a general weakness of TCP which seems not to be as well known as it might be and so should be included; perhaps the first paragraph is best. We have a delicate juggling act here, that syslog over TLS is the IESG-mandated solution, because it provides flow control, and so we cannot be too critical of it, yet need to criticise it in order to justify the existence of sylog over DTLS. > Section 2 > > "A "DTLS client" is an application that can initiate a DTLS Client Hello > to a server." > > AO: Further in the document we have... > > " The transport sender initiates a DTLS connection by sending a DTLS > Client Hello to the transport receiver. > > "A SYSLOG transport sender is always a DTLS client and a transport > receiver is always a DTLS server." > > AO: Why do we need 4 terms then? If they are equivalent, may be best > to just add further description to transport sender/receiver and stick > them? Bear in mind that RFC5424 prescribes a set of syslog terms that have nothing to do with (D)TLS and those should be used as is; we then need terms for the (D)TLSish things and I think that this is the minimum necessary. Who is client and who server is a big deal with (D)TLS and needs to be explicitly stated in application terms. > > Section 3 > > " The security requirements for Syslog are discussed in [RFC5425]." > > AO: Suggest changing to: " The security requirements for Syslog are > discussed in Section 2 of [RFC5425] and apply to this transport > mapping." Yup > Section 5.3.1 > > " The transport receiver and transport sender SHOULD provide > mechanisms > to record the end-entity certificate for the purpose of correlating > it with the sent or received data." > > AO: Which exact fields of the certificate? Surely not entire > certificate. Maybe full DN + SubjectAltName + AuthorityKeyIdentifier? I think that these are murky waters; something similar cropped up on the TLS list recently with the view that this is really a task for PKIX, even if they show no signs of wanting to take it on. Outside PKIX, I think that we should restrict ourselves to entire certificates (or to fingerprints thereof, when appropriate). > Section 5.4.1 > > The message size SHOULD NOT exceed the DTLS maximum record size > limitation of 2^14 bytes. > > AO: SHOULD NOT or MUST NOT? > > When mapping onto different transports, DTLS has different record size > limitations. > > AO: Can we mention limitations with UDP and DCCP here, so people don't > have to dig and do the math on extra size header overhead? Another murky water on which I will pass. tp > Anton. > From j.schoenwaelder@jacobs-university.de Tue Feb 23 07:44:31 2010 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 907C528C1BC for ; Tue, 23 Feb 2010 07:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 r9C7BrF7Wdvq for ; Tue, 23 Feb 2010 07:44:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 772C028C132 for ; Tue, 23 Feb 2010 07:44:30 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0912FC0028; Tue, 23 Feb 2010 16:46:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7mPY3LF1wvlt; Tue, 23 Feb 2010 16:46:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B322C0026; Tue, 23 Feb 2010 16:46:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 31D151092FA6; Tue, 23 Feb 2010 16:46:09 +0100 (CET) Date: Tue, 23 Feb 2010 16:46:09 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100223154609.GD17081@elstar.local> Mail-Followup-To: "tom.petch" , "Anton Okmyanskiy (aokmians)" , "syslog@ietf.org" References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> <001f01cab490$edc6cec0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01cab490$edc6cec0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "syslog@ietf.org" Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:44:31 -0000 On Tue, Feb 23, 2010 at 02:53:02PM +0100, tom.petch wrote: > We have a delicate juggling act here, that syslog over TLS is the > IESG-mandated solution, because it provides flow control, and so we > cannot be too critical of it, yet need to criticise it in order to > justify the existence of sylog over DTLS. You do not have to 'criticize' SYSLOG over TLS/TCP - there will be situations where there simply is no TCP, see 6lowpan et al. The best thing is to concentrate on defining how SYSLOG over DTLS works and to leave out any discussion about 'shortcomings' of TLS/TCP or how to choose the best SYSLOG transport for a given network for future documents. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From cfinss@dial.pipex.com Wed Feb 24 12:24:32 2010 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 334C228C176 for ; Wed, 24 Feb 2010 12:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.145, 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 KkXB8ytSzvEI for ; Wed, 24 Feb 2010 12:24:31 -0800 (PST) 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 E2A8128C133 for ; Wed, 24 Feb 2010 12:24:30 -0800 (PST) X-Trace: 242264664/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.103/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.103 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMHAKoahUs+vGln/2dsb2JhbACBeBaFQIkWiyCudgmNUQILglyCCQQ X-IronPort-AV: E=Sophos;i="4.49,534,1262563200"; d="scan'208";a="242264664" X-IP-Direction: IN Received: from 1cust103.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.103]) by smtp.pipex.tiscali.co.uk with SMTP; 24 Feb 2010 20:26:36 +0000 Message-ID: <000301cab587$258b9ec0$0601a8c0@allison> From: "tom.petch" To: "Juergen Schoenwaelder" References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> <001f01cab490$edc6cec0$0601a8c0@allison> <20100223154609.GD17081@elstar.local> Date: Wed, 24 Feb 2010 20:19:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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@ietf.org Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 20:24:32 -0000 ---- Original Message ----- From: "Juergen Schoenwaelder" To: "tom.petch" Cc: "Anton Okmyanskiy (aokmians)" ; Sent: Tuesday, February 23, 2010 4:46 PM Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 > On Tue, Feb 23, 2010 at 02:53:02PM +0100, tom.petch wrote: > > > We have a delicate juggling act here, that syslog over TLS is the > > IESG-mandated solution, because it provides flow control, and so we > > cannot be too critical of it, yet need to criticise it in order to > > justify the existence of sylog over DTLS. > > You do not have to 'criticize' SYSLOG over TLS/TCP - there will be > situations where there simply is no TCP, see 6lowpan et al. The best > thing is to concentrate on defining how SYSLOG over DTLS works and to > leave out any discussion about 'shortcomings' of TLS/TCP or how to > choose the best SYSLOG transport for a given network for future > documents. I see many I-Ds criticised for failing to say why they should exist. The limitations of TCP and the attractions of UDP justify this I-D so I regard those preliminary paragraphs as a necessary part of this I-D. Ir might be called an applicability statement. Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Feb 24 14:43:44 2010 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 BFCF53A85FE for ; Wed, 24 Feb 2010 14:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 PSt7opna3htu for ; Wed, 24 Feb 2010 14:43:43 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B41363A85FD for ; Wed, 24 Feb 2010 14:43:43 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D601C002A; Wed, 24 Feb 2010 23:45:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T-pw-BqKOrwv; Wed, 24 Feb 2010 23:45:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33F1BC0029; Wed, 24 Feb 2010 23:45:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96ECD1096F81; Wed, 24 Feb 2010 23:45:34 +0100 (CET) Date: Wed, 24 Feb 2010 23:45:34 +0100 From: Juergen Schoenwaelder To: "tom.petch" Message-ID: <20100224224534.GA25023@elstar.local> Mail-Followup-To: "tom.petch" , "Anton Okmyanskiy (aokmians)" , "syslog@ietf.org" References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com> <001f01cab490$edc6cec0$0601a8c0@allison> <20100223154609.GD17081@elstar.local> <000301cab587$258b9ec0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000301cab587$258b9ec0$0601a8c0@allison> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "syslog@ietf.org" Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 22:43:44 -0000 On Wed, Feb 24, 2010 at 08:19:31PM +0100, tom.petch wrote: > > You do not have to 'criticize' SYSLOG over TLS/TCP - there will be > > situations where there simply is no TCP, see 6lowpan et al. The best > > thing is to concentrate on defining how SYSLOG over DTLS works and to > > leave out any discussion about 'shortcomings' of TLS/TCP or how to > > choose the best SYSLOG transport for a given network for future > > documents. > > I see many I-Ds criticised for failing to say why they should exist. > The limitations of TCP and the attractions of UDP justify this I-D > so I regard those preliminary paragraphs as a necessary part of this > I-D. Ir might be called an applicability statement. Good luck with spelling out the "limitations of TCP" in a way that does not look hand waving and passes the reviews without triggering nasty questions. Leave the discussion which transport to choose in which situation to a future SYSLOG applicability statement document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Wed Feb 24 15:26:39 2010 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 08BD33A8328 for ; Wed, 24 Feb 2010 15:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pqtxHL5uRGZM for ; Wed, 24 Feb 2010 15:26:33 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D31CF3A6818 for ; Wed, 24 Feb 2010 15:26:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEZFhUurR7H+/2dsb2JhbACBQplRc6M8mEeEcgSDFg X-IronPort-AV: E=Sophos;i="4.49,535,1262563200"; d="scan'208,217";a="488084980" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 24 Feb 2010 23:28:41 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o1ONSeuB023517 for ; Wed, 24 Feb 2010 23:28:41 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 15:28:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAB5A9.19232420" Date: Wed, 24 Feb 2010 15:28:39 -0800 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB097A80FC@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments for draft-ietf-syslog-dtls Thread-Index: Acq1qRg8EmRcZ21WTFWpS4BggnTaYg== From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 24 Feb 2010 23:28:41.0035 (UTC) FILETIME=[1932F1B0:01CAB5A9] Subject: [Syslog] Review comments for draft-ietf-syslog-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: Wed, 24 Feb 2010 23:26:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAB5A9.19232420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Chris asked me as well to review draft-ietf-syslog-dtls. I agree with the overall sentiment that this draft is in good shape. Here are my comments: =20 =20 1.Editorial: "Syslog" or "SYSLOG" - should use consistent (non-)capitalization throughout. =20 =20 2. Introduction, last paragraph: This could use a little editorial wordsmithing: For one, "SYSLOG over DTLS over DCCP [RFC5238 ]" - is it clear where the parantheses are set? Might consider putting the reference into the previous paragraph ("DTLS has been mapped onto different transports"). Actually to that last sentence in the second-to-last-paragraph, is it true that DTLS was mapped onto different transports specifically just to secure syslog? This is what it sounds like. =20 =20 3. In addition, the Introduction also states:=20 "For systems where DCCP is either not available or not usable (such as the aforementioned situation), DTLS over UDP is also defined. " =20 At the same time, section 5.1 states: "Implementations of this specification MUST support DTLS over UDP" =20 So, the statement in the Introduction seems to be a bit misleading as it appears to imply that DTLS over UDP is optional, specifically as it seems to make the decision whether or not to implement it dependent just on what is suppoted on the system (and not end-to-end considerations). =20 =20 4. I am not sure about the purpose of the Introduction's last sentence. ("Syslog over TLS does not provide application layer acknowledgements and therefore is not a fully reliable solution.") If anything, this seems to belong into the second paragraph, where it talks about performance as an issue that is part of the motivation for a different transport. =20 =20 5. Section 5.1: the term "session" should be introduced. This is the first time the term occurs in the document. What is the relevance of a session in the context here? =20 =20 6. Section 5.1: Last paragraph, first sentence can use wordsmithing ("When TCP is used syslog over DTLS MUST NOT be used.") When TCP is used for what? Might better state that syslog over DTLS must only be used when DTLS does not use TCP. Actually, why is this prohibition there in the first place - is it simply not a good idea, or must it really be prohibited? =20 =20 7. Section 5.1, 2nd sentence: needs wordsmithing - for one, has-->have; is this really a single port? =20 =20 8. Section 5.4.1: I think there is a little potential for confusion regarding message length. I am assuming that message length refers to the length of the syslog message, per section 5.4. 5.4 also states that syslog messages do not have to align with DTLS records - allowing application data presumably to be fragmented across frames (as a syslog message is always contained as a whole within a syslog frame). However, in 5.4.1, it is also stated that "The message size SHOULD NOT exceed the DTLS maximum record size limitation". Why is that? (And, is "message size" the same as "(syslog) message length". =20 =20 Kind regards --- Alex =20 ------_=_NextPart_001_01CAB5A9.19232420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Chris asked me as well to review draft-ietf-syslog-dtls.  I agree with = the overall sentiment that this draft is in good shape.  Here are my = comments:

 

 

1.Editorial:&= nbsp; “Syslog” or “SYSLOG” – should use = consistent (non-)capitalization throughout. 

 

2. Introduction, last paragraph:  This could use a little editorial = wordsmithing:      For one, “SYSLOG over DTLS over DCCP [RFC5238]” – is it clear where the parantheses are set?  Might consider = putting the reference into the previous paragraph (“DTLS has been mapped = onto different transports”).  Actually to that last sentence in = the second-to-last-paragraph, is it true that DTLS was mapped onto different transports specifically just to secure syslog?  This is what it = sounds like. 

 

3. In addition, the =
Introduction also states: 
“For systems where DCCP =
is either not available or not

   = usable (such as the aforementioned situation), DTLS over UDP is = also

   defined. “ 

At the same time, section 5.1 states:

“Implementations of =
this

   specification MUST support DTLS over UDP”

 

So, the statement in the Introduction seems to be a bit misleading as it = appears to imply that DTLS over UDP is optional, specifically as it seems to make = the decision whether or not to implement it dependent just on what is = suppoted on the system (and not end-to-end considerations).  =

 

4. I am not sure about the =
purpose of the Introduction’s last sentence. (“Syslog over TLS does =
not
   provide application layer =
acknowledgements and therefore is not a
   fully reliable =
solution.”)  If anything, =
this seems to belong into the second paragraph, where it talks about =
performance as an issue that is part of the motivation for a different =
transport.  
 
= 
5. Section 5.1: the term =
“session” should be introduced.  This is the first time =
the term occurs in the document.  What is the relevance of a =
session in the context here?  
 
= 
6. Section 5.1: Last =
paragraph, first sentence can use wordsmithing (“When TCP is used syslog over DTLS =
MUST NOT be used.”)  When TCP is =
used for what?  Might better state that syslog over DTLS must only =
be used when DTLS does not use TCP.  Actually, why is this =
prohibition there in the first place – is it simply not a good =
idea, or must it really be prohibited?  =

 
= 
7. Section 5.1, =
2nd sentence: needs wordsmithing – for one, =
has-->have; is this really a single port?  =

 
= 
8. Section 5.4.1: I think =
there is a little potential for confusion regarding message =
length.  I am assuming that message length refers to the length of =
the syslog message, per section 5.4.  5.4 also states that syslog =
messages do not have to align with DTLS records – allowing =
application data presumably to be fragmented across frames (as a syslog =
message is always contained as a whole within a syslog frame).  =
However, in 5.4.1, it is also stated that “The message size SHOULD =
NOT exceed the DTLS maximum record size limitation”.  Why is =
that?  (And, is “message size” the same as =
“(syslog) message length”.  =

 
= 
Kind =
regards
--- Alex

 

------_=_NextPart_001_01CAB5A9.19232420-- From ietfdbh@comcast.net Thu Feb 25 06:47:16 2010 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 807DA28C183 for ; Thu, 25 Feb 2010 06:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 KLVj8P0l9iIx for ; Thu, 25 Feb 2010 06:47:15 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 4607728C0E9 for ; Thu, 25 Feb 2010 06:47:15 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA11.westchester.pa.mail.comcast.net with comcast id mEX71d0071GhbT85BEpTPB; Thu, 25 Feb 2010 14:49:27 +0000 Received: from Harrington73653 ([24.147.240.98]) by omta07.westchester.pa.mail.comcast.net with comcast id mEpS1d008284sdk3TEpSoB; Thu, 25 Feb 2010 14:49:26 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'tom.petch'" References: <55A6113CC564224086CF0B067CC21C67DC256D@XMB-RCD-113.cisco.com><001f01cab490$edc6cec0$0601a8c0@allison><20100223154609.GD17081@elstar.local><000301cab587$258b9ec0$0601a8c0@allison> <20100224224534.GA25023@elstar.local> Date: Thu, 25 Feb 2010 09:49:25 -0500 Message-ID: <172601cab629$b9bce840$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 In-Reply-To: <20100224224534.GA25023@elstar.local> Thread-Index: Acq1oyDqFL9Xc3vITuyLmD3vgWG3IgAhCFwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: syslog@ietf.org Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 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: Thu, 25 Feb 2010 14:47:16 -0000 Hi, (chair hat ON) 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. Our job is to define a DTLS transport for syslog. I don't interpret the charter as saying we need to show why TCP is inadequate. syslog/tls is mandatory-to-implement. syslog/dtls is not. Syslog/dtls is being designed for cases where a connection-less transport is desired. We provide the specification of how to do so in a standardized manner. (chair hat OFF) Applicability is an operational/deployment decision. It might be good to state that in the document. I would be fine with a statement that says syslog/dtls SHOULD be used when the operational environment demands a secure connection-less transport, but syslog/tls SHOULD be used in normal operating environments for purposes of interoperability. dbh > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Wednesday, February 24, 2010 5:46 PM > To: tom.petch > Cc: syslog@ietf.org > Subject: Re: [Syslog] Please review draft-ietf-syslog-dtls-01 > > On Wed, Feb 24, 2010 at 08:19:31PM +0100, tom.petch wrote: > > > > You do not have to 'criticize' SYSLOG over TLS/TCP - there will be > > > situations where there simply is no TCP, see 6lowpan et > al. The best > > > thing is to concentrate on defining how SYSLOG over DTLS > works and to > > > leave out any discussion about 'shortcomings' of TLS/TCP or how to > > > choose the best SYSLOG transport for a given network for future > > > documents. > > > > I see many I-Ds criticised for failing to say why they should exist. > > The limitations of TCP and the attractions of UDP justify this I-D > > so I regard those preliminary paragraphs as a necessary part of this > > I-D. Ir might be called an applicability statement. > > Good luck with spelling out the "limitations of TCP" in a way that > does not look hand waving and passes the reviews without triggering > nasty questions. Leave the discussion which transport to choose in > which situation to a future SYSLOG applicability statement document. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog >