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

[Henk Birkholz <[e-mail]>]

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://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.
> 
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit
>