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

[Brendan Moran <[e-mail]>]

Hi Dave,

Henk has it right. However this might obscure the more salient point:


  1.  Class IDs should be UUIDs.
  2.  UUIDs require a Name Space ID.
  3.  The Name Space ID should be unique per-vendor.
  4.  There must be a way to convert a vendor identifier to a Name Space ID in a consistent way.

OUI does not provide this.
PEN might provide this, but it would require a specification of the correct encoding to use when creating a UUID from an OID. This is missing in RFC4122, despite the inclusion of NAMESPACE_OID.

Best Regards,
Brendan

On 27 Jul 2020, at 16:51, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

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

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.