[Iotops] Re: I-D Action: draft-ietf-iotops-security-summary-02.txt

["A.J. Stein" <[e-mail]>]

Brendan,

Thanks for taking the time to address the review during the meeting. Let me
know how we can coordinate. And yes, I am more than happy to co-author this
draft with you moving forward.

Sincerely,
A.J.

On Wed, Jul 24, 2024 at 4:35 PM A.J. Stein <[e-mail]>
wrote:

> Hello,
>
> I am tardy on my review of draft-iotops-security-summary-01 (and now a
> recently published -02 in the interim) as requested. I had to review the
> 119 meeting notes to remember some of the context and the evolving
> motivation of this document.[1] I also had to refresh myself on background
> and rewatched part of the iotops session in 119 because I could not
> remember all the details about this document.[2] (Note to those who are
> like me: the notes and the attribution to those commenting by acronym was
> very terse and hard to use, I guess this observation means I help with
> notes next time).
>
> Overall, I think the foundations of the document are good. I can see
> liberal use of NIST requirements and their mapping to relevant European
> baselines (and correct from my many spot checks of NISTIR 8259A and the
> other documents; I however did not spot check each and every one). I know
> at least one work group member really wanted this document, and I too can
> see a need to continue, so I will organize this review into several
> sections, from most significant to minor. I will repeat this at the end,
> but I am more than willing to propose changes and fixes, WG permitting, to
> act on these recommendations but could not find a way to do that before or
> during review (more on that later).
>
>
> # Concepts (major)
>
> 1. Per discussion in the 119 session and my review, what is a security
> baseline, a security requirement, their relationship, and why it matters to
> the draft are not explained and knowledge is presumed. Such an explanation
> seems important to this document as it is mapping technical requirements to
> said requirements in a baseline and the latter are not common knowledge to
> IETF protocol designers and implementers. Something could and should be
> added.
> 2. In the document, there is labelling (taxonomy?) of certain technologies
> and requirements that can be architectural, hardware, procedural, and
> policy/compliance in nature. I will speak more to the consistency of it
> below. Here I will say that, even if some of these labels seem common-sense
> in nature, they are not defined, if and how they relate to one another
> matters, if you want one or combinations (or prohibit combinations of
> them). In particular, architecture and hardware could mean many things to
> me. It seems they should be defined with group consensus or (hopefully) use
> other RFC/I-D definitions and scope appropriately.
> 3. NISTIR 8259A (IoT Core Baseline) maps to multiple documents, some
> governmental and not, but this document only picks two. Why? Does that need
> explanation? I can see why it would be suboptimal to cover all of them and
> reiterate NISTIR 8259A in a document 1:1, but it seems this warrants an
> explanation in my opinion.
> 4. NIST does a lot of mapping work (not me in particular but I did do
> relevant data modeling and automation for it). NIST and others have the
> notion of a control document (NISTIR 8259A in this case) and target
> documents (ETSI and ENISA docs in this case). Should we not explain that?
> Often these documents, now or overtime, map back to one another so you want
> to know which "direction" (which source to which targets) you chose in your
> document, or much confusion occurs.
>
> # Structure and organization (major)
>
> 1. Much of the document identifies the mapped security requirement from a
> baseline (or document?) by reproducing some or all verbatim. The necessary
> discussion or explanation of technologies happens sometimes before this
> requirement copy-paste, sometimes after, without clear delineation about
> what is the control and the commentary of relevant technologies and their
> relationship (the real focus of this document). I would recommend adjusting
> and organizing the different parts potentially with headers for consistency.
> 2. The document abstract mentions a threat model ("Ultimately, a threat
> model is presented as a basis to derive requirements that interconnect
> existing and emerging solution technologies.") that is neither in the
> security consideration sections or elsewhere in the document from what I
> could find. One of the recommendations from a cited document mentions
> threat models as a requirement, but that is obviously not what I think was
> meant or is now absent. I believe this to be an artifact from previous
> edits or expectations, but the security considerations are threadbare.
> Should the abstract be adjusted to fix this discrepancy?
>
> # Editorial issues (minor)
>
> 1. In Sections 1 and 4, ietf is not capitalized in different paragraphs
> where it should be.
> 2. The parenthetical usage of citations is correct, but inconsistent in
> different sections of the document, so it became more noticeable when
> reading from start to finish.
> 3. The order of baseline references should be ... alphabetical? Sometimes
> it is NIST ENISA ESTI, sometimes ETSI ENISA. I think for a document that
> will open be a lookup table for implementers to have headings and/or the
> order of baseline references more consistent.
>
> # Open questions without prioritization
>
> 1. During the IETF 119 session for iotops, there was unclear resolution on
> whether the EU Cyber Resiliency Act was beneficial or mandatory for this
> draft to move forward. It obviously has not been added, but it is not quite
> like the other documents. It is not critical for my review of the document,
> but this issue has not been addressed and consensus (in the room or
> historically on the mailing list was unclear.
> 2. In the room, there was talk of balance and the focus of the compared
> document are only those from the US and Europe. There was high-level talk
> about including to the matrix of baseline requirements those "from
> Singapore" as useful and may add balance. It would seem that was/is an
> allusion to the Singapore Cyber Labelling Scheme (CLS) to some extent.[3]
> It is an open question on whether or not to add it, it still has not been
> added yet. I wanted to bring that back up on the list.
>
> # Conclusion
>
> I hope this review is helpful. Re my introduction, I was unable to find
> the source (GitHub, GitLab, whatever) for the draft to report these
> individual issues one-by-one and propose changes or fixes during or after
> the review. I ask because I want to repeat that I am willing to draft
> changes and assist beyond this review. I am not sure how to. (Brendan, if
> you read this, I have tried contacting you via email today and sparingly
> over the last few months to coordinate on this and make review smaller and
> faster, so I apologize for doing this all in a very large email. Let me
> know how I can help
>
> Best,
> A.J.
>
> # References
>
> 1. https://notes.ietf.org/notes-ietf-119-iotops#
> 2. https://www.youtube.com/watch?v=5WZssU-h5Ak
> 3.
> https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/cls-publication
>