Re: [mile] Working Group Last Call for IODEF Guidance

Roman Danyliw <rdd@cert.org> Wed, 19 April 2017 19:14 UTC

Return-Path: <rdd@cert.org>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DDC128DF6 for <mile@ietfa.amsl.com>; Wed, 19 Apr 2017 12:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 gIXtyDMXVGyz for <mile@ietfa.amsl.com>; Wed, 19 Apr 2017 12:14:37 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E8F12945A for <mile@ietf.org>; Wed, 19 Apr 2017 12:14:37 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v3JJEY7m017044 for <mile@ietf.org>; Wed, 19 Apr 2017 15:14:34 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu v3JJEY7m017044
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1492629274; bh=OmJJH4lneRnqMqheMrgQXyv6tnuZ4M+/naIyY66KYCk=; h=From:To:Subject:Date:References:In-Reply-To:From; b=lUCDf8M+4epWfvyqRb+uCUg9wsSDBB4xSp0aVSzzCtVP+r5pIsryEYMtKsZjT1oCE WYCF2dEJfFIQdDcro6yAxlu5HPierd7jiQ+WOef2EpfgRgPWArGWQgeM0pBEhTPKuP yUnV4AHY+syyyTlq0olsP2pq9Dit/UtPMOrZoSfU=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id v3JJETdx014770 for <mile@ietf.org>; Wed, 19 Apr 2017 15:14:29 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0319.002; Wed, 19 Apr 2017 15:14:29 -0400
From: Roman Danyliw <rdd@cert.org>
To: "mile@ietf.org" <mile@ietf.org>
Thread-Topic: Working Group Last Call for IODEF Guidance
Thread-Index: AQHSqBsdzaOykKabgkq+aGKpuqOHZKHNMMpQ
Date: Wed, 19 Apr 2017 19:14:28 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC0104F3CD58@marathon>
References: <7CE030B4-2629-4333-AEBA-3305D90FBBD0@cisco.com>
In-Reply-To: <7CE030B4-2629-4333-AEBA-3305D90FBBD0@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC0104F3CD58marathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mile/SVefLbbVbteuOLYqEqbQlhBBlLg>
Subject: Re: [mile] Working Group Last Call for IODEF Guidance
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 19:14:40 -0000

Hello!

Here are a few suggestions from reviewing draft-ietf-mile-iodef-guidance-09.

(1) Results of XML validation on all XML examples and snippets:
** The second xml snippet in Appendix A is missing the HashData@scope attribute.  Replace both instances of '<HashData>' with '<HashData scope="file-contents">'.
** All the examples in Appendix B #1 - 5 are valid XML

(2) The abstract notes IODEF v2 [RFC7970]; but Section 2 and 6 note [RFC5070] and [RFC7970].  This raised confusion for me on which version of IODEF this draft is providing implementation guidance?  The provided examples and Section 3.1 are [RFC7970] specific.

(3) Section 3.1.  This write-up is a bit imprecise.  The parent IODEF-Document technically needs an Incident class (as noted), a version attributed (as noted), but also an xml:lang attributed (not referenced).

(4) Section 3.3, page 5, "An IndicatorData class depicts a threat indicator ... to describe ... that an exploit happened".  I'd recommend replacing 'exploit' with a 'successful attack'.  IndicatorData is shared as a watch-and-warning product for an event that did occur or not.  The use of an exploit doesn't seem material.

(5) Section 4, page 6, The sentence "When defining the IODEF use strategy practitioners need to ..." doesn't parse.  Perhaps, "IODEF implementers need to ..."

(6) Section 4.1, page 6.  I don't understand the recommendation made by the sentence, "Practitioners SHOULD only support external enumerations that are expected to be used in IODEF documents for their use-cases."

(7) Section 4.1, page 6. I'd recommend updating the sentence 'The Enumeration Reference Format specifies a format to ..." with 'The Enumeration Reference Format specifies a means to use external enumeration specifications that could define an enumeration format, specific enumeration values, or both".

(8) Section 4.2, page 6.  I'd recommend updating the sentence "Many class attributes and their values can be extended using the "ext-*" prefix." to "Many attributes with enumerated values can be extended using ...".

(9) Section 4.4, page 7. Include a reference to RFC6545 and expand the acronym RID given that this is the first reference to RID in the document.

(10) Section 4.4, page 7.  I'd recommend updating the sentence "The enforcement of the disclosure guidelines goes beyond IODEF." with "The enforcement of the disclosure guidelines is out of scope for IODEF".
(11) Section 5.1, page 7. and Section 5.3, page 11, s/CERT/Computer Security Incident Response Teams/.

(12) Section 5.2, page 8.  The opening sentence, "Various vendors organized and executed an exercise where multiple threat indicators were exchanged using IODEF" left me wanting a deeper explanation of the background on this section.  What exercise?  what vendors?  When?  Is this section an implementation report?

(12) Section 5.2, page 8.  I'm confused by the intent of this section.  It reads like an implementation report more suitable for draft-ietf-mile-implementreport-10.

(13) Section 5.2, page 8. Typo.  I'd recommend updating the text "The threat information shared included incidents like DDoS attacks.  Malware and Spear-Phishing" to read as follows: "The threat information shared included indicators from DDoS attacks; and Malware and Spear-Phishing incidents".

(14) Section 5.3, page 11.  I'm confused by the title of this section.  "*More* use cases".  The 'more' suggests that other use cases were explicitly enumerated elsewhere.

(15) Section 5.3, page 11.  Additional use cases could include “Satisfying regulatory or statutory requirements for incident reporting”

(16) Globally.  Replace "practitioners' with 'implementers'.

Roman

From: mile [mailto:mile-bounces@ietf.org] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, March 28, 2017 7:29 PM
To: mile@ietf.org
Subject: [mile] Working Group Last Call for IODEF Guidance

Colleagues,

We are doing another WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-mile-iodef-guidance

Please provide comments before May 1st and provide your support and/ or raise any issue you feel are yet to be addressed.

Regards, Nancy