Subject: [Suit] Firmware Transport Protocol

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 23 Oct 2017 22:31:37 -0700

On the protocol to transport firmware, the vast majority of firmware
updates we see  the industry using run over tftp and http with perhaps coap
in the future. We think the charter need to explicitly allow for a design
that allows any one of those three to be use by the IoT device and is to be
clear how they are each used.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 07:20:42 +0000

Hi Suhas,

The beauty of the charter text is that it already allows any transport mechanism to be used.

While home routers use HTTP and TFTP lower end IoT devices use CoAP or distribute the firmware images directly over the link layer protocol. See, for example, a recent write-up from my co-worker where he is using the firmware manifest we described and implemented over LoRa with differential updates: https://os.mbed.com/blog/entry/towards-fota-lora-crypto-delta-updates/

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 24 October 2017 07:32
To: [email-masked]
Subject: [Suit] Firmware Transport Protocol

On the protocol to transport firmware, the vast majority of firmware updates we see  the industry using run over tftp and http with perhaps coap in the future. We think the charter need to explicitly allow for a design that allows any one of those three to be use by the IoT device and is to be clear how they are each used.

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: Alexander Pelov <[email-masked]>
Date: Tue, 24 Oct 2017 09:45:27 +0200

Dear Hannes,

Thanks for clarifying some of the points and for getting the work started!

Just for my understanding, if I over-simplify, the goal si to define a manifest format (will all the behavior that is related to it) necessary to perform secure firmware update for IoT, is this correct?

(I imagine the way bindings are defined to the actual L2/L3 protocols that perform the update would be defined in the manifest file)

Best,
Alexander

> Le 24 oct. 2017 à 09:20, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi Suhas,
>  
> While home routers use HTTP and TFTP lower end IoT devices use CoAP or distribute the firmware images directly over the link layer protocol. See, for example, a recent write-up from my co-worker where he is using the firmware manifest we described and implemented over LoRa with differential updates: https://os.mbed.com/blog/entry/towards-fota-lora-crypto-delta-updates/ <https://os.mbed.com/blog/entry/towards-fota-lora-crypto-delta-updates/>
>  
> Ciao
> Hannes
>   <>
> From: Suit [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Suhas Nandakumar
> To: [email-masked] <mailto:[email-masked]>
> 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] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 07:56:24 +0000

Hi Alexander,

I believe the work has to start somewhere.

What do we have today?

If you are using a general purpose OS, like Linux, then there are lots of software/firmware update mechanisms available. I know that there are still problems with using them on devices like home routers but those problems are often related to non-technical aspects, such as discontinued support or pushing updates through the long value chain. (This problem has even been recognized with smart phones.)

Furthermore, there are also various “transports” for getting a firmware image from A-to-B.

Hence, I had suggested to focus on the gaps that exist today, namely a standardized firmware format for use with low end IoT devices.
Before we started our implementation work more than 2 years ago there was not much available in terms of standardized formats. Hence, we used RFC 4108 as a starting point.

If we manage to complete this part of the work we will then be able to use it with a number of transports. Cisco may prefer a HTTPS based communication with the firmware update server pre-configured. We continue use our LwM2M approach with CoAP. Maybe someone else will switch to QUIC in the future or (as some of the low power WAN guys do) just shuffle it over their radio without using IP.

Does this make sense?

Ciao
Hannes

From: Alexander Pelov [mailto:[email-masked]]
Sent: 24 October 2017 09:45
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]
Subject: Re: [Suit] Firmware Transport Protocol

Dear Hannes,

Best,
Alexander

Le 24 oct. 2017 à 09:20, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Suhas,

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 24 October 2017 07:32
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Firmware Transport Protocol

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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 24 Oct 2017 10:00:20 +0200

Hi Hannes,

Thanks for the quick reply! Ok, I think I understand a little bit better.

So, it’s about the File Format that contains the firmware? (so that we have nice things, such as signing, verification, delta-updates, and so forth ?)

Alexander

