[Syslog] secdir review of draft-ietf-syslog-dtls-05 (fwd)

Chris Lonvick <clonvick@cisco.com> Sat, 19 June 2010 03:35 UTC

Return-Path: <clonvick@cisco.com>
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 1AAA23A6874 for <syslog@core3.amsl.com>; Fri, 18 Jun 2010 20:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.127
X-Spam-Level:
X-Spam-Status: No, score=-9.127 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_05=-1.11, 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 7wbfPc-L4v1L for <syslog@core3.amsl.com>; Fri, 18 Jun 2010 20:35:31 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 267373A6873 for <syslog@ietf.org>; Fri, 18 Jun 2010 20:35:31 -0700 (PDT)
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: AjoFAP7XG0yrR7Hu/2dsb2JhbACScQGMJHGoCJoshRsEg1Q
X-IronPort-AV: E=Sophos;i="4.53,442,1272844800"; d="scan'208";a="547209216"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Jun 2010 03:35:37 +0000
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5J3ZbkX026518 for <syslog@ietf.org>; Sat, 19 Jun 2010 03:35:37 GMT
Date: Fri, 18 Jun 2010 20:35:36 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: syslog@ietf.org
Message-ID: <Pine.GSO.4.63.1006181701590.13308@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [Syslog] secdir review of draft-ietf-syslog-dtls-05 (fwd)
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Jun 2010 03:35:32 -0000

Hi Folks,

This one slipped past me.  :-(

Don't comment on this as I'm going to open up three additional issues 
which I think will be easy to resolve.

Thanks,
Chris


-----Original Message-----
From: Stephen Hanna [mailto:shanna@juniper.net]
Sent: Monday, May 17, 2010 6:13 PM
To: draft-ietf-syslog-dtls.all@tools.ietf.org
Cc: secdir@ietf.org; iesg@ietf.org
Subject: secdir review of draft-ietf-syslog-dtls-05

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other comments.

This document defines a DTLS transport for syslog. The document is
well-written, clear, and seems to serve a worthwhile purpose.

Although the security considerations section is brief (mainly just
referring to the security considerations in RFC 5425, RFC 5246,
and RFC 4347), it is largely adequate. I see only one omission.

One difference between the security considerations for syslog over
DTLS and those for syslog over TLS (unnoted in the current Security
Considerations section) is that DTLS does not provide retransmission.
If an attacker can cause a packet to be dropped (especially one
carrying significant information about an attack), the transport
receiver may not consider this a significant event and so the syslog
server may be completely unaware of the occurrence. This contrasts
with syslog over TLS where a dropped packet would be retransmitted
until acknowledged or until the TLS connection goes down (indicating
to the transport sender and receiver and perhaps to the syslog client
and server that a significant event has occurred). Maybe it would be
a good idea to recommend that the transport receiver notice gaps in
the DTLS sequence numbers and notify the syslog server. Still, this
is not as good from a security standpoint as syslog over TLS since
none of the client code will be aware that the dropped message was
not received. At least, there should be a discussion of this issue
in the Security Considerations section of this document.

In addition to this concern, I have noticed a few areas that could
use some clarification and maybe some fixes.

Section 5.3 says "Implementations MUST support the denial of service
countermeasures defined by DTLS." That's good but it's not clear
whether this means that these countermeasures MUST always be enabled.
Since that is not explicitly stated, it seems that a server could
have those countermeasures enabled by default and a client could
have them disabled by default. That would result in a client and
server that would not interoperate until the administrator tracked
down the problem and changed their configuration. I suggest that
the document be changed to require not only that implementations
support these countermeasures but that they be enabled by default.

Section 7 says "The security policies for syslog over DTLS are the
same as those described in [RFC5425]." Does that mean that all the
normative text in section 5 of RFC 5425 applies to implementations
of this document as well? I hope so but if that's the intent, it
should be explicitly stated (for example by adding the text "and
all the normative requirements of section 5 of [RFC5425] apply").

Once these issues are addressed, I'm sure that the document will
be a worthwhile and relatively secure addition to the RFC series.
Congratulations and thanks to the editors/authors for their work.

Thanks,

Steve