Subject: [Suit] HR Review: Firmware Update Architecture for IoT Devices

From: Gurshabad Grover <[email-masked]>
Date: Thu, 12 Jul 2018 03:00:48 +0530

Hi,

Thanks to the authors and the working group for developing the
comprehensive drafts.

As part of efforts in the Human Rights Protocol Considerations (HRPC)
group, Sandeep and I have reviewed the human rights considerations (RFC
8280) in the three drafts.

Following the updates to the drafts on July 2nd, we reached out to some
of you. We are aware that some of the concerns we raise may no longer
apply since the updates; we are sharing our review hoping to engage you
on our other observations (and their solutions) in next week's HRPC
sessions at IETF102.

Review: A Firmware Update Architecture for Internet of Things Devices
=====================================================================

An assessment of human rights considerations in
* draft-ietf-suit-architecture-01
* draft-moran-suit-manifest-02
* draft-ietf-suit-information-model-01

Introduction
------------
‘A Firmware Update Architecture for Internet of Things Devices’
(draft-ietf-suit-architecture-01) proposes an architecture for firmware
update mechanism suitable for IoT devices, and lists various
requirements associated with the same. [SUIT-ARCH]

‘A CBOR-based Manifest Serialisation Format’
(draft-moran-suit-manifest-02) describes the format of the manifest
which contains firmware update metadata for a device. The draft defines
components of the manifest and specifies their functions in
firmware-update process. [SUIT-MF]

‘Firmware Updates for Internet of Things Devices - An Information Model
for Manifests’ (draft-ietf-suit-information-model-01) describes the
information in the manifest, a threat model for the architecture, and
provides security requirements for the mitigation of these threats.
[SUIT-IM]

This is a review of the human rights considerations in the three drafts.
(See [RFC8280], ‘Research Into Human Rights Protocol Considerations’).

Human Rights Considerations
---------------------------

# Privacy ([RFC8280], section 6.2.2)

Privacy considerations are with regards to maintaining the
confidentiality of firmware image and manifest. Both the firmware image
and manifest contain information about the device. As mentioned in the
older version of the drafts, Class ID and Vendor ID are typically
compiled as strings into the firmware image. If an untrusted
intermediary storage is assumed, as in [SUIT-ARCH], this device
information will be available to all intermediary and snooping parties,
which may violate the device operator’s privacy. Additionally, device
information can be used by an attacker to design and mount targeted
attacks on the device.

Concern: The drafts are inconsistent in its recommendation of encryption
of firmware images. Section 3.3.13 of [SUIT-IM] says that the
information model must enable encrypted payloads to prevent the
attackers from reading the content of the firmware images whereas
Section 3.3 of [SUIT-ARCH] leaves the choice of encryption to the
authors/OEMs.

Recommendation: We recommend removing these inconsistencies, and that
the drafts mandate the encryption of the firmware image. Accordingly, we
recommend the relevant text of section 3.3 of [SUIT-ARCH] be updated.

Concern: The manifest also contains information of the device (such as
device-manufacturer’s name, model name, and model number) which an
end-user operates, but the drafts have not recommended the encryption of
the manifest.

Recommendation: We recommend that the drafts ([SUIT-ARCH], [SUIT-MF])
recommend encryption of the manifest as well.

# Security  ([RFC8280], section 6.2.4)

Security concerns have been emphasised in the draft [SUIT-IM]; various
threats have been covered in the thread model (section 3.1 of [SUIT-IM])
and possible mitigations have been discussed.

# Internationalization ([RFC8280], section 6.2.5) and Localization
([RFC8280], section 6.2.12)

Concern: For the specific question, “Does your protocol have text
strings that have to be understood or entered by humans?” [RFC8280]: An
email highlighting the recent updates to the drafts [MF-MAIL] notes that
a container in the manifest will have “severable” text meant for humans.
However, it is not clear from the draft what this text will contain.
Since the update server may choose to send the text to the device (if
the device supports it), human readability of these text strings is a
concern from a human rights perspective.

