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

[Brendan Moran <[e-mail]>]

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.
o   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? 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. ☺

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.