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

From: Brendan Moran <[email-masked]>
Date: Fri, 8 Mar 2019 14:54:03 +0000

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.

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Mon, 11 Mar 2019 13:15:12 +0000

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 <[email-masked]> On Behalf Of Brendan Moran
> Sent: 8. mars 2019 15:54
> To: [email-masked]
> 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.
> 
> 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!
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Brendan Moran <[email-masked]>
Date: Tue, 12 Mar 2019 10:02:10 +0000

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 <[email-masked]> wrote:
>
> 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.

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

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

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

> 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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Mar 2019 12:27:29 +0100

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

… and authorized.

The idea to turn the update manifest into an update script (which is a name I’d prefer then) and let that do what it wants to do, once authorization says that it should be able to, sounds good.
A few parameters go into that authorization.  They can be manifest-like external parameters, or they can be parameters to one or more “unlock” commands that actually establish the authorization.

Grüße, Carsten

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Tue, 12 Mar 2019 12:00:14 +0000

I agree with all your responses and have no further comments on the document.
This cleared up a lot!

I don't have any strong preferences on the terms, although "check" is 
probably the item that can't be misinterpreted on a different domain
(e.g. validate like validate the format of a condition or test as in a 
system test instead of the actual condition test). This is all subjective,
though. Any of these terms are usable as long as there is good wording
introducing the concepts

Regards
Frank Audun Kvamtrø

> From: Brendan Moran <[email-masked]>
> Sent: 12. mars 2019 11:02
> To: Kvamtrø, Frank Audun <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Introducing draft-moran-suit-behavioural-manifests-00
> 
> Hi Frank,
> 
> I think you’re right, the draft should, at least, specify that the
> behavioural document, as a whole, needs to be authenticated.
> 
> > 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.
> 
> >
> > in 4.1, although the concept "validation" is fairly broad on this
> > level compared to the use of conditional verification in chapter 5.
> >
> > -Change the wording in processing steps (4.1) to limit them to "doing"
> > operations, so instead of stating "symmetric cryptographic operations"
> > -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.
> 
> 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.
> 
> >> 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.
> >>
> >> 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!
> >>
> >> 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
> >> draft-ietf-suit-information-model-02 and
> >> draft-moran-suit-behavioural- manifest-00.
> >>
> >> Best Regards,
> >> Brendan
> >> 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.