Recommendation: Support of multiple languages for text meant to be read
by humans advances access to information and non-discrimination. OEMs
must have the ability to internationalise and localise any text meant to
be read by humans. CBOR does support UTF-8; we recommend that the draft
make the internationalisation ability explicit for all text meant for
humans.

# Open standards ([RFC8280], section 6.2.7)
 
Pertaining to the question in [RFC8280], “is your protocol fully
documented in such a way that it could be easily implemented, improved,
built upon, and/or further developed?”, we found some statements in the
drafts that might impede further improvement and development:
* The use of the ‘extensions’ field of the manifest, defined in Section
2.1 of [SUIT-MF], has not been defined.
* Section 4.18 of [SUIT-IM] says that linked manifests must be installed
simultaneously. For clarity, we recommend that the draft specify that
each linked manifest must be validated separately.

# Reliability ([RFC8280], section 6.2.14)

Reliability concerns have been addressed in Section 3.5 and 3.6 of
[SUIT-ARCH].

Concern: With regard to the question, “[d]o you have a documented way to
announce degradation?” [RFC8280], [SUIT-ARCH] does not provide any
mechanism to convey the degradation to either the author or the device
operator.

Recommendation: We recommend that [SUIT-ARCH] recommend that degradation
is made apparent to the operator.

Concern: With regard to the question, “[d]o you have measures in place
for recovery or partial healing from failure?”, Section 3.6 of
[SUIT-ARCH] says that a recovery mechanism is optional. The lack of a
recovery mechanism will render the device inoperational in case an
update fails; this aspect is especially important in the case of
constrained devices where communication about the failure of the update
may not always be apparent to the operator.

Recommendation: Instead of making the recovery mechanism optional, we
suggest that the firmware architecture recommend or mandate the
inclusion of a recovery mechanism to ensure high reliability of the
devices in case the update fails.

# Integrity ([RFC8280], section 6.2.16)
Integrity concerns mentioned have been adequately addressed in the
Section 3.3 of the [SUIT-IM].

# Authenticity ([RFC8280], section 6.2.17)
Authenticity concerns have been adequately addressed in the Section 3.3,
in particular, the subsections 3.3.5, 3.3.6 of [SUIT-IM].

# Outcome Transparency ([RFC8280], section 6.2.12)
Whenever possible, the fact whether a update has been successful or
unsuccessful should be conveyed to the device operator. In case of
update failure, an error description should be provided. The status
tracker, described in Section 2 of [SUIT-ARCH] as offering device
management functionalities and update progress tracking, can serve this
function. However, its mechanism is not sufficiently clear in the
drafts. The coordination between status tracker and communicator has
been mentioned in Section 3.10 of [SUIT-ARCH], but the mechanism has not
been elaborated on.

# Others
After going through the drafts, we found no concerns for Heterogeneity
Support ([RFC8280], section 6.2.8) since the architecture makes little
or no assumptions about the devices or transport of the firmware image
and manifest. Concerns in the following sections are out of scope:
Connectivity ([RFC8280], section 6.2.1), Anonymity ([RFC8280], section
6.2.9), Pseudonymity ([RFC8280], section 6.2.10), Decentralization ([RFC
8280], section 6.2.13), Accessibility ([RFC8280], section 6.2.11),
Content Agnosticism ([RFC8280], section 6.2.3), and Censorship
Resistance ([RFC8280], section 6.2.6).

#Additional suggestions

Section 3.9 of [SUIT-ARCH] talks about multiple authorizations wherein
an unnecessary distinction has been made between critical infrastructure
and non-critical infrastructure. Even in non-critical infrastructure,
operators would want to the ability to install updates according to
their own preferences. In such scenarios, forced installations may
violate user’s control of the device. Accordingly, we propose that the
device operator SHOULD have the authority to accept or reject firmware
updates.

