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

[Kvamtrø, Frank Audun <[e-mail]>]

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ø


> -----Original Message-----
> From: Brendan Moran <[e-mail]>
> Sent: 12. mars 2019 11:02
> To: Kvamtrø, Frank Audun <[e-mail]>
> Cc: [e-mail]
> 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.
> 
> > 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-manifes
> >> t/
> >>
> >> 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.