Hi Derrell, It seems like we’re coming at this from very different angles, so let me try to set some context. The SUIT manifest, which is the first normative specification expected from the SUIT WG, is a document format that defines a process for a device to progress from one version of one or more firmware/software/data components to another version of that/those components. A manifest may also define a process for a device to determine whether or not it has all required components, that they are correct, load those components into executable memory if needed, and then invoke one or more components. Updating the components of a device, is a security sensitive process that is, by its very definition, remote code execution. Thus, while firmware update mechanisms are the single most important security tool we have for patching vulnerabilities, they are also the single most dangerous tool: any flaw in an update mechanism could lead to complete malicious takeover of a device. As a result, we have taken a very particular approach to the Information model. It should be said that the Information Model was originally defined as a Threat Model within the architecture, but it was later separated from the architecture and grouped with a list of required information, resulting in the information model as it is today. It would probably be more precise to define the document as a “Security and Usability model.” Maybe we should call it an “information and threat model." Please see further comments inline. Best Regards, Brendan > On 19 Nov 2020, at 00:34, Derrell Piper via Datatracker <noreply@xxxxxxxx> wrote: > > 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. We believe that it is necessary to justify the presence of each information element. This requires defining exactly which security requirements and usability requirements give rise to each information element. Similarly security requirements and usability requirements do not exist in a vacuum. Security requirements that do not mitigate threats and usability requirements that do not enable user stories are needless complexity. Instead of leaving these implicit, as is done in many documents, we have fully defined them. This does make the document somewhat different from other information models, but we believe that those who read the information model should understand the purpose of each element and that the only way that they can understand those purposes is to see why the elements are there. > I would prefer MAY, MUST, or SHOULD be used consistently instead of OPTIONAL > and RECOMMENDED. Both are used here. We have chosen terms based on how they best fit the structure of the surrounding grammar. If we need to choose one set of terminology, we can do this, but it will require substantial rephrasing. BCP14 does not give guidance on using only one of (MAY,OPTIONAL) or (SHOULD,RECOMMENDED) consistently. Is there a reference that gives guidance on this topic? > 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 Would you find it less confusing to order it as follows? o elements o requirements o threats/user stories The working group was quite clear that the list of information elements should come first and be justified by subsequent sections. > 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? This is an explicit references to RFC4122. The full sentence under discussion reads: > Recommended practice > is to use [ > RFC4122 > ] version 5 UUIDs with the vendor's domain name and > the DNS name space ID. > RFC4122 says (https://tools.ietf.org/html/rfc4122#section-4.3): > Allocate a UUID to use as a "name space ID" for all UUIDs > generated from names in that name space; see > Appendix C > for some > pre-defined values > And (https://tools.ietf.org/html/rfc4122#appendix-C): > /* Name string is a fully-qualified domain name */ > uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ > 0x6ba7b810, > 0x9dad, > 0x11d1, > 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 > }; Therefore, when the suit-information-model references “the DNS name space ID” it is referring to the UUID in RFC4122, Appendix-C: > 6ba7b810-9dad-11d1-80b4-00c04fd430c8 Would it be clearer to rephrase the original text as follows? > Recommended practice > is to use [ > RFC4122 > ] version 5 UUIDs with the vendor's domain name and > 6ba7b810-9dad-11d1-80b4-00c04fd430c8 (the DNS name space ID). > As it happens, the SUIT working group has discussed the possibility of using Private Enterprise Numbers in place of UUIDs for Vendor IDs as well. This action is pending in the working group, as an update to the manifest specification. > 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? Some methodology must be used in order to perform a threat analysis. This is the method we used and it defines the terminology used to classify the various threats in the threat model. Is there a reason to remove this reference given that it defines the terminology used in the threat model? > There may be traffic analysis and fingerprinting concerns if the manifest is > not encrypted, specifically if the vendor IDs are sent unencrypted. I believe this is THREAT.MFST.EXPOSURE and/or THREAT.NET.ONPATH. The mitigation is: REQ.SEC.MFST.CONFIDENTIALITY: Encrypted Manifests, which is implemented by: External Encryption Wrapper / Transport Security See these sections for full details: https://tools.ietf.org/html/draft-ietf-suit-information-model-08#section-4.2.7 https://tools.ietf.org/html/draft-ietf-suit-information-model-08#section-4.2.14 https://tools.ietf.org/html/draft-ietf-suit-information-model-08#section-4.3.14 > pp.10, "...that version MUST be specified" > > It MUST be specified IF, but the element is OPTIONAL? Correct. It MUST be supported by the serialization, but a given deployment does not require it if, for example, it does not support differential updates. So it is REQUIRED in the serialization, but OPTIONAL to implement in any given manifest or manifest processor. > 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? In general, we try not to require a synchronised time source, since this puts substantial requirements on a constrained device. You are correct that, for an image to expire, some notion of time is necessary. This can be complex or simple. We do not require millisecond accuracy; even displaying “Today’s Date” to a user would be “secure enough” for this use since, as noted in the draft: > This element may also be displayed (e.g. via an app) > for user confirmation since users typically have a reliable knowledge > of the date. > Is there a reason to include specific time formats in the information model, rather than a serialization thereof? > pp.32 4.4.3, "Satisfied by USER_STORY.OVERRIDE (Section 4.4.3)" > > Section 4.4.3 is circular (satisfies itself) This is a reference error. Thanks for picking it up. The correct reference is: 4.5.2. REQ.USE.MFST.OVERRIDE_REMOTE > Derrell > > > > _______________________________________________ > Suit mailing list > Suit@xxxxxxxx > https://www.ietf.org/mailman/listinfo/suit IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
