Re: [sacm] Working Group Last Call for draft-ietf-sacm-vuln-scenario
Jim Schaad <ietf@augustcellars.com> Fri, 26 August 2016 02:26 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4AC12B051 for <sacm@ietfa.amsl.com>; Thu, 25 Aug 2016 19:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 weXqhtnuXO3H for <sacm@ietfa.amsl.com>; Thu, 25 Aug 2016 19:26:23 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139E112B03F for <sacm@ietf.org>; Thu, 25 Aug 2016 19:26:23 -0700 (PDT)
Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 25 Aug 2016 19:38:10 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Adam Montville' <adam.w.montville@gmail.com>, sacm@ietf.org
References: <B7DD871D-ED83-4399-B7C9-AAC016969C7D@gmail.com> <B57E8E91-8DDB-4E81-AFB5-2F893187CEEC@gmail.com> <FA030A04-3B89-446D-ACC6-F1BDD8013BF4@gmail.com> <93109F49-39A7-4C72-BFD6-F565F94E7868@gmail.com>
In-Reply-To: <93109F49-39A7-4C72-BFD6-F565F94E7868@gmail.com>
Date: Thu, 25 Aug 2016 19:25:53 -0700
Message-ID: <07d501d1ff41$2d0897b0$8719c710$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_07D6_01D1FF06.80AC09A0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIyNiklLvJtznnwpPfosuSGf45n1wIWi5vXAhRLF3sBhoR5a59sigpQ
Content-Language: en-us
X-Originating-IP: [192.168.1.152]
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/KGcgTuVcfgWDnc8SiA1TkT5NrHQ>
Subject: Re: [sacm] Working Group Last Call for draft-ietf-sacm-vuln-scenario
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Aug 2016 02:26:26 -0000
My memory can easily be faulty on this, nothing like going to a meeting long ago and only partially paying attention. However I was under the impression that the purpose of this document was to help formulate the solutions that the WG needed to create. This would include helping to figure out what goes into the IM, what interfaces, and what control are needed. My impression was not that this was a high level document to describe how to operate a security program. I have no way to evaluate if it meets the second goal, nor am I sure that it is useful to document that goal as I have zero basis to evaluate that on. I definitely does not meet what I thought the goal of the document was. This does not mean that I would be so violently oppose to publishing the document as to file an appeal or anything. Jim From: sacm [mailto:sacm-bounces@ietf.org] On Behalf Of Adam Montville Sent: Thursday, August 25, 2016 5:25 AM To: <sacm@ietf.org> <sacm@ietf.org> Subject: Re: [sacm] Working Group Last Call for draft-ietf-sacm-vuln-scenario Jim, I've reviewed your comments, thanks for making them. I think your perspective is at a lower level than that which this draft intends to live. The draft is intended to describe an operational scenario not at the network layer, but from the perspective of running and operating a security program. I think some of the nits you have are probably valid, but many of your comments, I feel, may stem from the desire to have this scenario describe something at a lower level than that which was intended. As someone familiar with security programs and the basic processes and procedures typically embodied by them, this draft made sense to me (as did many of the novel acronyms, having been in this problem domain for a while). On Aug 24, 2016, at 3:02 PM, Adam Montville <adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com> > wrote: I just noticed Jim's comments under a different subject (next time, please provide your comments under the same subject heading which makes judging consensus and open issues a bit less error prone and a bit easier). Does anyone have any comment on Jim's findings? https://mailarchive.ietf.org/arch/msg/sacm/JjvnpiodY9X32yjq72W-FIMLpB4 I'll reproduce his comments here. Section 1 - first sentence. This says that it is detailed. I question that statement as I found it to gloss over almost everything The second sentence of the introduction makes a promise that I cannot find fulfilled anyplace in the core text of this document. How is this informing protocol or data model development? What I expect to see if a set of statements in the document along the lines of "This affects means that we need to have a protocol that does X" or "This affects the data model because it needs to do Y." I expect that this is going to be highlighted in the text if that is the function of the document. Section 1 - If prioritization is so important - should it affect the IM? Section 1 - Are we expecting to publish vulnerabilities in the IM long term? If so it would see that at least part of publication would be in scope. Section 2 - are you sure you want me to read this? Vulnerability description information: The subject of the first sentence is Information - so it appears to say Information which can adversely impact. Kill everything starting with which Section 3 - bullet point 1 - How much of the processing is processing into something that is SACM IM aware? Actually, looking at most of these assumptions they seem to be things that people have said that SACM should be able to do. It would be useful to call that out and say what things in SACM will support these assumptions. Section 3 - bullet point 4 - I have no idea what this says Section 4.2 - What components are we talking about that it is going to understood by? This is the first time that I know that you have used this word. As far as I know, there is current no reason for any of this data to be SACM data but could all be company proprietary. I found this document to be very hard to review. From my point of view it is lacking any useful information and therefore does not help progress any work in the group. If it is published I will do my best to forget that it ever existed and go forward. Jim Never ask for a review unless you really want one, you will probably not be happy with the results. Appendix I seems to be short on implementation specific details as promised in section 4.1 B.1 para #1 - The last sentence makes zero sense to me B.1 para #2-4 - You need to motivate these paragraphs. On Aug 24, 2016, at 2:56 PM, Adam Montville <adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com> > wrote: There seems to be good consensus on putting our vulnerability draft through to the IESG. Henk had some terminology-related comments that were augmented by Jarrett. The suggestion [1] was to change "Endpoint Vulnerability Assessment Capability" to "Endpoint Vulnerability Assessment Capabilities" (make it plural). Given that we have consensus as it stands, I don't feel that we should require the draft to be updated, but the change is small, and simple, so we could do so easily. Danny, would you be willing to make that small change before we submit the draft to IESG? Kind regards, Adam [1] https://mailarchive.ietf.org/arch/msg/sacm/lPHC95Ug2lQWTYC1HG5s2iMOYic On Jul 28, 2016, at 9:20 AM, Adam Montville <adam.w.montville@gmail.com <mailto:adam.w.montville@gmail.com> > wrote: This message starts a Working Group Last Call for the Internet-Draft ‘SACM Vulnerability Assessment Scenario’ — https://datatracker.ietf.org/doc/draft-ietf-sacm-vuln-scenario/. Please send your comments, questions, and edit proposals to the WG mail list until August 5, 2016. If you believe the document is ready to be submitted to the IESG for consideration as an Informational RFC, please send a short message stating so. Kind regards, Adam
- Re: [sacm] Working Group Last Call for draft-ietf… Jarrett Lu
- Re: [sacm] Working Group Last Call for draft-ietf… Wolfkiel, Joseph L CIV DISA ID (US)
- Re: [sacm] Working Group Last Call for draft-ietf… Ira McDonald
- Re: [sacm] Working Group Last Call for draft-ietf… John Strassner
- Re: [sacm] Working Group Last Call for draft-ietf… Waltermire, David A. (Fed)
- Re: [sacm] Working Group Last Call for draft-ietf… Henk Birkholz
- Re: [sacm] Working Group Last Call for draft-ietf… Romascanu, Dan (Dan)
- Re: [sacm] Working Group Last Call for draft-ietf… Haynes, Dan
- Re: [sacm] Working Group Last Call for draft-ietf… Adam Montville
- Re: [sacm] Working Group Last Call for draft-ietf… Jessica Fitzgerald-McKay
- [sacm] Working Group Last Call for draft-ietf-sac… Adam Montville
- Re: [sacm] Working Group Last Call for draft-ietf… Adam Montville
- Re: [sacm] Working Group Last Call for draft-ietf… Adam Montville
- Re: [sacm] Working Group Last Call for draft-ietf… Adam Montville
- Re: [sacm] Working Group Last Call for draft-ietf… Jim Schaad
- Re: [sacm] Working Group Last Call for draft-ietf… Haynes, Dan