Subject: Re: [Last-Call] Last Call: <draft-ietf-suit-architecture-11.txt> (A Firmware Update Architecture for Internet of Things) to Informational RFC

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Oct 2020 09:15:23 +1300

Hi,

I can't see any changes in the proposed -13 version that respond to my comments below. I do see that the example that suggested operating without a status tracker has vanished. If the status tracker is now considered essential, that probably needs to be stated. But I still don't understand how the target device and the status tracker (or server) discover each other. This seems like a fundamental part of the architecture.

Regards
   Brian Carpenter

On 29-Sep-20 11:34, Brian E Carpenter wrote:
> Hi,
> 
> I can't see any changes in the -12 version that respond to my comments below.
> 
> Regards
>    Brian Carpenter
> 
> On 25-Jul-20 11:31, Brian E Carpenter wrote:
>> Hi,
>>
>> I don't understand from the architecture discussion how a firmware
>> consumer discovers the firmware server, especially in the unmanaged
>> (no status tracker) case. It can't be preconfigured, in case the
>> firmware server changes for some reason.
>>
>> Not unrelated:
>>
>>> Installing trust anchors to
>>> devices via the Trust Provisioning Authority happens in an out-of-
>>> band fashion prior to the firmware update process.
>>
>> What happens when the firmware originator goes out of business
>> and somebody else takes over support, or for any other reason
>> the trust anchors become obsolete?
>>
>> Regards
>>    Brian Carpenter
>>
>> On 25-Jul-20 10:30, The IESG wrote:
>>>
>>> The IESG has received a request from the Software Updates for Internet of
>>> Things WG (suit) to consider the following document: - 'A Firmware Update
>>> Architecture for Internet of Things'
>>>   <draft-ietf-suit-architecture-11.txt> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> [email-masked] mailing lists by 2020-08-14. Exceptionally, comments may
>>> be sent to [email-masked] instead. In either case, please retain the beginning
>>> of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    Vulnerabilities with Internet of Things (IoT) devices have raised the
>>>    need for a solid and secure firmware update mechanism that is also
>>>    suitable for constrained devices.  Incorporating such update
>>>    mechanism to fix vulnerabilities, to update configuration settings as
>>>    well as adding new functionality is recommended by security experts.
>>>
>>>    This document lists requirements and describes an architecture for a
>>>    firmware update mechanism suitable for IoT devices.  The architecture
>>>    is agnostic to the transport of the firmware images and associated
>>>    meta-data.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
>>>
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 14 Oct 2020 06:25:18 +0000

Hi Brian,

For the distributed version I have focused on addressing comments raised by Bob first.

However, I have changed the definition of the status tracker and it is not an optional component anymore.

Here is the new definition:

   -  Status Tracker: The status tracker has a client and a server
      component and performs three tasks: 1) It communicates the
      availability of a new firmware version.  This information will
      flow from the server to the client.
      2) It conveys information about software and hardware
      characteristics of the device.  The information flow is from the
      client to the server.
      3) It can remotely trigger the firmware update process.  The
      information flow is from the server to the client.

You wrote: "But I still don't understand how the target device and the status tracker (or server) discover each other."

The discovery today works mostly by using pre-configured servers. However, dynamic discovery techniques have been proposed (e.g. in ANIMA and in FIDO).

I hope this makes sense.

Ciao
Hannes

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Sent: Tuesday, October 13, 2020 10:15 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]; [email-masked]; Bob Briscoe <[email-masked]>
Subject: Re: Last Call: <draft-ietf-suit-architecture-11.txt> (A Firmware Update Architecture for Internet of Things) to Informational RFC

Hi,

Regards
   Brian Carpenter

On 29-Sep-20 11:34, Brian E Carpenter wrote:
>> What happens when the firmware originator goes out of business and
>> somebody else takes over support, or for any other reason the trust
>> anchors become obsolete?
>>
>> Regards
>>    Brian Carpenter
>>
>>> The IESG has received a request from the Software Updates for
>>> Internet of Things WG (suit) to consider the following document: -
>>> 'A Firmware Update Architecture for Internet of Things'
>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits final comments on this action. Please send substantive
>>> comments to the [email-masked] mailing lists by 2020-08-14.
>>> Exceptionally, comments may be sent to [email-masked] instead. In
>>> either case, please retain the beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
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: Brendan Moran <[email-masked]>
Date: Wed, 21 Oct 2020 14:24:12 +0000

Hi Brian,

This can be done either using per-configured hosts, or using a discovery mechanism such as DNS-SD:
> Devices also require a mechanism to
>    discover the status tracker(s) and/or firmware servers, for example
>    using pre-configured hostnames or [RFC6763] DNS-SD.

And, for the second comment

This is addressed (perhaps somewhat indirectly) in the list of areas that fall outside the IETF’s efforts, but do require consideration:
>    *  Ensuring that firmware updates addressing critical flaws can be
>       obtained even after a product is discontinued or a vendor goes out
>       of business.

Fundamentally, this requirement must be enabled by the trust provisioning authority. They must be responsible for ensuring continuity of service in the event that a firmware author becomes unresponsive to defects for any reason.

Best Regards,
Brendan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Oct 2020 10:18:16 +1300

Hi Brendan,

>>    using pre-configured hostnames or [RFC6763] DNS-SD.

Thanks. As I mentioned, this is also a problem we could easily solve with the ANIMA mechanisms too, in a fully autonomic network.
 
> Fundamentally, this requirement must be enabled by the trust provisioning authority. They must be responsible for ensuring continuity of service in the event that a firmware author becomes unrespon…

Yes, that covers it I think. For information only, ANIMA has a similar problem, discussed at https://www.ietf.org/archive/id/draft-ietf-anima-bootstrapping-keyinfra-44.html#name-updating-or-extending-vouch

Thanks
    Brian