> Le 24 oct. 2017 à 09:56, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi Alexander,
>  
> From: Alexander Pelov [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Suhas Nandakumar; [email-masked] <mailto:[email-masked]>
> Le 24 oct. 2017 à 09:20, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Suhas,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 08:28:55 +0000

Ø  Thanks for the quick reply! Ok, I think I understand a little bit better.

Ø  So, it’s about the File Format that contains the firmware? (so that we have nice things, such as signing, verification, delta-updates, and so forth ?)

Yes, it is pretty easy to understand. Just try to implement a firmware update mechanism and you will notice that the security part is the complex part. That’s probably not super surprising since we made this observation already numerous times already with other work in the IETF.

If you want to know the details of what we have implemented, just take a look at https://tools.ietf.org/html/draft-moran-fud-manifest-00. As mentioned earlier, we are polishing our code right now and will release it as open source (Apache 2 license).

Ciao
Hannes

Alexander

Le 24 oct. 2017 à 09:56, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander,

What do we have today?

Does this make sense?

Ciao
Hannes

From: Alexander Pelov [mailto:[email-masked]]
Sent: 24 October 2017 09:45
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Firmware Transport Protocol

Dear Hannes,

Best,
Alexander

Hi Suhas,

Ciao
Hannes

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 24 Oct 2017 11:08:32 +0200

Oh, I see, sounds good !

For information - during the last Yang of Things meeting (which very unfortunately was in the same time slot as FUD), we discussed the use of YANG model for this description. (the manifest file then can be expressed in CBOR, XML, or JSON.. (I’ll be tempted to default to CBOR).

Do you think this could be something of interest for the BoF and for the follow-up of Suit ?

Alexander

> Le 24 oct. 2017 à 10:28, Hannes Tschofenig <[email-masked]> a écrit :
> 
> If you want to know the details of what we have implemented, just take a look at https://tools.ietf.org/html/draft-moran-fud-manifest-00 <https://tools.ietf.org/html/draft-moran-fud-manifest-00>. As mentioned earlier, we are polishing our code right now and will release it as open source (Apache 2 license).
>  
> Ciao
> Hannes
>  
> Alexander
>  
>  
> Le 24 oct. 2017 à 09:56, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander,
>  
> [email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 10:39:00 +0000

Hi Alexander,

we have actually thought about exactly doing the same as well (in the anticipation that the usual encoding discussion comes up). Unfortunately, our Yang language expertise is a bit limited. (Note that our interest was really only in Yang as a language for describing the format rather than in anything else.)

While the encoding appears to be a fundamental thing it is actually just a distraction from discussing the semantics of the fields and the security stuff.

Regarding your preference for CBOR I will ask you the same question as I did to Suhas: do you have actually any reasons?

Ciao
Hannes

From: Alexander Pelov [mailto:[email-masked]]
Sent: 24 October 2017 11:09
To: Hannes Tschofenig
Cc: [email-masked]; Suhas Nandakumar
Subject: Re: [Suit] Firmware Transport Protocol

Oh, I see, sounds good !

Alexander

Ciao
Hannes

Alexander

Hi Alexander,

What do we have today?

Does this make sense?

Ciao
Hannes

Dear Hannes,

Best,
Alexander

Hi Suhas,

Ciao
Hannes

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 24 Oct 2017 12:46:53 +0200

Great! So I think we can converge on the YANG part and if necessary we can work on it together (there will probably be a YoT side meeting during IETF 100, so we can actually try to prepare this ahead of the BoF?)

On the encoding: we’re using CBOR in the application layer, so there are already CBOR encoders in place. 
I am not sure if we can actually live without ASN.1 (e.g. if we don’t need X.501 certificates and all the rest)..

But this actually brings up an interesting question:
- What are the requirements for the manifest file 

(because, if you but ASN.1 or CBOR there, then it becomes a MUST for the end-device to support it)

++
Alexander

> Le 24 oct. 2017 à 12:39, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi Alexander,
>  
> Le 24 oct. 2017 à 10:28, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> a écrit :
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 10:59:00 +0000

Hi Alexander,

Sounds good.

You would need COSE in addition since CBOR itself just defines the encoding.

Currently our description explains what we had implemented and the solution is based on asymmetric crypto and the use of X.509 certificates. While it is possible to use raw public keys our experience with the industrial sector has been that they are somewhat conservative and want to re-use their existing infrastructure. When you use X.509 certs then you will also have an ASN.1 parser. Even if you use COSE you are most likely going to have an ASN.1 parser since the requirements for X.509 certs will not magically go away when you switch to a different encoding.

As a consequence, yo you will have to implement COSE, CBOR, and the ASN.1 parser. Furthermore, the functionality of a firmware update mechanism makes it quite security sensitive and hence you will put the code into the bootloader (Brendan provided more details in earlier email exchanges on the FUD list). ASN.1 parsers are widely available (since they are part of every security stack these days) and their quality is quite high.

We raised the question about the use of symmetric key cryptography since this is something we had mixed feelings about but nobody responded. On one hand it is a more efficient mechanism but on the other hand it provides weaker security properties.

Could you explain your question a bit more?

Ciao
Hannes

++
Alexander

Le 24 oct. 2017 à 12:39, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander,

Ciao
Hannes

From: Alexander Pelov [mailto:[email-masked]]
Sent: 24 October 2017 11:09
To: Hannes Tschofenig
Cc: [email-masked]<mailto:[email-masked]>; Suhas Nandakumar
Subject: Re: [Suit] Firmware Transport Protocol

Oh, I see, sounds good !

Alexander

Ciao
Hannes

Alexander

Hi Alexander,

What do we have today?

Does this make sense?

Ciao
Hannes

Dear Hannes,

Best,
Alexander

Hi Suhas,

Ciao
Hannes

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 24 Oct 2017 06:44:18 -0600

> On Oct 24, 2017, at 3:08 AM, Alexander Pelov <[email-masked]> wrote:
> 
> Oh, I see, sounds good !
> 

 A bunch of the management systems that need to deal with keeping track of what is running on the IoT device and more and more moving to yang so I think that would be very well worth considering as  a way to express the data model for the manifest.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 12:51:25 +0000

> A bunch of the management systems that need to deal with keeping track of what is running on the IoT device and more and more moving to yang so I think that would be very well worth considering as…

Note that Alexander was proposing "Yang" as the data modelling language, see https://www.iab.org/wp-content/IAB-uploads/2016/03/IoT-yang-bclaise.pdf.
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: Alexander Pelov <[email-masked]>
Date: Tue, 24 Oct 2017 18:34:23 +0200

Hi Hannes,

> Le 24 oct. 2017 à 12:59, Hannes Tschofenig <[email-masked]> a écrit :
> 
> Hi Alexander,
>  

Thanks for the detailed explanation. Actually it is what I meant by saying about the ‘MUST’ statement.

The question is, will a device which supports SUIT be required to implement X.501 certificates? (I am not against - I like them quite a lot).
Another way to say it - what is the scope of SUIT? Is it X.509-only based firmware update system for IoT? (including the future architecture that will be defined and so forth)?

Are we going to start with X.509 and then add other as we continue?

Is the focus primarily on the Manifest file (and thus, the importance to chose one path), or is it on the process (and thus potentially allow for several mechanisms)?

I don’t think we should make a complex solution - and I would encourage a simple one that works. I think it would benefit if we try to narrow down before / during the BoF on these points.

++
Alexander

>  
> Ciao
> Hannes
>  
>  
>  
> ++
> Alexander
>  
>  
>  
> Le 24 oct. 2017 à 12:39, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> a écrit :
>  
> Hi Alexander,
>  
> Cc: [email-masked] <mailto:[email-masked]>; Suhas Nandakumar
> 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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Oct 2017 16:45:32 +0000

Hi Alexander,

A few remarks below:

From: Alexander Pelov [mailto:[email-masked]]
Sent: 24 October 2017 18:34
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [email-masked]
Subject: Re: [Suit] Firmware Transport Protocol

Hi Hannes,

Le 24 oct. 2017 à 12:59, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Alexander,

Sounds good.

[Hannes] The charter leaves this open for discussion by the folks involved in the group. Only because we have implemented an X.509-based solution doesn’t mean everyone should do the same. The draft also allows for the use of raw public keys. We understand the desire to have something more lightweight but at the same time everyone wants to have it secure as well, which is a challenge with a plain PSK-based mechanism.

Is the focus primarily on the Manifest file (and thus, the importance to chose one path), or is it on the process (and thus potentially allow for several mechanisms)?
As currently proposed it is focused on the manifest format, which includes the security wrapper. It is not focused on the process, since standardizing processes is not something the IETF is particularly great at.

Thanks.

Ciao
Hannes

++
Alexander

Ciao
Hannes

++
Alexander

Hi Alexander,

Ciao
Hannes

Oh, I see, sounds good !

Alexander

Ciao
Hannes

Alexander

Hi Alexander,

What do we have today?

Does this make sense?

Ciao
Hannes

Dear Hannes,

Best,
Alexander

Hi Suhas,

Ciao
Hannes