Subject: Re: [Suit] Manifest and architecture drafts updated

From: Marti Bolivar <[email-masked]>
Date: Thu, 22 Feb 2018 14:52:39 -0500

Hi,

On Mon, Jan 29, 2018 at 10:02 AM, Hannes Tschofenig <
[email-masked]> wrote:

> Hi all,
>
>
>
> we just submitted updates to the manifest and the architecture documents.
> Here are the two drafts:
>
> https://tools.ietf.org/html/draft-moran-suit-manifest-01
>
> https://tools.ietf.org/html/draft-moran-suit-architecture-01
>

Thanks for the notice!

I have some questions and other comments about
draft-moran-suit-architecture-01. I hope this is an appropriate forum for
public feedback on this draft. Please let me know if not.

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

Page 13: "We would like the following persons" should be "we would like to
thank the following persons".

Page 18: In 11.3.3, are there any plans for requirements that devices MUST
use the manifest with the most recent Best-before timestamp in case
multiple are available?

Page 18:

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 11.3.4, the location to store the payload MUST
be included in the signed information (and 11.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 11.3.4,
it's specified that the payload format MUST be included in the signed
information, and in 11.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.

Page 21: In 11.5.1 and 11.5.2, should each "it must be possible" be
replaced with "it MUST be possible"?

Page 21: Would it be helpful to add additional normative text describing
what happens when 11.6.4 (Manifest Field: Dependencies), and 11.6.5
(Manifest Field: Best-Before timestamp) are combined?

I'm assuming the idea is that if the Best-before timestamp has expired for
the top-level or any dependent manifests, suitably equipped devices MUST
reject the entire update; is that right? If so, an update making that more
explicit might be in order.

This relates to my earlier question about whether devices MUST prefer
"fresher" manifests, since a hierarchy of dependencies seems to only induce
a partial order on freshness. It also seems to relate to Michael's
questions regarding firmware version ordering; I'm not sure it's clear in
the document if Best-before contributes to that ordering.

Thanks,
Marti

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 26 Feb 2018 12:36:35 +0000

Hi Marti,

Thanks for the feedback.

A few remarks below:

From: Marti Bolivar [mailto:[email-masked]]
Sent: 22 February 2018 20:53
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Suit] Manifest and architecture drafts updated

Hi,

On Mon, Jan 29, 2018 at 10:02 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

we just submitted updates to the manifest and the architecture documents. Here are the two drafts:
https://tools.ietf.org/html/draft-moran-suit-manifest-01
https://tools.ietf.org/html/draft-moran-suit-architecture-01

Thanks for the notice!

I have some questions and other comments about draft-moran-suit-architecture-01. I hope this is an appropriate forum for public feedback on this draft. Please let me know if not.

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

Thanks. Will update the text.

Page 13: "We would like the following persons" should be "we would like to thank the following persons".

Will fix it.

Page 18: In 11.3.3, are there any plans for requirements that devices MUST use the manifest with the most recent Best-before timestamp in case multiple are available?

We haven’t discussed the mandatory-to-implement or the mandatory-to-use features in the group yet but it is worthwhile to bring this topic up in the conference call today.

Page 18:

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 11.3.4, the location to store the payload MUST be included in the signed information (and 11.6.7 specifies that Storage Location is a Manifest Field).

Yes; maybe we should make this explicit.

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

True.

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.

Good catch. We have to fix this.

Page 21: In 11.5.1 and 11.5.2, should each "it must be possible" be replaced with "it MUST be possible"?

It really depends on how you use RFC 2119 language. It was originally specified as normative language for specifications but here it only refers to requirements. We could, however, use capitalized MUST/SHOULD/MAYs.

Page 21: Would it be helpful to add additional normative text describing what happens when 11.6.4 (Manifest Field: Dependencies), and 11.6.5 (Manifest Field: Best-Before timestamp) are combined?

I'm assuming the idea is that if the Best-before timestamp has expired for the top-level or any dependent manifests, suitably equipped devices MUST reject the entire update; is that right? If so, an update making that more explicit might be in order.

This relates to my earlier question about whether devices MUST prefer "fresher" manifests, since a hierarchy of dependencies seems to only induce a partial order on freshness. It also seems to relate to Michael's questions regarding firmware version ordering; I'm not sure it's clear in the document if Best-before contributes to that ordering.

We clearly haven’t provided enough text in the document yet. The Best-before condition expresses that an update must not be applied after the indicated time. If the manifest contains dependencies then also those would not be applied either. At least that’s how I think it should work but ultimately it is the decision of the group to decide how the functionality has to work.

Ciao
Hannes

Thanks,
Marti
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: <[email-masked]>
Date: Wed, 28 Feb 2018 10:55:32 +0000

Hannes, Brendan, All

Thanks for the update. Adding section 11 is really valuable when it comes to understanding where the fields of the manifest are derived. 

Please find my comments and questions below after a first review of the Architecture Document.
I hope this is the right form to address this. Any comments, feedback, clarification, corrections are appreciated.

