Subject: [Suit] Follow-up re: my comment on charter and software sources and permissions

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Nov 2017 17:10:19 +0800

The meeting is running out of time. 

But I wanted to followup to the discussion relating to my comment on the mic.

Hannes had responded by saying that we cannot specify who the potential sources are.

That wasn’t what I suggested or said. I would like the charter to say that there’s sufficient expressive power in the format to handle situations that go beyond the 1 source 1 permission case. The architecture draft already talks about this, although from a slightly different angle. The actual potential sources and styles of permissions are up to individual deployments. What we do in the IETF is capabilities, in formats and protocols and so on to enable individual deployments to express their situation with our tools. Obviously within some reasonable limits, given that we are talking about small, constrained devices.

I was thinking of something along the following lines:

"The format is expected to be expressive enough to allow the use of different software sources and permission models."

Jari

---

From: Madjid Nakhjiri <[email-masked]>
Date: Mon, 13 Nov 2017 22:09:31 +0000

Hi Jari, 

Sorry, I am catching up on the context, as I subscribed a few days ago.
Can anybody point me to where examples for permission models are described?

Regards,
Madjid Nakhjiri, 
Sr. Director, ARTIK Security Architect

On 11/13/17, 1:10 AM, "Suit on behalf of Jari Arkko"
<[email-masked] on behalf of [email-masked]> wrote:

>That wasn¹t what I suggested or said. I would like the charter to say
>that there¹s sufficient expressive power in the format to handle
>situations that go beyond the 1 source 1 permission case. The
>architecture draft already talks about this, although from a slightly
>different angle. The actual potential sources and styles of permissions
>are up to individual deployments. What we do in the IETF is capabilities,
>in formats and protocols and so on to enable individual deployments to
>express their situation with our tools. Obviously within some reasonable
>limits, given that we are talking about small, constrained devices.
>
>"The format is expected to be expressive enough to allow the use of
>different software sources and permission models."
>
>Jari
>
>_______________________________________________
>Suit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/suit

---

From: Eliot Lear <[email-masked]>
Date: Tue, 14 Nov 2017 10:15:49 +0800

Hi Jari,

> "The format is expected to be expressive enough to allow the use of different software sources and permission models."

I wasn't in the room for the whole discussion, but I presume there are
two possible use cases here:

  * the case where a particular deployment wants to authorize and
    inventory specific releases for a given set of devices; and
  * the case where a manufacturer is about to drop dead, and you want
    someone else to be able to continue development in a deployable fashion.

Is this something where what we are really talking about is just
cross-signed signing certificates?  The reason I'm asking is that it
would be good to scope DOWN the work where possible.  The point is that
if we are able to scope toe work to at least prefer as much existing
infrastructure where practicable, that would be good.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 06:28:08 +0000

Hi Jari,

I understood your question in the following way and please correct me if I got it wrong.

You wanted a device to be updated by parties other than the manufacturer.

I clarified that the term "manufacturer" is a bit too generic since there are many parties responsible for manufacturing a device.
Who is, however, allowed to update a device is a policy decision but I am happy to explicitly write about this.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: 13 November 2017 17:10
To: [email-masked]
Subject: [Suit] Follow-up re: my comment on charter and software sources and permissions

Jari

_______________________________________________
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: Jari Arkko <[email-masked]>
Date: Tue, 14 Nov 2017 14:42:41 +0800

Hannes — the manufacturer example was just that, an example. I definitely agree that we shouldn’t write anything about manufacturers or owners! What I’d like to have, however, is a recognition that there’s a need to support a bit more expressive power in our mechanisms to support some of the cases that can come up. I sent some suggested text earlier in this thread, but other text would work as well.

Madjid — I was thinking of the kinds of permission models that e.g., the architecture draft (draft-moran-suit-architecture) talks about in Section 3.7. That example is from a slightly different use case than I had in mind, but it is another example.

Jari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 06:47:52 +0000

Hi Jari,

I believe I understand where you are heading with your remarks.

The question to me is whether this is something that has to go into the charter text or into a document of the group.

Ciao
Hannes

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: 14 November 2017 14:43
To: Hannes Tschofenig; Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Suit] Follow-up re: my comment on charter and software sources and permissions

Jari

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 14 Nov 2017 07:03:25 +0000

Given that we are working to post updated charter text in the next couple days for review, it would be good to hear about any concerns with or support for adding Jari's text to the charter. Please also indicate if you would like to see adjusted text instead.

Thanks,

Dave

________________________________
From: Suit <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Sent: Tuesday, November 14, 2017 2:47 PM
To: Jari Arkko; Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Suit] Follow-up re: my comment on charter and software sources and permissions

Hi Jari,

Ciao
Hannes

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: 14 November 2017 14:43
To: Hannes Tschofenig; Madjid Nakhjiri
Cc: [email-masked]
Subject: Re: [Suit] Follow-up re: my comment on charter and software sources and permissions

Jari

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
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdavid.waltermire%40nist.gov%7C9692f18aca764711c63108d52b2ba5f7%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636462388821450489&sdata=y0f44wdKDfaCxtsplZ1iwjTULuoiHFw%2F7F381mjTZIE%3D&reserved=0

---

From: Brendan Moran <[email-masked]>
Date: Tue, 14 Nov 2017 09:43:04 +0000

While I am happy with Jari’s text in principle, I’d like to know what he intended by “software sources” prior to inclusion in the charter text.

Best Regards,
Brendan

On 14 Nov 2017, at 07:03, Waltermire, David A. (Fed) <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Dave

________________________________
From: Suit <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 14, 2017 2:47 PM
To: Jari Arkko; Madjid Nakhjiri
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Follow-up re: my comment on charter and software sources and permissions

Hi Jari,

Ciao
Hannes

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: 14 November 2017 14:43
To: Hannes Tschofenig; Madjid Nakhjiri
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Follow-up re: my comment on charter and software sources and permissions

Jari

[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Nov 2017 18:16:42 +0800

> While I am happy with Jari’s text in principle, I’d like to know what he intended by “software sources” prior to inclusion in the charter text.

I meant the abstract notion of being able to process images that came possibly from different entities (e.g., a device is capable of accepting a firmware signed by either your IT department or the vendor). I did *not* mean software sources in any server, TFTP-server IP address or similar sense :-)

Jari

---

From: Brendan Moran <[email-masked]>
Date: Tue, 14 Nov 2017 11:11:53 +0000

> On 14 Nov 2017, at 10:16, Jari Arkko <[email-masked]> wrote:
>
>

Hi Jari,
That is what I suspected. Would it be alright to change the phrasing to either of these so it’s a bit more clear?

> "The format is expected to be expressive enough to allow the use of diverse update authorities and permission models."
OR
> "The format is expected to be expressive enough to allow the use of diverse update authors and permission models."

Best Regards,
Brendan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Nov 2017 14:00:33 -0500

Jari Arkko <[email-masked]> wrote:
    > Hannes — the manufacturer example was just that, an example. I
    > definitely agree that we shouldn’t write anything about manufacturers
    > or owners! What I’d like to have, however, is a recognition that
    > there’s a need to support a bit more expressive power in our mechanisms
    > to support some of the cases that can come up. I sent some suggested
    > text earlier in this thread, but other text would work as well.

For instance, a manufacturer might provide ten different images that are
signed.  (Different versions and/or feature sets, or even because the same
valve controller is used in both sewage and building control...)

The operator of the building/sewage system might get to select among them.

Then iterate (recursive really) for the fact that the we might have a
compound device which contains many such valves in different configurations,
requiring different feature sets within the same manifest.

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

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 14 Nov 2017 21:37:34 +0000

Hi Jari, 

Ok. Thanks for pointing me to the permissions in the architecture draft.
Some the permissions are fuzzy to me, e.g. Approve or qualify. Are we
expecting that level of complexity? Approve but not apply? I could think
of say store but not apply (install) yet, which could be solved with some
timing information in the metadata.

These permissions are making the job of a update manager module (sorry for
the invented term) much more complex. I personally would think of a
permission system as policies that allows device HW/SW to perform or
reject some actions requested by a requestor. Examples: install, execute,
etc. Implementing multiple signatures (e.g. from both code author and
device operator) would be straight forward, as a signature would
implicitly mean approval.

What use case did you have in  mind?

Hannes, I guess more description on the permissions would clarify this
better.

Regards,
Madjid Nakhjiri, 

On 11/13/17, 10:42 PM, "Jari Arkko" <[email-masked]> wrote:

>Hannes ‹ the manufacturer example was just that, an example. I definitely
>agree that we shouldn¹t write anything about manufacturers or owners!
>What I¹d like to have, however, is a recognition that there¹s a need to
>support a bit more expressive power in our mechanisms to support some of
>the cases that can come up. I sent some suggested text earlier in this
>thread, but other text would work as well.
>
>Madjid ‹ I was thinking of the kinds of permission models that e.g., the
>architecture draft (draft-moran-suit-architecture) talks about in Section
>3.7. That example is from a slightly different use case than I had in
>mind, but it is another example.
>
>Jari
>
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 23:27:50 +0000

Hi Jari,

~snip~

> a device is capable of accepting a firmware signed by either your IT department or the vendor

Thanks for the clarification. Yes, it makes sense to me that additional parties need to approve the firmware update at a device. Whether this always requires a multi-signature approach is a secondary question.

Ciao
Hannes

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Nov 2017 00:57:19 +0100

Client<->controller connection. Allow initiation from either side,
individual client device (classes) may support only one direction.

Controller retrieves necessary information from device to make decision
what firmware to use on device. Tells device what firmware to use. URL
or direct download.

As soon as you start trying to embed firmware selection decision mechanisms
into the device itself, you've just created IMHO another dead end solution.

If you do not automate retrieval of all decision parameters that can be
automated, you are wasting money and reliability into manual processes.

Not all automated information retrieval needs to be from device itself,
a lot could be in manufacturing databases, but if you can not guarantee
that the decision maker can reliably automatically retrieve it, a protocol
with the device itself should provide this information.

yada yada yada. This is the type of architectural outline stuff i would love
to see in a firmware download RFC.

On Tue, Nov 14, 2017 at 02:00:33PM -0500, Michael Richardson wrote:
>     > Hannes ??? the manufacturer example was just that, an example. I
>     > definitely agree that we shouldn???t write anything about manufacturers
>     > or owners! What I???d like to have, however, is a recognition that
>     > there???s a need to support a bit more expressive power in our mechanisms

-- 
---
[email-masked]

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 15 Nov 2017 00:22:27 +0000

Is this an example for permissions? Or a use case for multiple signatures?

 why can¹t sewage versus building control information be included in
metadata (manifest) of the image? The devices come with model numbers and
the device configuration would know based on the metadata whether it
should install a package or not. Plus, I would think the device would be
notified that an update is available and then it goes and pulls the
update. Rather than a distribution server just blasts data to all devices
(sewage or building  and it is up to each device to figure out whether it
is the target for an image or not. I am not sure if that is the most
efficient way to handle network bandwidth or device battery/ bandwidth.

Regards,
Madjid Nakhjiri, 

On 11/14/17, 11:00 AM, "Suit on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>    > Hannes ‹ the manufacturer example was just that, an example. I
>    > definitely agree that we shouldn¹t write anything about
>manufacturers
>    > or owners! What I¹d like to have, however, is a recognition that
>    > there¹s a need to support a bit more expressive power in our
>mechanisms

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 15 Nov 2017 17:29:49 +0000

Hi Brendan, 

Sorry for jumping in. to me ³Author² has more to do with the source
(signing), whereas ³ authority² has more to do with the operations:
distribution server the image came from, or polled the device to go fetch
the update (e.g. Device management operator). So depends on what you want
to mean!!
Still, I have a hard time to see how some of the permissions are enforced.

Regards,
Madjid Nakhjiri, 

On 11/14/17, 3:11 AM, "Suit on behalf of Brendan Moran"
<[email-masked] on behalf of [email-masked]> wrote:

>>> While I am happy with Jari¹s text in principle, I¹d like to know what
>>>he intended by ³software sources² prior to inclusion in the charter
>>>text.
>>
>> I meant the abstract notion of being able to process images that came
>>possibly from different entities (e.g., a device is capable of accepting
>>a firmware signed by either your IT department or the vendor). I did
>>*not* mean software sources in any server, TFTP-server IP address or
>>similar sense :-)
>>
>> Jari
>
>Hi Jari,
>That is what I suspected. Would it be alright to change the phrasing to
>either of these so it¹s a bit more clear?
>
>>diverse update authorities and permission models."
>OR
>>diverse update authors and permission models."
>
>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.