Re: [secdir] SECDIR review of draft-ietf-eman-framework-07

Benoit Claise <bclaise@cisco.com> Mon, 03 March 2014 17:42 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885FF1A0313; Mon, 3 Mar 2014 09:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.048
X-Spam-Level:
X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ZVeNkU0BwdZM; Mon, 3 Mar 2014 09:42:38 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9A1A0312; Mon, 3 Mar 2014 09:42:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3420; q=dns/txt; s=iport; t=1393868555; x=1395078155; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=2rMa2rs9I0jlISm9Sgfv9BucZxWrx/cxrdcIrMD2rhU=; b=KBNaLJPCBe7zqWDo4e5/uuunKp5PF/mDyXDB6ArJN9pB/K3XGcZ6hc8k 2W8yji9PIZlFdcCxvEW+q0fEwpjs4EXW0y2LUyNUsPpQj2ZXAfz/BOGdK x+BggH7NaCHM3tS6oXMCMfXwIKJsZe7EVRqObmCWLqhcStrMfgy0/ZtAt I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAOG+FFOQ/khN/2dsb2JhbABagwbBZIEkFnSCJgEBBDhAEQsOExYPCQMCAQIBRQYBDAgBARCHZcw6F44LVYQ4AQOYPIZKi2GDLTw
X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="2219650"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-3.cisco.com with ESMTP; 03 Mar 2014 17:42:34 +0000
Received: from [10.61.192.27] ([10.61.192.27]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s23HgXK4011782; Mon, 3 Mar 2014 17:42:33 GMT
Message-ID: <5314BF09.9020001@cisco.com>
Date: Mon, 03 Mar 2014 17:42:33 +0000
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, "<secdir@ietf.org>" <secdir@ietf.org>, "<iesg@ietf.org> IESG" <iesg@ietf.org>, "draft-ietf-eman-framework.all@tools.ietf.org" <draft-ietf-eman-framework.all@tools.ietf.org>
References: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com>
In-Reply-To: <523EEFE5-315C-4A49-B802-1F7C31B7ADD9@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0pPybIz7HGHL9OdeZmfhf3Bm3Is
Subject: Re: [secdir] SECDIR review of draft-ietf-eman-framework-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Mar 2014 17:42:40 -0000

Hi Yoav,

Thanks for your review.
Unfortunately, you have reviewed version 7 and we're now at version 15.
However, some of your comments were still applicable.
See in-line.
> 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 last call comments.
>
> Although I am reviewing this for SECDIR, I have to begin with some editorial remarks. I don't know what tool was used, but it's producing a very ill-formatted draft. It's true that the RFC editor staff will get it right, but it is apparent that this is a combination of several sources. See for example section 2 for a jarring mixture of line lengths.  Or the broken-in-half artwork of Figure 1 at the bottom of page 14. When you do that, someone (that's the RFC editor) has to put your diagrams back together, an error-prone process that should be done by the authors.
>
> The middle of section 1 has a paragraph whose entire text is "Energy Management Documents Overview". Was this supposed to be the title to a subsection?
>
> The document also contains some parts that are supposed to be removed before publication, for example the URL to the issue tracker. Please add a label like "RFC EDITOR NOTE: REMOVE THE FOLLOWING PARAGRAPH" before this. They know to look for it, and we don't end up with things we didn't want in the draft.
>
> Speaking of issues, I followed that URL, and found that it is showing three open issues. Are these resolved?
>
> I confess to being totally ignorant of the subject matter, but reading through this I noticed something that surprised me. In section 3.1 there is this paragraph:
>          A simple device such as a light bulb can be switched on or off
>          only by switching its power supply.  More complex devices may
>          have the ability to switch off themselves or to bring
>          themselves to states in which they consume very little power.
> Is the "may" here appropriate? Don't these complex devices *require* that they switch themselves off rather than have their power switched off?
changed "may" to "will" to all cases.
>
> Finally, the security considerations section. The most important recommendation there is to use SNMPv3, because it includes authentication and privacy, unlike earlier versions. I agree with the recommendation, but it should be noted that authentication was part of SNMPv1 as well, although different mechanisms (not based on community strings) were only added in SNMPv3. "Privacy" is a loaded term with multiple meanings. In SNMP privacy simply means confidentiality, and it's preferable to use that term rather than "privacy" which today is no longer used interchangeably with confidentiality.
changed.

Version 16, addressing your comments, will be posted shortly.

Regards, Benoit
>
> The section does an OK job of enumerating the risks, but IMO downplays them. For example, "Unauthorized changes to the Energy Management Domain or business context of an Energy Object may result in misreporting or interruption of power."  There's no "may" about it. If an attacker can modify the energy management domain, then they can at least shut down the network.
>
> Yoav
>
>
>
>
> .
>