Re: [Suit] Review of draft-ietf-suit-manifest-09

[Henk Birkholz <[e-mail]>]

Hi Dave,

yes exactly. This I-D is now revitalized due to some re-occurring 
requirements - SUIT being one of the domains of interest.

Viele Grüße,

Henk

On 27.07.20 17:43, Waltermire, David A. (Fed) wrote:
> By CBOR OID are your referring to draft-bormann-cbor-tags-oid?
> 
> https://datatracker.ietf.org/doc/draft-bormann-cbor-tags-oid/
> 
> Dave
> 
> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Henk Birkholz
> Sent: Monday, July 27, 2020 11:15 AM
> To: Brendan Moran <[e-mail]>; Dave Thaler <dthaler=[e-mail]>
> Cc: suit <[e-mail]>
> Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09
> 
> Hi Brendan,
> hi Dave
> 
> thanks for your extensive summary, Brendan! This is very useful. Just two small additions.
> 
> While CBOR OID seems to be a good match, that unfortunately introduces a timing problem (as does packed), but maybe we can devise a way around that.
> 
> As PEN are not a rare choice in CBOR-based representations, I'd just want to voice support for the notion of being very careful here. We can of course start to create a qualified name that involves a PEN (among other things), but we are not the only ones that might attempt such a thing and therefore might require some ealignment.
> 
> Viele Grüße,
> 
> Henk
> 
> On 27.07.20 16:42, Brendan Moran wrote:
>> Hi Dave,
>>
>> Thank you very much for your very detailed review! Of course, it will
>> take me some time to work through this review. I will do my best to
>> clarify these technical comments as I work through. In general, the
>> issues you’ve listed look to me like the “right” answer is fairly
>> obvious, so I will straighten them out. There are several comments
>> that I think deserve a little more clarification.
>>
>> 6. SUIT_Report
>>
>>> SUIT_Report and Reporting Engine text is added but does not appear to
>>> be about what goes in a SUIT manifest, so I argue that it doesn’t
>>> belong in this spec (and is arguable as to whether it’s in scope for
>>> SUIT at all)
>>
>> You’re right. This has not been raised on the list. If it’s more
>> appropriate to put it in a new draft, I’m happy to do that. However,
>> it’s a natural consequence of adding the SUIT_Reporting_Policy, which
>> was discussed at the virtual interim. It seemed to me that if a
>> reporting policy was specified, then an implementor would naturally
>> want to know how to report that information. If there is a need for
>> logging SUIT commands, along with their arguments and results, this
>> seems very specific to SUIT in general and the SUIT manifest in
>> specific. I struggle to see what document would be more appropriate
>> than the SUIT manifest for the SUIT_Report.
>>
>>> Furthermore, it says SUIT_Report can go in an attestation report.
>>> What’s the rationale for that as opposed to some more typical
>>> logging/reporting mechanism that might integrate with existing error
>>> reporting mechanisms and trouble ticketing?
>>
>> SUIT_Reporting_Policy has two output channels: “system information,”
>> that is the “actual” values compared against in conditions, and
>> “command records” which are effectively logs of command execution. For
>> an update case, these are adequately served by logging infrastructure.
>> However, in a bootloader case, this is inadequate because the
>> bootloader and the booted application are different security domains.
>> This means that any system information or command records need to be
>> protected from modification by the application. Typically, this would
>> be done with a signature; I don’t see how this is different from attestation.
>>
>> The discussion of a Reporting Engine seems necessary: it’s the thing
>> that consumes reporting policy.
>>
>>> 7.Defining a new identifier space (UUIDs) for vendors is not
>>> motivated.  So a vendor can’t use an existing OUI or IANA private
>>> enterprise number that can be easily looked up? You have to instead
>>> use an opaque identifier with no way to directly look up its meaning?
>>> What is the rationale for inventing a new space rather than being
>>> able to reuse an existing one that can be looked up to get an org
>>> name, contact info, etc.? (Yes there is suit-text-vendor-domain but
>>> that’s severable and optional to implement at all.) And a UUID takes
>>> up more bytes than either an OUI or a PEN, so is worse for
>>> constrained devices, so why not use an existing space that is shorter
>>> and hence more applicable to constrained devices?
>> 7. Vendor IDs
>> I’d argue that I have not defined a new identifier space. It was
>> defined in RFC4122. That said, I think that PEN could be beneficial if
>> we can work around some of the complexities associated with it.
>>
>> OUIs may be prohibitive for small manufacturers (US $2,995). For
>> example, I have seen small manufacturers avoid building USB devices
>> due to the cost of obtaining a USB VID. Class IDs still require a UUID
>> Name Space Identifier. There is no rule I can find for constructing an
>> OUI UUID, so it cannot be used as a UUID Name Space Identifier.
>>
>>
>> Private Enterprise Numbers seem manageable by small manufacturers.
>> There is a UUID Name Space Identifier for OIDs, however this gets a
>> bit confusing. You would need to construct a class ID as follows:
>>
>> Vendor_UUID = uuid.uuid5(uuid.NAMESPACE_OID, EncodeOID(‘1.3.6.1.4.1.’
>> +
>> PEN))
>> Class_UUID = uuid.uuid5(Vendor_UUID, Class_Information)
>>
>> The problem here is that EncodeOID() is not specified at all in RFC4122.
>> The closest we get is:
>>
>>> For example, some name spaces are the
>>>      domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished
>>>      Names (DNs), and reserved words in a programming language.
>> So Class IDs become unpredictable because OID encoding is
>> underspecified in RFC4122. I can see the Vendor_UUID being computed
>> with several different versions of EncodeOID:
>> - Encode as dotted-integer string
>> - Encode as DER OID
>> - Encode as value of DER OID (no tag/length)
>> - Lots of other ASN.1 encodings possible.
>> - Future CBOR OID?
>>
>> I do not believe we should specify the use of OUIs because 1) they
>> cost $3000, 2) there is no UUID namespace for OUIs
>>
>> I’m not against using a PEN, but we would also need to provide
>> extremely strict encoding guidelines for constructing Vendor UUIDs,
>> since the Vendor UUID is needed as the Name Space ID for the Class
>> UUID. For encoding in the manifest I think we should insist on using
>> the PEN directly rather than the full OID. But what would we do with a
>> PEN sub-assignment?
>>
>> There’s a lot more complexity here than just “use a PEN.”
>>
>>
>> Best Regards,
>> Brendan
>>
>>
>>> On 24 Jul 2020, at 23:51, Dave Thaler
>>> <dthaler=[e-mail]
>>> <mailto:dthaler=[e-mail]>> wrote:
>>>
>>> During the IETF hackathon week, I went through all of the suit
>>> manifest draft and kept notes.
>>> My full review in context is at
>>> https://www.microsoft..com/en-us/research/uploads/prod/2017/05/draft-
>>> ietf-suit-manifest-09.pdf
>>> <https://www.microsoft.com/en-us/research/uploads/prod/2017/05/draft-
>>> ietf-suit-manifest-09.pdf> which is too long to copy into email here.
>>> Besides lots of editorial comments, there’s a few technical
>>> comments/questions, including (but there may be more depending on
>>> whether you interpret some others as editorial or technical):
>>> 1.Apparent contradictions about whether on systems with a single
>>> component, whether setting the component index should clear the
>>> dependency index or not.
>>> 2.What it means to “break” is underspecified (I’m guessing continue
>>> on to the next command after try-each, as opposed to go on to the
>>> next manifest, but it’s not stated in the doc).
>>> 3.Section 6.7 seems to require using multiple processes, not just
>>> multiple threads, without justification.
>>> 4.The trust model when multiple manifest processors exist, in two or
>>> more security domains, is underspecified, and not mentioned in the
>>> Security Considerations section.
>>> 5.Suit-text-version-required expression syntax is underspecified.
>>> 6.SUIT_Report and Reporting Engine text is added but does not appear
>>> to be about what goes in a SUIT manifest, so I argue that it doesn’t
>>> belong in this spec (and is arguable as to whether it’s in scope for
>>> SUIT at all).  It reads like SUIT_Record is yet another alternative
>>> to IPFIX, syslog, etc., and doesn’t state the rationale for defining
>>> a new format. You might say that it could be used in an octetArray in
>>> IPFIX if someone defined such a field, but this document doesn’t, and
>>> indeed if SUIT_Record is not something that would appear in a SUIT
>>> manifest, then I think it should not be in this document.
>>> oFurthermore, it says SUIT_Report can go in an attestation report.
>>> What’s the rationale for that as opposed to some more typical
>>> logging/reporting mechanism that might integrate with existing error
>>> reporting mechanisms and trouble ticketing? I don’t think this was
>>> motivated in either the suit architecture or the suit IM document,
>>> and I don’t recall it ever being discussed on the SUIT list or WG
>>> meeting (but maybe it was and I forgot?)   Again, I think my
>>> preferred course would be to sever it from the SUIT manifest specification.
>>> 7.Defining a new identifier space (UUIDs) for vendors is not
>>> motivated.  So a vendor can’t use an existing OUI or IANA private
>>> enterprise number that can be easily looked up? You have to instead
>>> use an opaque identifier with no way to directly look up its meaning?
>>> What is the rationale for inventing a new space rather than being
>>> able to reuse an existing one that can be looked up to get an org
>>> name, contact info, etc.? (Yes there is suit-text-vendor-domain but
>>> that’s severable and optional to implement at all.) And a UUID takes
>>> up more bytes than either an OUI or a PEN, so is worse for
>>> constrained devices, so why not use an existing space that is shorter
>>> and hence more applicable to constrained devices?
>>> 8.The time-of-day and day-of-week wait events are underspecified in
>>> terms of whether they are in local time or UTC.
>>> 9.If I understand correctly, if a dependency manifest sets Strict
>>> Order to false, this will then carry over to the dependent manifest,
>>> potentially leading to a source of unexpected bugs.  Is my
>>> understanding correct?
>>> 10.For conditions that are optional to implement, I couldn’t tell if
>>> that means that if not implemented by a manifest processor, they are
>>> treated as passing, failing, or as parse errors.
>>> 11.There are several commands where in certain contexts the doc says
>>> they “MUST have no effect”.  But why not make them illegal to appear
>>> in such contexts?   Why spend the extra space to include them in the
>>> manifest just to have no effect?
>>> 12.Swap directive is underspecified in terms of what should happen if
>>> the destination doesn’t yet exist (i.e., fail vs move).
>>> 13.IANA considerations section doesn’t yet meet the requirements of
>>> RFC 8126.  For example, it specifies Expert Review but contains
>>> insufficient information to instruct an expert how to review, per the
>>> guidelines in that RFC.
>>> I know the doc is long (109 pages) so forgive me if some answers are
>>> elsewhere in the doc and I just missed them, which just means maybe a
>>> cross-reference would be sufficient.J Dave
>>> _______________________________________________
>>> Suit mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.walter
>>> mire%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797
>>> a93e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2
>>> BTGq7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0
>>
>> 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.
>>
>> _______________________________________________
>> Suit mailing list
>> [e-mail]
>> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermi
>> re%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797a93
>> e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2BTGq
>> 7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0
>>
> 
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ce1a91bc27b184eb4affa08d8323ff57b%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637314597580328389&amp;sdata=1HJE9Qiicoe%2BTGq7kaodbBn23m6L31VL5OQLI3mHoAY%3D&amp;reserved=0
>