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

[Derrell Piper <[e-mail]>]

Brendon,

On 11/19/2020 7:08 AM, Brendan Moran wrote:
> 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."

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

Absolutely no need to apologize for considering usability.

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

BCP14 is where I'd go so leave it.

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

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.

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

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 update to the manifest specification.

Okay.

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

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.

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

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

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

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

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

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

Derrell