*Page 6, Section 3.3 Uses state-of-the-art security mechanisms:

State-of the-art security can mean a lot of things and is really very high level. Would it make sense to specify this a bit more. E.g.:
-There has been discussion on Resistance against Quantum Cryptography on the mailing list. Is it worth mentioning?
-Does it make sense to specify the minimum Security Strength of Algorithms required for the IETF SUIT?
E.g. The Security Strength (Bits of Security) of Cryptographic Algorithms used to provide firmware image authentication and confidentiality protection must be 128 Bits of Security or greater ....
(Security Strength Definitions can be found in NIST SP 800-57 Part1, Section 5.6.1. Note I am not suggesting only to allow algorithms listed in SP 800-57)

* Page 6, Section 3.4 Rollback attacks must be prevented 

-I am not sure how the last paragraphs (manifest parsing) relates to rollback protection?
I would have rather expected some text as described in section 11.2.1

*Page 6, Section 3.5 High Reliability

Reading on page 12, Section 8 its states the following is _out of scope_:
'installing firmware updates in a robust fashion so that the update does not break the device functionality of the environment this device operates in'
-This seems to be in conflict what is stated in Section 3.5 as Requirement?

-In addition shall the IoT Firmware Update Architecture really limit the update to a Dual Image Approach ?
Of course it is the most robust approach, but due to NVM Constraints of Devices a Single Image Update should not be excluded.

*Page 6, Minimal bootloader

-What does 'validate the received _firmware_' mean?
I would assume it means to validate the manifest including verification of manifest signature, validation of manifest claims and Check of Hash over Firmware Image and optionally decryption of the received firmware image...?
In general it is unclear what is the meaning of '_firmware_' in this section (manifest and firmware image OR firmware image only) , since the term 'firmware' by itself in not defined/mentioned in Section 2 and some parts of the architecture explicitly use 'firmware image' and other sections talk about 'firmware' (e.g. Section 6 Example Flow, where I would interpret that firmware means firmware image)

*Page 9, Section 4 Architecture

It states: "
For confidentiality protection of firmware images the author needs
      to be in possession of the certificate/public key of a device."

There are also Symmetric Key Options (Recipient Algorithms) for Content Encryption Key (CEK) Distribution, which is actually already stated in the manifest draft .
-Therefore the above sentence should be updated to reflect, clarify also usage of symmetric keys as an additional option for confidentiality protection!?

*Page 19, Section 11.3.5 & Page 24, Section 11.6.11 

With the update of the Threat Model for the first time symmetric signatures come into the picture as a requirement.
In 11.6.11 states: " .. If Message  Authentication Codes (MAC) are used for authenticity, then devices  MUST have unique pre-hared keys."
In the previous Architecture Version 00 it stated " Future versions may also describe a  symmetric key approach for very constrained devices"

Some comments for discussion:
While the benefit of symmetric device individual signatures is to support very constrained devices with non-public key cryptography support, it comes with some drawbacks:
1) cost of complexity for symmetric device individual key management ;
2) Device Individual Manifests are non broadcast friendly requiring some form of online environment versus e.g. utilizing an store and forward architecture;
3) Impact to some already defined requirements: E.g. how to comply to MSFR6 
(Handling Authorship right and a Qualification right with symmetric device individual signatures seems to be very hard in practice in my opinion)

If there is a requirement to support symmetric signatures (which is my interpretation from 11.3.5 and 11.6.11) then:
1) To be consistent it should also be stated in Section 4 Architecture, where currently only public key cryptography is stated (..We use public key cryptography to accomplish this..) ? 
2) The drawbacks and potential conflicts to part of the architecture should be documented 
3) Potentially it should be stated that Public Key Cryptography is the preferred choice... ?
-The other alternative would be to focus on asymmetric signatures only in the first version...

* Section 11. Threat Description, General Comment

Although Confidentiality Protection is optional I currently don't see this  topic addressed in section 11 (and hence no requirements for key management fields for payload protection in section 11.6 Manifest Fields ).
Therefore I see two possible topics where it might make sense to add:
1) Add a Threat in Section 11.2, Reverse Engineering Of Firmware Image for Vulnerability Analysis: 
An Attacker wants to mount  an attack on an IoT Device. To prepare the attack he retrieves the provided Firmware Image and performs reverse engineering of the Firmware Image to analyze it for specific vulnerabilities.
2) Add a Use Case in Section 11.4, IP Protection:
 As an OEM or Developer for IoT devices, I want to protect the IP contained in the Firmware Image.

-Would the above or similar text make sense to add to be consistent how the Manifest Fields are derived in section 11.6?

Thanks,
Markus

This e-mail and any attachments are confidential. They are intended solely for the attention and use of the named addressee(s). If you are not the named addressee(s) you must not use, disclose, retain or reproduce all or any part of the information contained in this e-mail or any attachments. Any unauthorized use or disclosure may be unlawful. If you have received this e-mail by mistake, please inform the sender immediately and delete it and all copies from your system and destroy any hard copies of it.