References
----------
[RFC8280] ten Oever, N., Cath, C., “Research into Human Rights Protocol
Considerations”, RFC 8280, October 2017,
<https://www.rfc-editor.org/info/rfc8280>.
[SUIT-ARCH] Moran, B., Meriac, M., Tschofenig, H., “A Firmware Update
Architecture for Internet of Things Devices”,
draft-ietf-suit-architecture-01, June 2018,
<https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/>.
[SUIT-MF] Moran, B., Meriac, M., Tschofenig, H., “A CBOR-based Manifest
Serialisation Format”, draft-moran-suit-manifest-02, January 2018,
<https://datatracker.ietf.org/doc/draft-moran-suit-manifest/>.
[SUIT-IM] Moran, B., Tschofenig, H., Birkholz, H., Jimenez, J.,
“Firmware Updates for Internet of Things Devices - An Information Model
for Manifests”, draft-ietf-suit-information-model-01, June 2018,
<https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/>.
[MF-MAIL] Moran, B., “[Suit] [suit]: draft-moran-suit-manifest-02”, IETF
Mail Archive, July 2018,
<https://mailarchive.ietf.org/arch/msg/suit/rc1gkzf2jhICwcXHSq5JggdGiHo>

Thanks to Mallory K., Amelia A., Niels t. and Sunil A. for their inputs.

Regards,
Gurshabad

---

From: Dave Thaler <[email-masked]>
Date: Wed, 11 Jul 2018 22:07:39 +0000

Thanks Gurshabad.

A clarifying question below...

> Privacy considerations are with regards to maintaining the confidentiality of firmware image and 
> manifest. Both the firmware image and manifest contain information about the device. As mentioned
> in the older version of the drafts, Class ID and Vendor ID are typically compiled as strings into the
> firmware image. If an untrusted intermediary storage is assumed, as in [SUIT-ARCH], this device
> information will be available to all intermediary and snooping parties, which may violate the device
> operator’s privacy. Additionally, device information can be used by an attacker to design and mount
> targeted attacks on the device.
>
> Concern: The drafts are inconsistent in its recommendation of encryption of firmware images.
> Section 3.3.13 of [SUIT-IM] says that the information model must enable encrypted payloads to
> prevent the attackers from reading the content of the firmware images whereas Section 3.3 of
> [SUIT-ARCH] leaves the choice of encryption to the authors/OEMs.
>
> Recommendation: We recommend removing these inconsistencies, and that the drafts mandate
> the encryption of the firmware image. Accordingly, we recommend the relevant text of section
> 3.3 of [SUIT-ARCH] be updated.

I believe the argument for it not being mandatory is that many IoT devices are not associated with
humans.  For example, factory devices are owned by the factory not a human.   Can you elaborate
on what the concern is for such devices that would warrant mandatory encryption?   Your comment
seems focused on devices associated with humans, and so I cannot tell whether your comment
applies more generally to all use cases that are in scope for the drafts.

Dave

---

From: David Brown <[email-masked]>
Date: Wed, 11 Jul 2018 17:50:39 -0600

>applies more generally to all use cases that are in scope for the drafts.

In addition, the range of devices covered by these drafts include
those with insufficient capabilities to support encryption.

It is also unclear how it would be possible to not present class and
vendor information in plain text somewhere.  The systems involved in
the software upgrade process need to be able to know what firmware
image to look at, presumably this will be indexed by these values, or
something equivalent.  Even if the image were encrypted, it would be
clear from where the image is coming from what device it applies to.

The intention of encrypting the information is to protect the firmware
author, and I'm not sure that it addresses privacy concerns about the
image.

David

---

From: David Brown <[email-masked]>
Date: Wed, 11 Jul 2018 17:58:12 -0600

>device operator SHOULD have the authority to accept or reject firmware

This depends a lot on who the device operator is referring to.  From a
security perspective, the vendor may wish to make certain types of
security updates mandatory.  As stated earlier, for devices say in a
factory, or installed on a water meter, it is unclear who the device
operator is.  An organization installing water meeting IoT devices is
unlikely to allow the individual consumers of water to have any
authority as to whether firmware is installed.

