Re: [Suit] Introducing draft-moran-suit-behavioural-manifests-00

Great to see work on this!

I wonder if this document needs to be a bit more distinct with regards 
to secure boot. It is mentioned in the ingress, but there are not a lot of 
indication right now on where to put e.g. an asymmetric signature or MAC to 
ensure the validity and/or integrity of the processable items as part 
of the behavior described in this draft...

From looking at multiple standards on security the term "verify" is often 
distinctly reserved to mean cryptographic verify functionality, e.g. using a
signature or a MAC qualifying the next jump etc. In this draft "verify" is 
stated in 5 different versions of conditions, but none of them clearly defines 
a behavior I would equate to a cryptographic verify function. In my mind 
I'm able to put said cryptographic verification functionality in the 
conditions in commands 5.2, 5.4 and 5.5 dependent on the use-case. 
Such functionality is not explicitly mentioned in any of these except from 
a loose reference to doing a similar type operation, i.e. cryptographic hash 
function in 5.2 - Verify Image presence, but then the assumption must be
that there is a signature at a different level, safeguarding the digest.

I also struggle with this due to a collision in text at the end of chapter
3 where in a paragraph before and after talk about processing steps in 
chapter 4.1:

    "System validation is used to ensure that all required dependencies
     are present and that all required images are preset. This process
     is equivalent to that used in the validation portion of Secure boot 
     workflows".

I as a reader would equate this to validation being a processing step
in 4.1, although the concept "validation" is fairly broad on this level
compared to the use of conditional verification in chapter 5.

If a cryptographic verify function is to be understood to live inside
conditional commands in chapter 5, then I have some proposals:

-Change the wording in processing steps (4.1) to limit them to 
 "doing" operations, so instead of stating "symmetric cryptographic operations"
 simply state "decryption". This means that MAC operations isn't 
 falsely included as a processing step.
-Be more explicit on the location and intention of doing a cryptographic 
 verify operation (asymmetric signature check or MAC) inside one or more 
 of the verify commands in chapter 5 or in the ingress of chapter 5
 so that it is tighter coupled with the concept of a "condition".

If the content of this operational description is *not* based on a 
signature check inside said behavioral description, but rather a 
signature around the complete set of behaviors, then this could be 
made clearer in the ingress in my opinion

The term "signature" is not mentioned once in this document, and I wonder
if this is done on purpose... I think it should be mentioned since
secure boot is referenced at several locations in this draft, even if
signatures as a concept is skipped on purpose...

Regards
Frank Audun Kvamtrø

> -----Original Message-----
> From: Suit <suit-bounces@ietf.org> On Behalf Of Brendan Moran
> Sent: 8. mars 2019 15:54
> To: suit@ietf.org
> Subject: [Suit] Introducing draft-moran-suit-behavioural-manifests-00
> 
> After IETF103, it became clear that we need to focus more on very
> constrained devices and that optimising the format for constrained parsers
> was very important. Simultaneously, we were presented with several more use-
> cases that required extension and complication of the format. It very
> quickly became clear that the existing serialisation would not meet the
> stated goals of reducing complexity in constrained devices, but also enable
> all the desired use-cases.
> 
> This made it very clear that we needed to take a new approach.
> 
> Internally, at Arm, we have been developing a new sort of mechanism for
> describing firmware updates and secure boot. It is a significant departure
> from the format we were developing before, but it comes with a lot of
> advantages. I’m pleased to be able to share it with SUIT today!
> 
> https://datatracker.ietf.org/doc/draft-moran-suit-behavioural-manifest/
> 
> This approach focuses less on describing the data that a process needs and
> more on describing the actions the process should take. We’ve been
> evaluating it against the use cases in draft-ietf-suit-information-model-02
> and more besides, and it produces compact results.
> 
> The forthcoming draft-moran-suit-manifest-04 will be based on a union of
> draft-ietf-suit-information-model-02 and draft-moran-suit-behavioural-
> manifest-00.
> 
> Best Regards,
> Brendan
> 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
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit