Subject: [Suit] Human rights issues and *manifest* encryption

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Aug 2018 11:10:58 -0400

{watching the Youtube video of the WG session from two weeks ago}

I think that there are many specific non-human rights related reasons to
encrypt the firmware.  I think that the WG is in the right direction on that.

Encryption of the manifest is a complex question to me.

My take is that the concern is that if a person is identifiable when they
(or rather, their personal network) asks questions like:
    ** Is there a new firmware for device type X? **
or receives notices like:
    ** In order to do X, your device Y needs firmware at least Z **
    (and this might be done by sending a manifest)

When device type X is a medical device, or some other socially awkward
device (a sex toy, a diaper, etc.) one can easily see why privacy is
important.  As far as I understand, the process of asking questions like
above, and/or receiving notices of new firmware available is explicitely
out-of-scope today.

The problem that I see with encrypting manifests is that either
it prevents much of the supporting infrastructure from being useful (if it's
well encrypted), or the encryption key is so well known as to be a joke.

I suspect that much of the problem can and SHOULD be solved with transport
layer security around the transactions about updates.

I think that the SUIT architecture should deal with this issue, and rule
manifest encryption out of scope, mentioning that the (out of scope)
transport protocol MUST provide transport encryption.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Aug 2018 12:01:06 -0700

> transport protocol MUST provide transport encryption.

I kind of half agree. I don't think that going to the level of "you should encrypt this or that" makes sense. That said, the more I learn about communications on the Internet the more I think they should be encrypted as a class, and I would agree that the obvious tools include TLS or DTLS. If everything is encrypted, the manifest is encrypted, as is the exchange that surrounds it.

It's one thing to get an email saying "your <specific sex toy> needs a firmware upgrade" and another thing to get an email from a company that, on the long list of products of products that it manufactures or sells, includes sex toys. In the latter case, the most one might validly conclude from the metadata is that you have done business in the past with that company.
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 2 Aug 2018 23:48:05 +0000

Everything you say below, Michael, makes sense to me. I agree with your conclusion.

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 02 August 2018 08:11
To: suit
Subject: [Suit] Human rights issues and *manifest* encryption

I think that there are many specific non-human rights related reasons to encrypt the firmware.  I think that the WG is in the right direction on that.

My take is that the concern is that if a person is identifiable when they (or rather, their personal network) asks questions like:
    ** Is there a new firmware for device type X? ** or receives notices like:
    ** In order to do X, your device Y needs firmware at least Z **
    (and this might be done by sending a manifest)

When device type X is a medical device, or some other socially awkward device (a sex toy, a diaper, etc.) one can easily see why privacy is important.  As far as I understand, the process of asking questions like above, and/or receiving notices of new firmware available is explicitely out-of-scope today.

The problem that I see with encrypting manifests is that either it prevents much of the supporting infrastructure from being useful (if it's well encrypted), or the encryption key is so well known as to be a joke.

I suspect that much of the problem can and SHOULD be solved with transport layer security around the transactions about updates.

I think that the SUIT architecture should deal with this issue, and rule manifest encryption out of scope, mentioning that the (out of scope) transport protocol MUST provide transport encryption.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

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: Martin Pagel <[email-masked]>
Date: Thu, 23 Aug 2018 16:43:23 +0000

If a device needs to collect updated images from multiple source servers, privacy may be at stake as a sex toy may request an updated image from its manufacturer. But that exposure even applies if the manifest is encrypted. 

However a centralized Update Server would hide such traffic exposure and I believe channel encryption / transport layer security would then be sufficient. 

Martin

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 02 August 2018 08:11
To: suit
Subject: [Suit] Human rights issues and *manifest* encryption

_______________________________________________
Suit mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ceb92920d114e4ca6253508d5f8d26c15%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636688505018117746&amp;sdata=U6P1KScm4IDtA5WK%2FxPHeX29d5peZwKIO4O%2FD843Jok%3D&amp;reserved=0