Realistically, calling this mandatory in the spec would mostly just
result in that criteria of the spec being ignored.

One challenge with SUIT, in general, is that those producing these
end-use devices have little motivation to comply with the spec.  The
benefits gained to them are resources (such as reference code) and
infrastructure that wouldn't have to be implemented.  They have little
reason to not modify any behavior of the code that doesn't suit their
own requirements.

Although there may be good reasons to desire that decisions like this
be granted to certain parties, the SUIT documents have little
authority for enforce them.

David

---

From: Gurshabad Grover <[email-masked]>
Date: Thu, 12 Jul 2018 11:27:23 +0530

Hi,

Thank you both for your responses and the examples. In light of those,
my thoughts on the encryption recommendation are given below. Also some
comments in-line.

Overall, I think the requirement level of encryption of firmware image
is not sufficiently clear in the drafts. The ambiguity makes it seem
like it is truly OPTIONAL, i.e. it expresses no preference for
encryption. In my opinion, there is a privacy and security advantage in
encrypting the firmware image. Accordingly, the drafts should use the
word "SHOULD" or "RECOMMENDED" for it, which would imply that "there may
exist valid reasons in particular circumstances to ignore [it], but the
full implications must be understood and carefully weighed before
choosing a different course." [RFC2119]

An alternative may be to demarcate the requirement level based on
whether the target device supports decryption. But, my suspicion is that
this may lead to tricky grounds elsewhere.

> applies more generally to all use cases that are in scope for the drafts.
Thanks, Dave. I completely agree with you in that the privacy concern is
more pertinent for devices directly associated with humans (which I
understand are also in the scope of the drafts). The concern is less
pressing for devices in (say) a factory, where only the security concern
may be applicable, i.e. unintentional exposure of device information
(including version) to observers and eavesdroppersmay increase the
facility's susceptibility to attacks.

> those with insufficient capabilities to support encryption.
Thanks, David. I agree.Hope the clarification suffices. I'm thinking
about the other questions you posed, and will try to get back soon.

Gurshabad

---

From: Gurshabad Grover <[email-masked]>
Date: Thu, 12 Jul 2018 15:11:30 +0530

Hi David,

Thanks. Just to clarify that particular suggestion: we suggested that
the draft mention that the device operator SHOULD have the ability to
accept or reject updates, not "MUST".

In any case, I re-read draft-ietf-suit-architecture, and found the
updated Section 3.10 useful. Because of the great diversity in the
devices in scope of the architecture, I understand that it is hard to
take a call on whether client authorisation is desirable in the general
case. We can leave this suggestion out.

Thank you.
Gurshabad

---

From: Kvamtrø, Frank Audun <[email-masked]>
Date: Thu, 12 Jul 2018 12:38:34 +0000

Initially: I don't see forced updates stated anywhere in 3.9. It only talks
about authorization. I do share your sentiment that there is a possible 
complexity in referring the term critical infrastructure, but I do see
where the terms come from. Possibly the wording of this could be simplified
by adding another type of actor or operator (mentioned later in this e-mail).
 
I don't argue that the device operator has the final say on the synchronization
of when a firmware upgrade is to be applied, but I don't think that the device
operator should invoke an acceptance on behalf of something that it doesn't 
have signing rights over. I feel the standard tries to do this by describing 
critical infrastructure and talk about the device operator as something that
potentially has more power than it should by being a bit vague in the 
description...

CC'ing in Brendan as this is a wider point than the change of wording in 
chapter 3.9.

I have a problem distinguishing between an author and a device operator and I
think the reason for this is that there may be a missing type of operator 
described in the standard. I suggest we add a third type, an OEM operator:

(listing all here for reference:)

 - Device Operator: The actor responsible for the day-to-day
 operation of a fleet of IoT devices.

 - OEM Operator: Actor responsible for the day-to-day operation of
 OEM units in IoT devices connected to an IoT network

 - Network Operator: The actor responsible for the operation of a
 network to which IoT devices connect.

