[secdir] Secdir last call review of draft-ietf-netmod-syslog-model-21

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 18 February 2018 14:30 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736DF124BE8; Sun, 18 Feb 2018 06:30:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: secdir@ietf.org
Cc: draft-ietf-netmod-syslog-model.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
Date: Sun, 18 Feb 2018 06:30:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/drsKnWVR5gz9_67eAxQr_CChT20>
Subject: [secdir] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Feb 2018 14:30:57 -0000

Reviewer: Yaron Sheffer
Review result: Has Issues

General Comments

* The semantics of pattern matching is not clear: "and/or the message text" -
are there cases where you only match the text but not the facility/severity? *
It's very confusing to specify rollover in minutes, but retention in hours.
People are bound to get this one wrong. * Interface selection: the feature
makes sense, but I think the description is incorrect. "This leaf sets the
source interface to be used to send messages to the remote syslog server. If
not set, messages sent to a remote syslog server will contain the IP address of
the interface the syslog message uses to exit the network element". AFAIK the
source IP will always correspond to the interface, but this feature allows you
to select a particular one. * Usage examples: the second example lists a
specific IPv6 address, but the Yang snippet shows a domain name. * A generic
question (I am new to the Yang ecosystem): I understand most implementers will
use this module from
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
- is this the expectation? If so, why not add a link from the RFC into the
repo, to make it easier for people to find?

Security Comments

* I think almost all writable data nodes here are sensitive, because a network
attacker's first move is to block any logging on the host, and many of the data
nodes here can be used for this purpose. * Re: readable data nodes, I'm not
sure which are sensitive, and the document should give an example or two rather
than just say "some". Otherwise the security advice is not actionable. One
example: "remote" sections leak information about other hosts in the network. *
Write operations... can have a negative effect on network operations. - I would
add "and on network security", because logs are often used to detect security
breaches. * Also add an advice, similar to the one on "pattern match", that the
private key used for signing log messages MUST NOT be used for any other
purpose, and that the implementation of this data node must ensure this
property (I'm not sure how). The rationale: if the TLS private key is used, for
example, this could result in a signing oracle for TLS and eventually a MITM
attack.