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

"Clyde Wildes (cwildes)" <cwildes@cisco.com> Mon, 19 February 2018 21:02 UTC

Return-Path: <cwildes@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B28124E15; Mon, 19 Feb 2018 13:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.512
X-Spam-Level:
X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfyTvtP0Cy22; Mon, 19 Feb 2018 13:02:35 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80EC1200B9; Mon, 19 Feb 2018 13:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4928; q=dns/txt; s=iport; t=1519074155; x=1520283755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/yCfbAmTmkbCAKl83ZW8xBGkSK+deaNnrcZfYRHn+J0=; b=ZiiXr73ozCsdv9Z2Gboji8daUev0+e2ELp1nFzwfTWbxqVDI0K8AL8zh 4tOvJEuf5xQ51moGQxWJr9gncord3RjELof+E+fvqZNR9EqOb7WZKUy+S LbJ6/Ek1XexLGbYBJZmEyEw39tYPpwwCc4iDqwGXNIMbfXpKlnNp2YOHb w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAADTOota/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCoNdiiWOBIMZh3+OSoIWCiWFFgIagkFUGAECAQEBAQE?= =?us-ascii?q?BAmsohSQGIxFFEAIBCBoCJgICAh8RFRACBAENBYoKAxUQtm2CJ4c6DYEyghMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg3gEgiiBV4FoKYMFgmxEAoFbFoMXMYI?= =?us-ascii?q?0BZJSkS41CQKIIohbhQuCIJInixaCcEiJJAIRGQGBOwEfOYFRcBVkAYIYhHZ4j?= =?us-ascii?q?EqBGQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,536,1511827200"; d="scan'208";a="72968250"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 21:02:34 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1JL2Yvl009232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Feb 2018 21:02:34 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 15:02:26 -0600
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 15:02:26 -0600
From: "Clyde Wildes (cwildes)" <cwildes@cisco.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-netmod-syslog-model.all@ietf.org" <draft-ietf-netmod-syslog-model.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Secdir last call review of draft-ietf-netmod-syslog-model-21
Thread-Index: AQHTqMUZsEq/edddJ0uDZKwhfsdUyqOsnO2A
Date: Mon, 19 Feb 2018 21:02:26 +0000
Message-ID: <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com>
References: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
In-Reply-To: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2C52E5A62AB9A447BD783A3B7E4DA356@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jVo2z_R0ccGqFG4ZTQtW6bMfxJA>
Subject: Re: [secdir] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Mon, 19 Feb 2018 21:02:37 -0000

Yaron,

Thanks for your review. My answers are inline as [clw1].

On 2/18/18, 6:31 AM, "Yaron Sheffer" <yaronf.ietf@gmail.com>; wrote:

    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? *
    
[clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on the regex pattern; 3. Match on both facility/severity and the regex pattern.

    It's very confusing to specify rollover in minutes, but retention in hours.
    People are bound to get this one wrong.

[clw1] I will change the retention to minutes unless others object.

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

[clw1] You are correct. I will modify the description to make this clearer. How about:

"This leaf sets the source interface to be used to send messages to the remote syslog server. If
not set, messages can be sent on any interface."

    * Usage examples: the second example lists a
    specific IPv6 address, but the Yang snippet shows a domain name. 

[clw1] Thanks for catching this error. I will fix this in the next revision.

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

[clw1] It is standard practice to include the model in the RFC AFAIK. I have not seen github links published in any other RFCs.
    
    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.

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

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

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

Thanks,

Clyde