If the OEM operator type is added, I don't think we need to distinguish between
an author and a device operator in chapter 3.9 about robust permissions. For 
one the device operator and author does not need to be multiple signers. I 
would assume that the device operator and the firmware author is the same 
entity in this case. Then the device code can have an author, the OEM code can
have an author...
 
The distinction I want to make with an OEM operator and a Device operator is
that the OEM device is just a sub-system of the device, but authorities around 
the OEM device may be dictated between the OEM Operator and the Network 
Operator. This is different than the relationship between the OEM and the 
device operator. One would assume that the device operator wants to have 
control of the authority to accept or reject a firmware upgrade to be able to
synchronize when and how firmware updates are accepted to be applied, but 
he/she does not need to have full control over what an OEM device will accept 
or reject.

The OEM may be dictated by rules of synchronization of updates based on 
requirements from the network operator. It becomes the middleman between the 
Device operator and the Network operator and it should have its own signing
authority. The code running the OEM device may be certified or qualified 
between the OEM operator and the Network operator, totally outside of what the 
device operator has any influence over. Some network operators may even demand 
that the firmware is upgraded at a specific timeline. Not conforming to those 
timelines may lead to the Network operator outright rejecting devices from 
accessing parts of the network functionality.

Some example scenarios for explanation

Scenario 1: Multiple chip update, OEM radio chip
---------

Think of a device with an external OEM radio chip that is only valid in the 
network if it running certain firmware versions. This demand comes from the 
network operator, and is to be enforced by the device operators that use the
OEM radio without subject access to the OEM firmware except accepting a new
signed version from the OEM and adjusting the application to conform to any
changes in API to interface to it.

Both the OEM update and the main application may need to be updated atomically
for the firmware to be applied.

Having multiple signers prevents someone from applying a new firmware version 
on the OEM device out-of-time that may have a catastrophic effect (like an 
incompatible API change). The OEM device firmware is properly signed by the
OEM so it is a valid firmware update, but the addition of the extra authority
from the device operator prevents this from being falsely applied out-of-time.

The device operator is the last in the chain with regards to signing and will
(most likely) have control over when the firmware update process takes place. 
It can only accept or reject based on its own authority, not the authority of
any other signer (which may be accepted/rejected at a later stage in the 
firmware upgrade process).

Scenario: Single chip update, OEM peripheral
---------

If the OEM device is a generic peripheral that shares CPU resources with device
wherein it is used (e.g. for drivers and-or control of the peripheral) it is 
possible that the OEM vendor for the peripheral device wants to have the same
level of control as in the case of an external chip. If the system is complex
enough they may want to give out the firmware to use device under their own
control. An example of this could be a complex communication stack that is 
certified as a whole.

The firmware to run the peripheral may have the same same kind of API 
compatibility scheme you would need as in an IPC to an external chip. The OEM
may want to own all code that is run to interface with the peripheral, e.g.
by signing the firmware delivered to their customers that use the peripherals.

Having a requirement on authority to control when a new firmware is applied by
using multiple signers gives the OEM and the device operator the same level of
security with regards to not applying isolated parts of the firmware 
out-of-time. The device operator will be the last signer in the chains he/she
will be able to control the timeline of when the updates are finally applied 
(and any firmware that needs to be applied in a synchronized manner).

Regards
Frank Audun Kvamtrø

>an unnecessary distinction has been made between critical 
>infrastructure and non-critical infrastructure. Even in non-critical 
>infrastructure, operators would want to the ability to install updates 
>according to their own preferences. In such scenarios, forced 
>installations may violate user’s control of the device. Accordingly, we 
>propose that the device operator SHOULD have the authority to accept or 
>reject firmware updates.

Initially: I don't see forced updates stated anywhere in 3.9. It only talks
about authorization. I do share your sentiment that there is a possible 
complexity in referring the term critical infrastructure, but I do see
where the terms come from. Possibly the wording of this could be simplified
by adding another type of actor (mentioned later in this e-mail)
 