From: Suit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, January 29, 2018 4:03 PM
To: [email-masked]
Subject: [Suit] Manifest and architecture drafts updated

Hi all, 

The architecture document got enhanced to now include a threat analysis, security requirements, user stories, etc. This additional text has been motivated by mailing list discussions late last year. The text explains the presence of attributes in the manifest and the security mechanisms needed to protect them. 

Here is the diff: 
https://www.ietf.org/rfcdiff?url2=draft-moran-suit-architecture-01

The manifest document has only seen editorial updates, see https://www.ietf.org/rfcdiff?url2=draft-moran-suit-manifest-01

Thanks for the feedback so far. 

Ciao
Hannes & Brendan

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Mar 2018 07:38:23 +0000

Hi Markus,

Thanks for the detailed review.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 28 February 2018 11:56
To: Hannes Tschofenig; Brendan Moran; [email-masked]
Subject: RE: Manifest and architecture drafts updated

Hannes, Brendan, All

[hannes] Good points. What about adding this paragraph to Section 3.3:

"
The use of post-quantum secure signature mechanisms, such as hash-based signatures, should be explored. A mandatory-to-implement set of algorithms has to be defined offering a key length of 112-bit symmetric key or security or more, as outlined in Section 20 of RFC 7925. This corresponds to a 233 bit ECC key or a 2048 bit RSA key.
"

I am open for suggestions on better wording of the post quantum secure algorithms support.

I would add specific mandatory-to-implement algorithms in the manifest format itself. I would say something like MUST implement ECC with NIST P-256r1, AES-128-CCM, and SHA256. As an SHOULD implement I would use Ed25519, CHACHA20-POLY1305 and SHA256 (which seems to be close to what TLS 1.3 is recommending). Does this sound reasonable to you?

[hannes] I have re-arranged the text. Here is the new text for Section 3.4:

"
## Rollback attacks must be prevented

A device presented with an old, but valid manifest and firmware must not be tricked into installing such firmware since a vulnerability in the old firmware image may allow an attacker gain control of the device.

"

[hannes] In some sense it is desirable to provide functionality that does not break the device but on the other hand there is nothing in the manifest and consequently nothing in the specification that will really enable it since this is a system implementation design aspect. I understand that some people do not want to use a dual image approach and prefer to take the risk of going for a single image update.

Would you prefer to have this paragraph re-written or even dropped?

[hannes] I used firmware and firmware image interchangeable. I re-wrote the sentence:

"
The bootloader must be minimal, containing only the flash and cryptographic primitives. It needs to verify the received manifest and to install the bootable firmware image. The bootloader should not require updating, since a failed update poses a risk in reliability. If more functionality is required in the bootloader, it must use a two-stage bootloader, with the first stage comprising the functionality defined above.
"

Is this better?

It states: "

[Hannes] I believe this is correct since the use of a key transport mechanism would require the use of public key encryption of the content encryption key. The CEK would then be used to encrypt the firmware image itself. This would still require the author to know the public keys of all the device.

The pure use of symmetric keys has only been envisioned but not described so far.

3) Impact to some already defined requirements: E.g. how to comply to MSFR6 (Handling Authorship right and a Qualification right with symmetric device individual signatures seems to be very hard in practice in my opinion)

[Hannes] I agree with your assessment. Currently the document really focused on public key crypto and that's what we have implemented so far. We have repeatedly been told that a symmetric key version is necessary as well to deal with the low end IoT devices with all the pros & cons it has. Right now the symmetric key version has not been described throughout the document and hence I prefer to remove these sentences from the current version of the document since, as you stated, the story in the document isn't consistent. We could use the next IETF meeting to discuss the symmetric key mechanism and to make a decision about how to best incorporate it. Hence, I agree with you that we should focus on the asymmetric crypto version for the current version.

[Hannes] This is a good idea. I added the following text:

A.2.11.  Threat MFT11: Reverse Engineering Of Firmware Image for
         Vulnerability Analysis

   Classification: All Types

   An attacker wants to mount an attack on an IoT device.  To prepare
   the attack he or she retrieves the provided firmware image and
   performs reverse engineering of the firmware image to analyze it for
   specific vulnerabilities.

A.3.7.  Security Requirement MFSR7: Firmware encryption

   Firmware images must be encrypted to prevent third parties, including
   attackers, from reading the content of the firmware image and to
   reverse engineer the code.

   Mitigates: MFT11

A.4.6.  Use Case MFUC6: IP Protection

   As an OEM or developer for IoT devices, I want to protect the IP
   contained in the firmware image, such as the utilized algorithms.
   The need for protecting IP may have also been imposed on my due to
   the use of some third party code libraries.

A.6.15.  Manifest Field: Key Table

   Encrypting firmware images requires symmetric content encryption keys
   to be provided in the manifest, which themselves have to be encrypted
   using the public keys of devices.

   Implements: Security Requirement MFSR7.

Thanks again for the detailed review, Markus.

Ciao
Hannes

Thanks,
Markus

Hi all,

Here is the diff:

Ciao
Hannes & Brendan