Reviewer: Derrell Piper Review result: Not Ready 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. The summary of the review is: Not Ready Caveat: I found this document difficult. I've not previously encountered an "Informational Model" like this one, and I have not been following IoT. If these comments sound completely unhelpful then I may just not be the right person to review this informational model. I would prefer MAY, MUST, or SHOULD be used consistently instead of OPTIONAL and RECOMMENDED. Both are used here. The draft is split into five lists, with 10 pages of Manifest Information Element descriptions presumably forming the basis of the draft, but followed by the bulk of the document as the Security Consideratios section. I found the organization confusing, too abstract, and somewhat circular. In summary: o manifest elements satisfy one or more requirements o threats are mitigated by one or more requirements o security requirements (REQ.SEC) mitigate one or more threats o user stories are satisfied by one or more usability requirements o usability requirements (REQ.USE) satisfy user stories pp.7 "the DNS name space ID" This implies private DNS namespace may be a concern, and I'd like to understand why and how, because this is based on Trust Anchors as described in RFC6024. What other DNS namespaces are under consideration? pp.17, "This model uses the S.T.R.I.D.E. approach" Microsoft's STRIDE Threat Model defines six types of threats: identity spoofing, data tampering, repudiation, information disclosure, denial of service, and elevation of privilege. Why call out this particular approach? There may be traffic analysis and fingerprinting concerns if the manifest is not encrypted, specifically if the vendor IDs are sent unencrypted. pp.10, "...that version MUST be specified" It MUST be specified IF, but the element is OPTIONAL? pp.10 Manifest Element: Expiration Time Time is mentioned but no time format is specified. Is synchronized time a security requirement, and should specific time formats be specified? pp.32 4.4.3, "Satisfied by USER_STORY.OVERRIDE (Section 4.4.3)" Section 4.4.3 is circular (satisfies itself) Derrell -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
