[OPSEC] Artart last call review of draft-ietf-opsec-indicators-of-compromise-03

Rich Salz via Datatracker <noreply@ietf.org> Tue, 03 January 2023 17:51 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5A7C1522BB; Tue, 3 Jan 2023 09:51:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rich Salz via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-opsec-indicators-of-compromise.all@ietf.org, last-call@ietf.org, opsec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167276830082.16854.1023258034437526970@ietfa.amsl.com>
Reply-To: Rich Salz <rsalz@akamai.com>
Date: Tue, 03 Jan 2023 09:51:40 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/Eh9xI3M6scfzcdZPyiXbZqdo_wc>
Subject: [OPSEC] Artart last call review of draft-ietf-opsec-indicators-of-compromise-03
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.39
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2023 17:51:40 -0000

Reviewer: Rich Salz
Review result: Ready

I read this document for the ART review team. My background is in security, but
I tried to focus on "typical ART area issues" as described in
https://trac.ietf.org/trac/art/wiki/TypicalARTAreaIssues I have some feedback,
but nothing that could not be addressed during the next phase of publication;
i.e., do not respin a draft just for this review.

I think "blue team" mentioned in sec 3.1 should be in the terminology section,
and have an expanded definition.

Did Bianco coin the (lovely) term pyramid of pain? If so, perhaps use
"Bianco's" when introduced in 3.1  The wording in the paragraph before the
drawing might need some tweaking. At the end of 3.1 on large number of domain
names, isn't auto-generated names also a factor?

Sec 6.1, "If an attack happens than you hope"  "you hope" seems uncommon in
RFC's these days in my experience.

I really liked this document.  Thanks for providing it.