{Please no negative aspersions were intended!}
Brendan Moran <[email protected]> wrote:
> I think there may be some misconceptions about SUIT here.
So, let's distinguish what draft-ietf-suit-manifest-07 *CAN* do, from what
the *SUIT* *WG* needs to be able to defend.
So, we often articially limit applicability for solutions in order to be able to
get complete coverage, particularly when it comes to Security Considerations.
We then can come back, write a new applicability statement and extend usage.
It is my understanding that this is what the WG is doing.
>> This group will focus on defining a firmware update solution (taking into
>> account past learnings from RFC 4108 and other firmware update
solutions) that
>> will be usable on Class 1 (as defined in RFC 7228) devices, i.e.,
devices with
>> ~10 KiB RAM and ~100 KiB flash. The solution may apply to more capable
devices
>> as well.
> The suit manifest does, happily, apply to more capable devices. The
> suit manifest is, in principle, being adopted in TEEP, which targets
> more capable devices.
Yes, that's definitely true. And quite reasonably the things which are
deployed into the secure enclaves managed by the TEEP Agent might look a lot
like "APPs", and I would not fault some marketing person who wanted to call
them "Trusted Apps" [Afterall, we more or less call them that in the TEEP
Intro, and then use the term TA from when on], but, there is a lot of
difference in the attack surface for a TEEP TA than for an Android APK due to
the number of linkages to other services in Android, the use of Dalvik VM
(and it's replacement whose name I've forgotten), down to the libc that it
uses and the kernel underneath.
> Certainly, the design of suit was explicitly intended to target Class 1
> devices, however I am not aware of any missing feature or any missing
> functionality that would inherently restrict SUIT from being used for
> many component, high capability systems.
> I see no inherent problem with using suit manifests to deploy
> smartphone apps, docker containers, VM images, linux packages, kernel
> images, recovery partitions or bootloaders.
In SUIT we have stayed away from saying anything about the contents of the
blob. It can be a compressed file system, Intel HEX code, or even tar.gz.
What I *think* that we agree is that there ought *not* be 1292 blobs,
each one a different *file*. It wouldn't be wrong, and it probably would
work, but if it turned out it was O(n^2) [or O(2^n)!] in the number of blobs,
then that would be a concern, wouldn't it? I haven't thought about this, nor
do I expect to, since I think n<10.
So, I did say *specifically* that I do expect to use SUIT for:
docker containers
VM images
kernel images
recovery partitions
bootloaders
I'm less sure that it should admit that it can be used for apps and linux
packages, because I'm very much certain that the Security Considerations for
some of this will overwhelm us, and overwhelm the readers.
In particular the dependancy relationship that often needs to be expressed
can be quite complex. Can our MANIFEST be extended to support it? I'm
sure. Should we spend the time now?
No, because, I don't think those constituencies want to replace what they have
now.
> Please could you explain what the problem you see is that would make
> suit inappropriate for smartphone apps or many-component systems.
I hope that I have explained myself.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
