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

[Brendan Moran <[e-mail]>]

Hi Frank,

I think you’re right, the draft should, at least, specify that the behavioural document, as a whole, needs to be authenticated.

> On 11 Mar 2019, at 13:15, Kvamtrø, Frank Audun <[e-mail]> wrote:
>
> 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…

You’re correct, the document as a whole needs to be authenticated. In other words, the document lives inside an authenticated container.

>
> 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 could easily change the term to “validate” or “check” or “test” without significant change to the semantics of this draft. I’ll take that on and define the terms.

>
> 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”.

I think you’re correct on both points. If we were to tighten up the wording by stating “decryption,” rather than “symmetric,” it would be clearer. I think it would also be useful to say explicitly that all digest verification happens in conditions. Signature/MAC verification only happens when identifying the authority behind a manifest, as described in Chapter 7.

> 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

Signatures around the whole behavioural description are the intent. I will try to make that clearer in the next draft.

> 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…

Signatures are treated as a mechanism for establishing authority and authenticity in this draft. Signatures and MACs can both be used for this purpose, which is why they are explicitly excluded. The whole document starts from the assumption that authenticity has already been established.

draft-moran-suit-manifest-04 has now been published and goes into much more detail on these points.

Best Regards
Brendan

> Regards
> Frank Audun Kvamtrø
>
>
>> -----Original Message-----
>> From: Suit <[e-mail]> On Behalf Of Brendan Moran
>> Sent: 8. mars 2019 15:54
>> To: [e-mail]
>> 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
>> [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.