Re: [Suit] Firmware Transport Protocol

[Hannes Tschofenig <[e-mail]>]

Hi Alexander,

A few remarks below:

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

Hi Hannes,


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

Hi Alexander,

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?)

Sounds good.

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

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.

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)

Could you explain your question a bit more?

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?

[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.

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.

Thanks.

Ciao
Hannes


++
Alexander




Ciao
Hannes



++
Alexander



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

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:[e-mail]]
Sent: 24 October 2017 11:09
To: Hannes Tschofenig
Cc: [e-mail]<mailto:[e-mail]>; Suhas Nandakumar
Subject: Re: [Suit] Firmware Transport Protocol

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 <[e-mail]<mailto:[e-mail]>> a écrit :

>  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 <[e-mail]<mailto:[e-mail]>> a écrit :

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:[e-mail]]
Sent: 24 October 2017 09:45
To: Hannes Tschofenig
Cc: Suhas Nandakumar; [e-mail]<mailto:[e-mail]>
Subject: Re: [Suit] Firmware Transport Protocol

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 <[e-mail]<mailto:[e-mail]>> a écrit :

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:[e-mail]] On Behalf Of Suhas Nandakumar
Sent: 24 October 2017 07:32
To: [e-mail]<mailto:[e-mail]>
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. _______________________________________________
Suit mailing list
[e-mail]<mailto:[e-mail]>
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.

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
[e-mail]<mailto:[e-mail]>
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.

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
[e-mail]<mailto:[e-mail]>
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.