Subject: [Suit] draft-moran-suit-architecture-02

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 2 Mar 2018 21:23:09 +0000

Hi all,

I submitted a new version of the architecture document based on the feedback from the virtual interim meeting and the mailing list discussions:
https://tools.ietf.org/html/draft-moran-suit-architecture-02

Many of the changes resulted from feedback provided by Marti Bolivar, Andrzej Puzdrowski, and Markus Gueller.

There are various changes:
* added two figures to the architecture describing the delivery methods
* updated and clarified text in the requirements  section
* added a new threat about "Reverse Engineering Of Firmware Image for Vulnerability Analysis"
* added a new security requirement about "Firmware encryption"
* added use case about "IP Protection"
* added the manifest field "Content Key Distribution Method"

Ciao
Hannes

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: "Puzdrowski, Andrzej" <[email-masked]>
Date: Mon, 5 Mar 2018 08:26:16 +0000

Hi

I renew my previous comment  as it was not answered.
(I found out that I had referred to incorrect section number.)

Page 6, section 3.6 Operates with a small bootloader
I would escalate the group of recovery protocols

The recovery mechanism is used in case the update process failed and may include support for firmware updates over serial, USB or even a limited version of Bluetooth Smart.

The recovery mechanism is used in case the update process failed and may include support for firmware updates over serial, USB or even a limited version of wireless connectivity standard like a limited Bluetooth Smart.

BR

Andrzej

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, March 02, 2018 10:23 PM
To: [email-masked]
Subject: [Suit] draft-moran-suit-architecture-02

Hi all,

Ciao
Hannes

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 5 Mar 2018 08:52:59 +0000

Hi Andrzej,

Your wording change makes sense to me. I will update the text accordingly.

Ciao
Hannes

-----Original Message-----
From: Puzdrowski, Andrzej [mailto:[email-masked]]
Sent: 05 March 2018 09:26
To: Hannes Tschofenig; [email-masked]
Subject: RE: draft-moran-suit-architecture-02

Hi

Page 6, section 3.6 Operates with a small bootloader I would escalate the group of recovery protocols

BR

Andrzej

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, March 02, 2018 10:23 PM
To: [email-masked]
Subject: [Suit] draft-moran-suit-architecture-02

Hi all,

Ciao
Hannes

---

From: Marti Bolivar <[email-masked]>
Date: Mon, 5 Mar 2018 13:58:20 -0500

Hi Hannes,

Thank you for the update.

I also renew these previous comments which you agreed should correspond to
updated text, with updated page and section numbers:

Page 8: in "it conveys it", the first "it" refers to a person (the Author),
and should use a personal pronoun (so perhaps "they convey it"; "they" is
used elsewhere in the document as a gender-neutral alternative to "he" or
"she").

Pages 21-22:

MFSR4 (Signed Payload Descriptor) is described as mitigating threat MFT5
(The target device installs the payload to the wrong location), among other
threats, presumably since in A.3.4, the location to store the payload MUST
be included in the signed information (and A.6.7 specifies that Storage
Location is a Manifest Field).

If that reasoning is correct, then MFSR4 should also mitigate against MFT4
(The target device misinterprets the type of payload), since in A.3.4, it's
specified that the payload format MUST be included in the signed
information, and in A.6.6, the Payload Format is listed as a Manifest Field.

However, MFSR4 is not specified to mitigate MFT4. In fact, none of the
security requirements are listed as a mitigation for MFT4. This seems
likely to be a simple oversight, which can be fixed by adding MFT4 to the
list of
threats MFSR4 mitigates against.

Thanks,
Marti

On Fri, Mar 2, 2018 at 4:23 PM, Hannes Tschofenig <[email-masked]
> wrote:

> Hi all,
>
> I submitted a new version of the architecture document based on the
> feedback from the virtual interim meeting and the mailing list discussions:
> 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: Hannes Tschofenig <[email-masked]>
Date: Mon, 5 Mar 2018 20:38:27 +0000

I addressed this comment in version -03, Andrzej!

-----Original Message-----
From: Puzdrowski, Andrzej [mailto:[email-masked]]
Sent: 05 March 2018 09:26
To: Hannes Tschofenig; [email-masked]
Subject: RE: draft-moran-suit-architecture-02

Hi

BR

Andrzej

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, March 02, 2018 10:23 PM
To: [email-masked]
Subject: [Suit] draft-moran-suit-architecture-02

Hi all,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 5 Mar 2018 20:39:08 +0000

Hi Marti,

I thought I had addressed these issues in version -02 already. I might have messed something up. In any case, they should now be there in version -03.

Ciao
Hannes

From: Marti Bolivar [mailto:[email-masked]]
Sent: 05 March 2018 19:58
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Suit] draft-moran-suit-architecture-02

Hi Hannes,

I also renew these previous comments which you agreed should correspond to updated text, with updated page and section numbers:

Page 8: in "it conveys it", the first "it" refers to a person (the Author), and should use a personal pronoun (so perhaps "they convey it"; "they" is used elsewhere in the document as a gender-neutral alternative to "he" or "she").

Pages 21-22:

MFSR4 (Signed Payload Descriptor) is described as mitigating threat MFT5 (The target device installs the payload to the wrong location), among other threats, presumably since in A.3.4, the location to store the payload MUST be included in the signed information (and A.6.7 specifies that Storage Location is a Manifest Field).

If that reasoning is correct, then MFSR4 should also mitigate against MFT4 (The target device misinterprets the type of payload), since in A.3.4, it's specified that the payload format MUST be included in the signed information, and in A.6.6, the Payload Format is listed as a Manifest Field.

However, MFSR4 is not specified to mitigate MFT4. In fact, none of the security requirements are listed as a mitigation for MFT4. This seems likely to be a simple oversight, which can be fixed by adding MFT4 to the list of
threats MFSR4 mitigates against.

Thanks,
Marti

On Fri, Mar 2, 2018 at 4:23 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Ciao
Hannes

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: Marti Bolivar <[email-masked]>
Date: Tue, 6 Mar 2018 11:43:44 -0500

Hi Hannes,

Thanks for the fast response. I confirm these are addressed in version -03.

Marti

On Mon, Mar 5, 2018 at 3:39 PM, Hannes Tschofenig <[email-masked]

> Hi Marti,
>
>
>
> I thought I had addressed these issues in version -02 already. I might
> have messed something up. In any case, they should now be there in version
> -03.
>
>
>
> Ciao
> Hannes
>
>
>
> *From:* Marti Bolivar [mailto:[email-masked]]
> *Sent:* 05 March 2018 19:58
> *To:* Hannes Tschofenig
> *Cc:* [email-masked]
> *Subject:* Re: [Suit] draft-moran-suit-architecture-02
>
>
>
> Hi Hannes,
>
>
>
> Page 8: in "it conveys it", the first "it" refers to a person (the
> Author), and should use a personal pronoun (so perhaps "they convey it";
> "they" is used elsewhere in the document as a gender-neutral alternative to
> "he" or "she").
>
>
>
> Pages 21-22:
>
>
>
> On Fri, Mar 2, 2018 at 4:23 PM, Hannes Tschofenig <
> [email-masked]> wrote:
>
> Hi all,
>