I think the reason the text states MAY and not SHOULD like you propose is to 
support both cases, simple single signer or a multiple of signers

I don't argue that the device operator has the final say on
the synchronization of when a firmware upgrade is to be applied, but I don't 
think that the device operator should invoke an acceptance on behalf of
something that it doesn't have signing rights over. The device operator is the
last signer so he/she has a base acceptance criteria for starting a firmware 
upgrade, but I argue that it may not have rights to accept on behalf of all 
sub-systems described in the firmware upgrade. I feel the standard tries
to do this by describing critical infrastructure and talk about the 

I will try to explain my thinking

CC'ing in Brendan as this is a wider point than the change of wording.

There is probably an operator type that isn't expressed in the architecture 
specification that might make chapter 3.9 and multiple signing authorities a bit
clearer. At least it clears up the use-cases a bit more in my mind. It also
has some impact on the difference between a firmware author and a device operator.
I have problem distinguishing the two in the architecture document and I think 
the role may become clearer if the top level actor is the device operator

I suggest we add the third type of operator, an OEM operator

- OEM Operator: Actor responsible for the day-to-day operation of
 OEM units in devices connected to an IoT network

The distinction I want to make with an OEM operator and a device operator is
that the OEM device is just a sub-system of the device, but authorities around 
the OEM device may be dictated between the OEM and the Network Operator. This
is  different than the relationship between the OEM and the device operator. One
would assume that the device operator wants to have control of the authority to 
accept or reject a firmware upgrade to be able to synchronize when and how
firmware updates are accepted to be applied, but he/she does not need to have full
control of what an OEM device will accept or reject.

The OEM may be dictated by rules of functionality and synchronization of updates
based on requirements from the network operator. It becomes the middleman
between the Device operator and the Network operator and it should have its
own signing authority. The code running the OEM device may be certified or
qualified between the OEM operator and the Network operator, totally outside of 
what the device operator has any influence over. Some network operators may 
even demand that the firmware is upgraded at a specific timeline. Not conforming
to those timelines may lead to the Network operator outright rejecting devices 
from accessing parts of the network functionality.

Some example scenarios to justify this thoughts

Scenario: Justifying requirement of multiple signers: Multiple chip update
---------

Think of a device with an external OEM radio chip that is only valid in the 
network if it running certain firmware versions. This demand comes from the 
network operator, and is to be enforced by the device operators that use the
OEM radio without subject access to the OEM firmware except accepting a new
signed version from the OEM and adjusting the application to conform to any
changes in API to interface to it.

Both the OEM update and the main application may need to be updated atomically.

Having multiple signers prevents someone from applying a new firmware version 
on the OEM device out-of-time that may have a catastrophic effect (like an 
incompatible API change). The OEM device firmware is properly signed by the
OEM so it is a valid firmware update, but the addition of the extra authority
from the device operator prevents this from being falsely applied out-of-time

The device operator is the last in the chain with regards to singing and will
most likely have control over when the firmware update process takes place. It 
can only accept or reject based on its own authority, not the authority of any
other signer (which may be accepted/rejected at a later stage in the firmware 
upgrade process).

Scenario: Justifying requirement of multiple signers: Single chip update
---------

If the OEM device is a generic peripheral that shares CPU resources with device
wherein it is used (e.g. for drivers and-or control of the peripheral) it is 
possible that the OEM vendor for the peripheral device wants to have the same
level of control as in the case of an external chip. If the system is complex
enough they may want to give out the firmware to use device under their own
control. An example of this  could be a complex communication stack that is 
certified as a whole.

The firmware to run the peripheral may have the same same kind of API 
compatibility scheme you would need as in an IPC to an external chip. The OEM
may want to own all code that is run to interface with the peripheral, e.g.
by signing the firmware delivered to their customers that use the peripherals.

Having a requirement on authority to control the application of a new versions
gives the OEM and the device operator the same level of security with regards
to not applying isolated parts of the firmware out-of-time. The device operator 
will be the last signer in the chains he/she will be able to control the 
timeline of when the updates are finally applied (and any firmware that needs
to be applied in a synchronized manner)

