Subject: [Suit] Possible additional considerations for Suit

From: "Dr. Pala" <[email-masked]>
Date: Mon, 13 Nov 2017 15:15:02 +0800

Hi all,

after reading the material for the meeting, few high-level 
considerations popped into my mind that I think it might be useful to 
raise early. Here's the laundry list:

  * *Device Credentials for Firmware Access.* It seems that an
    alternative to per-device encryption is the possibility of allowing
    only authenticated devices to access/download/retrieve the firmware
    itself (This requires a transport protocol that would support the
    use of device-provided credentials)

  * *IP vs. non-IP Devices.* I wonder if some special considerations
    shall be given for IP vs. non-IP devices that might still be
    targeted for data extraction via device gateways.

  * *Firmware and Deployment.* How to allow for separation of device
    manufacturer firmware validation and deployment enabling in selected
    environments (i.e., another way to target the deployment of the
    firmware). For example, environments where deployment of the
    update(s) could be controlled by a third party (e.g., network
    operator). How to address that ?

  * *Public Crypto.* Is there any interest in providing any special
    considerations for devices that have support for public crypto
    (e.g., small crypto accelerators - ECDSA-P256/SHA256)? The
    availability of small crypto chip that allow for secure storage and
    off-chip crypto ops might benefit from special
    treatment/considerations... ?

  * *Trust Anchor Management.* Key management is a hard problem, but
    Trust Anchor management is often ignored or left to the
    application/device manufacturer. Should the group also provide
    guidance about how to handle TAs and their updates? For example, in
    the case where TLS is used for authentication of the source, what is
    the relationship between the certificate used on the server and the
    firmware development?

Last comment, personally I think that the proposed approaches might all 
provide a piece of the puzzle (authenticated manifest, signed firmware, 
encryption, per-device encryption, and TLS). From the experience I have 
with device manufacturers, the lack of experience on their part (in many 
cases) needs to be addressed by keeping the complexity of 
implementation, deployment, and long-term management/support to a minimum.

Just my 2 cents...

Looking forward to the Bof discussion :-D

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 13 Nov 2017 16:15:58 +0800

On 11/13/2017 03:15 PM, Dr. Pala wrote:
>     alternative to per-device encryption is the possibility of
>     allowing only authenticated devices to access/download/retrieve
>     the firmware itself (This requires a transport protocol that would
>     support the use of device-provided credentials)
>

If transport is out of scope, distinction between IP vs non-IP is not 
possible.  Of course it might be possible to profile different 
mechanisms that work over one or both of these.

>     manufacturer firmware validation and deployment enabling in
>     selected environments (i.e., another way to target the deployment
>     of the firmware). For example, environments where deployment of
>     the update(s) could be controlled by a third party (e.g., network
>     availability of small crypto chip that allow for secure storage
>     and off-chip crypto ops might benefit from special

Why do you stop at ECDSA?  What of ED25519?  We can get smaller with 
that.  Is it the job of SUIT to specify this?  I feel it might be an 
barrier to progress rather than a help.

>     guidance about how to handle TAs and their updates? For example,
>     in the case where TLS is used for authentication of the source,
>     what is the relationship between the certificate used on the
>     server and the firmware development?
>
> Last comment, personally I think that the proposed approaches might 
> all provide a piece of the puzzle (authenticated manifest, signed 
> firmware, encryption, per-device encryption, and TLS). From the 
> experience I have with device manufacturers, the lack of experience on 
> their part (in many cases) needs to be addressed by keeping the 
> complexity of implementation, deployment, and long-term 
> management/support to a minimum.
>
> Just my 2 cents...
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: "Dr. Pala" <[email-masked]>
Date: Mon, 13 Nov 2017 16:43:24 +0800

Hi Robert, all,

On 11/13/17 4:15 PM, Robert Moskowitz wrote:
> [...]
I had a different interpretation of the charter textl. In particular, I 
thought that although the WG would NOT define a new transport protocol, 
it might adopt existing ones (e.g., TLS) since it is listed as one of 
the component of the "firmware update solution."

This bullet point was meant to highlight that if specifying one or more 
transport protocol(s) and how they can be used for firmware updates is 
in scope, then we should be mindful of non-IP devices and how they 
should interact with the proposed protocol (e.g., via gateway devices).
> [...]
The algorithms were provided just as an example as this is, currently, 
the industry standard for small IoT cryptography (both on devices and 
cloud providers' services). Personally, I think that the WG should 
provide guidance about what and how to use as algorithms.

IMHO, providing complete and easy-to-follow solutions is paramount to 
increase the chances of a wide-spread adoption of the standard(s).

Cheers,
Max

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 13 Nov 2017 16:52:31 +0800

On 11/13/2017 04:43 PM, Dr. Pala wrote:
> I had a different interpretation of the charter textl. In particular, 
> I thought that although the WG would NOT define a new transport 
> protocol, it might adopt existing ones (e.g., TLS) since it is listed 
> as one of the component of the "firmware update solution."
>
> This bullet point was meant to highlight that if specifying one or 
> more transport protocol(s) and how they can be used for firmware 
> updates is in scope, then we should be mindful of non-IP devices and 
> how they should interact with the proposed protocol (e.g., via gateway 
> devices).

Think CAN-FD devices.  Of course automotive has their own firmware 
update standards.

I also think a lot about devices that are on PHYs that do not/can not 
support IP.

But then it is hard for the IETF to talk about non-IP communicating devices!

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 22:19:44 -0500

Robert Moskowitz <[email-masked]> wrote:
    drpala> * Public Crypto. Is there any interest in providing any special
    drpala> considerations for devices that have support for public crypto
    drpala> (e.g., small crypto accelerators - ECDSA-P256/SHA256)? The
    drpala> availability of small crypto chip that allow for secure storage
    drpala> and off-chip crypto ops might benefit from special
    drpala> treatment/considerations... ?

    > barrier to progress rather than a help.

I am very enthusiastic about Ed25519, and I'm pretty sure that whatever
container we use will have the algorithm agility to permit it.

There isn't deployed Ed25519 specific [hw] acceleration out there.
(I've been told that some ECDSA hardware acceleration options will accelerate
both, but I don't have details or first hand knowledge)

I don't believe that Ed25519 has any particular Quantum resistance over
ECDSA; rather it has higher assurance against state actors who may have a
backdoor.

So, if one is going to put a new algorithm into a boot loader, and it might
be in software, then I'd like to have a long-term quantum safe algorithm.

(The NIST competition deadline is the end of the month, and maybe we'll have a
miracle in late 2018 to save our bacon...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 22:21:53 -0500

> I also think a lot about devices that are on PHYs that do not/can not

sure, but that's why we have a requirement for multi-blob manifests, so that
the device that has IP (the router the PHY is in?) can collect the blob and
pass it on to the PHY. (whether the PHY has a trusted relationship with the
router, or can validate the blob itself is not in scope)