Re: [Suit] Firmware Update Paper

Michael Richardson <> Tue, 03 December 2019 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42465120044 for <>; Tue, 3 Dec 2019 13:57:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SphHSvGaHaHU for <>; Tue, 3 Dec 2019 13:57:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BC7512003E for <>; Tue, 3 Dec 2019 13:57:08 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 9D7DF3818F; Tue, 3 Dec 2019 16:53:30 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id B0F71784; Tue, 3 Dec 2019 16:57:06 -0500 (EST)
From: Michael Richardson <>
to: Emmanuel Baccelli <>, "suit\" <>, Brendan Moran <>
In-Reply-To: <23912.1575379400@localhost>
References: <> <> <> <> <> <> <> <23912.1575379400@localhost>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 03 Dec 2019 16:57:06 -0500
Message-ID: <5735.1575410226@localhost>
Archived-At: <>
Subject: Re: [Suit] Firmware Update Paper
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2019 21:57:10 -0000

Michael Richardson <> wrote:
    > Emmanuel Baccelli <> wrote:
    >> in the paper [1] for our experiements we used CoAP as transport, over UDP,
    >> 6LoWPAN and IEEE 802.15.4 low power radio.

    > CoAP Block Mode?

Hi, I know that you answered, and I actually posted my question before I had
finished all of the paper :-)
(That's a new kind of pie chart you've used...)

As I understand it, in the pure-CoAP scenario you provided an endpoint to
which the SUIT manifest was pushed (using Block1).   The target device then
evaluated the manifest, and if it validated and was new, then it downloaded
the new firmware.

Similarly, the same thing was done with a LwM2M-OTA situation.
Neither situation had any transport security (DTLS), and relied upon the
verification of the manifest.  So we had end-to-end integrity, but no

Of course, the 802.15.4 network could have L2 security... did you have that?
I'm asking because it's an additional crypto load.

At this point quite a number of people would like to standardized some
transport for SUIT manifests for use in some situations like you have described.
That was deemed outside the scope for the current SUIT effort (and I agreed
with the reasons at the time), and I wouldn't expect everyone to agree to use
it.   Some have expected OCF or another to do something here.

I wonder if there is interest in doing things at the IETF?

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-