Chapter 3.9 should probably have some refreshing of the language and I think 
that it is possible to clear up some misunderstandings.

Regards
Frank Audun Kvamtrø

> -----Original Message-----
> From: Suit [mailto:[email-masked]] On Behalf Of Gurshabad Grover
> Sent: 12. juli 2018 11:42
> To: David Brown <[email-masked]>
> Cc: Sandeep Jha <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Suit] HR Review: Firmware Update Architecture for IoT Devices
> 
> Hi David,
> 
> Thanks. Just to clarify that particular suggestion: we suggested that the
> draft mention that the device operator SHOULD have the ability to accept or
> reject updates, not "MUST".
> 
> In any case, I re-read draft-ietf-suit-architecture, and found the updated
> Section 3.10 useful. Because of the great diversity in the devices in scope
> of the architecture, I understand that it is hard to take a call on whether
> client authorisation is desirable in the general case. We can leave this
> suggestion out.
> 
> Thank you.
> Gurshabad
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Jul 2018 10:04:24 -0400

Gurshabad:

It is clear that we have not come to consensus yet, but I thing some qualifications on the RECOMMENDED or SHOULD statement will be necessary to get there.

Perhaps this is a starting point:  

	When a device is expected to be deployed in a manner that it is directly
	associated with a human, the firmware SHOULD be encrypted to help
	preserve the privacy of that human.

Russ

> On Jul 11, 2018, at 5:30 PM, Gurshabad Grover <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
>

---

From: Gurshabad Grover <[email-masked]>
Date: Sat, 14 Jul 2018 14:00:29 +0530

Hi,

Thank you for engaging with the recommendations.

As I mentioned earlier, the review is a part of the efforts of the Human
Rights Protocol Considerations (HRPC) group. We invite you to the HRPC
session at IETF102, wherein we will have a short discussion of the review.

HRPC Session at IETF102
Date: July 19 (Thursday)
Time: 15:50-17:50 EDT (Afternoon session II)
Room: Duluth
(https://datatracker.ietf.org/meeting/102/floor-plan?room=duluth#2nd-floor-convention-floor-2)
Agenda:
https://datatracker.ietf.org/meeting/102/materials/agenda-102-hrpc-03

Looking forward to hearing your thoughts at the session.

Gurshabad

On Thursday 12 July 2018 03:00 AM, Gurshabad Grover wrote:

> * draft-ietf-suit-information-model-01 [...]

---

From: Brendan Moran <[email-masked]>
Date: Tue, 17 Jul 2018 17:12:55 +0000

I look forward to the output of this discussion. I wish I had been able to cover these questions earlier in the process. I think that there is significant room for addressing the concerns you’ve raised, not least of which is the possibility raised by severing “sensitive” information from a manifest and encrypting it, while leaving the bulk of the manifest in plaintext.

I do have one concern about ensuring privacy where firmware updates are concerned: even the number of manifests or number of unique manifests delivered to a particular building could leak sensitive information. Even correlating data consumption with releases of firmware updates could leak sensitive information. These problems cannot be solved with encryption alone.

I’m hoping to provide a more detailed review soon.

Best Regards,
Brendan

> On 14 Jul 2018, at 09:30, Gurshabad Grover <[email-masked]> wrote:
>
> Hi,
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> 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.

---

From: Gurshabad Grover <[email-masked]>
Date: Wed, 18 Jul 2018 11:21:08 +0530

Russ,

Thank you for suggesting a starting point.

Most of the advantages of encrypting the firmware image are already
highlighted in Section 3.3.13 of draft-ietf-suit-information-model-01.
If the advantages (those + the privacy concern) aren't enough to warrant
a recommendation of firmware encryption in the general case, I am in
favour of adding the sentence you proposed.

Also wanted to flag off that the phrase "must enable" in the section is
potentially confusing: maybe we can replace it with a clear indication
of the requirement level.

Thank you.
Gurshabad