[netmod] Kathleen Moriarty's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Fri, 02 March 2018 20:09 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFB6126C25; Fri, 2 Mar 2018 12:09:10 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netmod-syslog-model@ietf.org, Lou Berger <lberger@labn.net>, Kent Watsen <kwatsen@juniper.net>, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.73.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152002135016.15735.729698942100498119.idtracker@ietfa.amsl.com>
Date: Fri, 02 Mar 2018 12:09:10 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/DNSjk6x_TgwqUT8TE_ezgKyHCos>
Subject: [netmod] Kathleen Moriarty's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Mar 2018 20:09:10 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with the SecDir review and thanks for responding to the review.  I have
one additional suggestion to make sure the points made from this review are
clear to the reader.  Thanks in advance!

SecDir Review text & response:
    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.

[clw1] I will reword the security section to include all writeable nodes as
sensitive. [KMM]  Thank you, I think it would be helpful to also note the
reason is this case with an extra sentence or two.

Something to the effect of:
Logging in particular is used to assess the state of systems and can be used to
indicate a network compromise.  If logging were to be disabled through
malicious means, attacks may not be readily detectable.

    * 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.

[clw1] This text was lifted from another model. I will review the readable
nodes and update. [KMM] Thanks

    * 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.

[clw1] I will add this phrase.

[KMM] I see this was added, thanks.  Please consider the above 2 sentences.

    * 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.

[clw1] I will add this advice.

[KMM] Thanks for adding this advice.