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

["Waltermire, David A. (Fed)" <[e-mail]>]

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