Subject: [Last-Call] Secdir last call review of draft-ietf-suit-information-model-08

From: Derrell Piper via Datatracker <[email-masked]>
Date: Wed, 18 Nov 2020 16:34:15 -0800

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

---

From: Brendan Moran <[email-masked]>
Date: Thu, 19 Nov 2020 15:08:19 +0000

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 <[email-masked]> wrote:
>
> Reviewer: Derrell Piper
> Review result: Not Ready
>

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.

> 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?

>  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.

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.

> 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?

> 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

> 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.

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?

> 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
> [email-masked]
> 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.

---

From: Derrell Piper <[email-masked]>
Date: Thu, 19 Nov 2020 11:57:03 -0800

Brendon,

> 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 i…

I think that change would help.  I almost wrote that I felt this 
document should have been contained in another, so there you go.

> 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 informat…

Absolutely no need to apologize for considering usability.

> 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. BC…

BCP14 is where I'd go so leave it.

> Would you find it less confusing to order it as follows?

Yes, I think that would really help.

> The working group was quite clear that the list of information elements should come first and be justified by subsequent sections.

They belong up front, if you reorg it that'll probably go a long way.

> Would it be clearer to rephrase the original text as follow >
>>     Recommended practice
>>     is to use [
>> RFC4122

Yes, it would be.

> 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…

Okay.

> 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 r…

It's the procedural point that you're pointing into Microsoft's 
corporate web's description of the Microsoft Commerce Server 2002, which 
may not be online forever.  I guess you have to have a reference, hum.

> https://tools.ietf.org/html/draft-ietf-suit-information-model-08#section-4.3.14

That is the mitigation, and I even like it, so okay!

> 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…

I thought so, so I'd just add that text explicitly to clarify.

> Is there a reason to include specific time formats in the information model, rather than a serialization thereof?

No, serialization would canonicalize it coming out, and that was my concern.

Derrell