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

[Michael Richardson <[e-mail]>]

    dthaler> 6. SUIT_Report
    dthaler> SUIT_Report and Reporting Engine text is added but does not appear to be
    dthaler> about what goes in a SUIT manifest, so I argue that it doesn’t belong in
    dthaler> this spec (and is arguable as to whether it’s in scope for SUIT at all)

    bm> You’re right. This has not been raised on the list. If it’s more
    bm> appropriate to put it in a new draft, I’m happy to do that. However, it’s a
    bm> natural consequence of adding the SUIT_Reporting_Policy, which was
    bm> discussed at the virtual interim. It seemed to me that if a reporting
    bm> policy was specified, then an implementor would naturally want to know how
    bm> to report that information. If there is a need for logging SUIT commands,
    bm> along with their arguments and results, this seems very specific to SUIT in
    bm> general and the SUIT manifest in specific. I struggle to see what document
    bm> would be more appropriate than the SUIT manifest for the SUIT_Report.

I had tweaked on Dave's question here about whether IPFIX might be an
appropriate transport.  I am intringued by this possibility.
I would like to understand more about this as a concept.
I think that I would not want an IPFIX client in a bootloader, so:

    dthaler> Furthermore, it says SUIT_Report can go in an attestation report.  What’s
    dthaler> the rationale for that as opposed to some more typical logging/reporting
    dthaler> mechanism that might integrate with existing error reporting mechanisms
    dthaler> and trouble ticketing?

    bm> SUIT_Reporting_Policy has two output channels: “system information,” that
    bm> is the “actual” values compared against in conditions, and “command
    bm> records” which are effectively logs of command execution. For an update
    bm> case, these are adequately served by logging infrastructure. However, in a
    bm> bootloader case, this is inadequate because the bootloader and the booted
    bm> application are different security domains. This means that any system
    bm> information or command records need to be protected from modification by
    bm> the application. Typically, this would be done with a signature; I don’t
    bm> see how this is different from attestation.

I don't know what "existing error reporting mechanism" a bootloader (in a
nanny cam) might have access to :-)
From Dave's probably TEEP point of view, I can see that the TAM could well
provide a very rich of facilities.
The observation that the bootloader and booted application are in different
security domains is probably more relevant than the observation I was going
to make that the bootloader might not have any network.

I think that we can reasonably separate this into another draft, that I
think, TEEP would ignore.

    bm> 7. Vendor IDs
    bm> I’d argue that I have not defined a new identifier space. It was defined in
    bm> RFC4122. That said, I think that PEN could be beneficial if we can work
    bm> around some of the complexities associated with it.
    bm>
    bm> OUIs may be prohibitive for small manufacturers (US $2,995). For example, I
    bm> have seen small manufacturers avoid building USB devices due to the cost of
    bm> obtaining a USB VID. Class IDs still require a UUID Name Space
    bm> Identifier. There is no rule I can find for constructing an OUI UUID, so it
    bm> cannot be used as a UUID Name Space Identifier.

At one point, this was just not an issue because you always had to get one
for ethernet.   But, in many lower-end semi-industrial cases, the network is
provided by a "wifi module", which really does layers 1-4 (sometimes TLS
too), so the vendors do not pay for ethernet OUI.

    bm> Private Enterprise Numbers seem manageable by small manufacturers.
    bm> There is a UUID Name Space Identifier for OIDs, however this gets a bit
    bm> confusing. You would need to construct a class ID as follows:

PENs are easy. You send an email to IANA, and a week or so later, you get
number.  I have one.

    bm> There’s a lot more complexity here than just “use a PEN.”

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [