Subject: [Suit] Which type of devices?

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 8 Nov 2018 10:10:19 +0700

Hi,

  I didn't get the discussion today. Just as a reminder, the SUIT WG 
Charter says explicitly: "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. "

Cheers
  matthias

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Nov 2018 03:28:38 +0000

Hi Matthias,

Which discussion during the meeting today did you give you the impression that we are not aiming for this goal?

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]
Subject: [Suit] Which type of devices?

Hi,

  I didn't get the discussion today. Just as a reminder, the SUIT WG Charter says explicitly: "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. "

Cheers
  matthias

--
Matthias Waehlisch
..  Freie Universitaet Berlin, Computer Science ... http://www.cs.fu-berlin.de/~waehl

_______________________________________________
Suit mailing list
[email-masked]
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.

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 8 Nov 2018 11:02:12 +0700

Hi Hannes,

  after Brendan's presentation there were some remarks on this. The 
discussion made slightly the impression that the group needs to argue 
why the SUIT solution should also fit into Class 1 devices.

  Based on the charter, the SUIT solution needs to suit Class 1, which 
has implications on design decisions and on which topic the WG invests 
time mostly.

  Supporting Class 1 devices is the default, anything else is nice to 
have.

Cheers
  matthias

On Thu, 8 Nov 2018, Hannes Tschofenig wrote:

> Hi Matthias,
> 
> Which discussion during the meeting today did you give you the 
> impression that we are not aiming for this goal?
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Nov 2018 04:35:11 +0000

Hi Matthias,

The contribution by Martin with his custom binary format (as an alternative binary format to the CBOR/COSE standardized format) is based on his impression that
* a custom binary format allows to reduce the size of the manifest by some (yet unknown) number of bytes, and
* CBOR and COSE libraries are not used in industrial IoT deployments.

I personally think that this discussion is unrelated to the device classes since the overhead really comes from the crypto, as several speakers on the microphone noted.

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

  after Brendan's presentation there were some remarks on this. The discussion made slightly the impression that the group needs to argue why the SUIT solution should also fit into Class 1 devices.

  Based on the charter, the SUIT solution needs to suit Class 1, which has implications on design decisions and on which topic the WG invests time mostly.

  Supporting Class 1 devices is the default, anything else is nice to have.

Cheers
  matthias

---

From: Martin Pagel <[email-masked]>
Date: Thu, 8 Nov 2018 05:05:21 +0000

Hannes and Matthias, 
I think there is an increasingly large spectrum of MCUs with different capabilities, some now include crypto accelerators, then the crypto code overhead is quite small. 

We currently use the proposed format in a quite constrained MCU implementation, for both software update and secure boot. Crypto operations are done via crypto accelerator. We use a simple C Struct to access the manifest elements, no need for schema validation. With the proper Struct definition this is compiler safe, Brendan. 

Brendan talked about a life cycle on how to drop data elements once they are not needed anymore. This is complexity we would like to avoid on constrained MCUs with a simple memory mapped binary structure.
Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
  matthias

On Thu, 8 Nov 2018, Hannes Tschofenig wrote:

> ..  Freie Universitaet Berlin, Computer Science ... 
> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.f
> u-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7
> Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7
> C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ou
> ByV2kMW%2BjGbHw%3D&amp;reserved=0
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
> microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
> b2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqc
> uOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0

--
Matthias Waehlisch
..  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0
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
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Nov 2018 05:16:10 +0000

Hi Martin,

> I think there is an increasingly large spectrum of MCUs with different capabilities, some now include crypto accelerators, then the crypto code overhead is quite small.

This is a common argument in the IoT standardization to justify variation. I heard the same argument when CBOR / COSE was developed....

> We currently use the proposed format in a quite constrained MCU implementation, for both software update and secure boot. Crypto operations are done via crypto accelerator. We use a simple C Struct…

Could you say a bit about the MCU you are using?

> Brendan talked about a life cycle on how to drop data elements once they are not needed anymore. This is complexity we would like to avoid on constrained MCUs with a simple memory mapped binary str…

Brendan didn't randomly come up with these ideas himself. Instead, it reflects what the group wanted to support functionality wise. Note that this is optional functionality that does not need to be used nor implemented if it isn't needed.

Ciao
Hannes

Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
  matthias

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Nov 2018 05:25:16 +0000

Martin,

Let me get back to the main question we need to answer here: Is your custom binary encoding worth the effort to have the data about the size of the messages and (maybe) the code size. Other arguments can either not be evaluated easily (such as the deployment status of CBOR / COSE in the industrial IoT) or not relevant since we are talking about optional fields that one does not need to use.

I am personally less interested in participating in the encoding discussions but I am sure Brendan is. I am more interested to see the COSE equivalent security wrapper.

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, November 8, 2018 12:16 PM
To: Martin Pagel <[email-masked]>; Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Martin,

Ciao
Hannes

Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
  matthias

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0
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: Martin Pagel <[email-masked]>
Date: Thu, 8 Nov 2018 05:27:04 +0000

We're using a MediaTek MT3620 MCU
A recent article explains some of it's functionality: http://linuxgizmos.com/first-azure-sphere-dev-board-launches/

But I have seen other similar on or off-chip solutions, too.

Martin

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Wednesday, November 7, 2018 9:16 PM
To: Martin Pagel <[email-masked]>; Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Martin,

Ciao
Hannes

Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
  matthias

--
Matthias Waehlisch
..  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cf7421d09043144c1a95b08d645394da2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772509774728710&amp;sdata=Wti25zwNIG6%2FErXijEWN8uOirZkeFTOOLxIZ4mdQjxc%3D&amp;reserved=0
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
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7Cf7421d09043144c1a95b08d645394da2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772509774738722&amp;sdata=iLroya%2F7nj7JrAVoTGS0Mf5pEBlZLArYKaTVna%2B0kME%3D&amp;reserved=0
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: Alexander Pelov <[email-masked]>
Date: Thu, 8 Nov 2018 12:39:54 +0700

Hi Martin, all,

Thanks for doing the hard work of looking into how to minimise to extreme the footprint of SUIT and the whole firmware update process!

Several points
- Only ONE schema for all potential encodings (otherwise, the chaos would be just too much)
- Do we need ONE or TWO encodings (no more)?
  - I'd have a tendency to start with we do ONE, unless there are cases that cannot be covered (with real-world scenarios) - and then and only then a second one is added

So, for me, this reads as:
- CBOR + CDDL
- If anything else is to be considered, what are the use-cases and how is this evaluated ?

Using a mapped binary structure does seem like a seducing opportunity, if you only use C. How about all the tooling that could use other programming languages? 
How about portability? (e.g. a C structure compiled on a big machine may not render the same memory layout as the one on a MCU.. so how are you going to even write the Metadata?)
One thing I am always very hesitant about is bugs and having correct code. And cost. And premature optimisation.

And finally - what is the benefit? I haven't seen any numbers on the C-Struct VS CBOR and use-cases that cannot be addressed by using CBOR. Until then, we can always have meta-discussions on how this or that could be made smaller.

This being said, I am more and more convinced that we need to split the process in two:
- Focus on CBOR + CDDL, with enough flexibility via Optional fields to address even very tiny devices (Class 1, Class 0 is nice to have)
- Later on (once all the CBOR+CDDL work is stable), IF there are use-cases that would require fighting for several tens of bytes (or even hundreds of bytes), write a spec how to translate a specific Manifest Profile to a specific binary serialization.
  - Ideally, that could stat with some "magic" number, that corresponds to a CBOR-encoded header that would make a generic CBOR parser understand it's not the intended public.
  - We may very well find that CBOR+C-struct Manifest can coexist.. (e.g. a CBOR structure that contains a binary BLOB, that is the effective binary-mapped C-Struct) ...
 
All these things sound awfully complex to me. So I'd really love to see ONE efficient, extensible and interoperable way to do it right. 

That being said, the discussion today was really useful to me to solidify my opinion on the topic, so thanks for the great arguments and for the great work! I do think it has great value - and I'll be happy see it get standardized on a second step (after we get the first Manifest format out).

My 2c
Alex

> On 8 Nov 2018, at 12:05, Martin Pagel <Martin.Pagel=[email-masked]> wrote:
> 
> Hannes and Matthias, 
> From: Suit <[email-masked] <mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
> To: Matthias Waehlisch <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>> https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.f <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.f>
>> u-berlin.de <http://u-berlin.de/>%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com <http://40microsoft.com/>%7
>> [email-masked] <mailto:[email-masked]>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i>
>> etf.org <http://etf.org/>%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
>> microsoft.com <http://microsoft.com/>%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
> ...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0>
> [email-masked] <mailto:[email-masked]>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>

---

From: Martin Pagel <[email-masked]>
Date: Thu, 8 Nov 2018 05:59:35 +0000

Hannes, 
A few bytes more or less don't make a big difference, but with CBOR you may need:
1. CBOR parser
2. Receive buffer for manifest
3. Data structure to be filled by parser
Whereas with a binary structure you load the data straight into the memory data structure (3), therefore no need for 1+2.

Yes, you need a proper signature envelope. COSE is certainly a good option, but what if the MCU's crypto accelerator only handles PKCS1 or ASN.1? For this reason, I left the type of signature method up to the platform to decide.
Martin

-----Original Message-----
From: Hannes Tschofenig <[email-masked]> 
Sent: Wednesday, November 7, 2018 9:25 PM
To: Hannes Tschofenig <[email-masked]>; Martin Pagel <[email-masked]>; Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Martin,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Thursday, November 8, 2018 12:16 PM
To: Martin Pagel <[email-masked]>; Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Martin,

Ciao
Hannes

Martin

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]>
Cc: [email-masked]
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
  matthias

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C69d0093b5918433af43808d6453a93f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772515235693780&amp;sdata=zpZbLjFmT%2B%2BbWV8mMiGAl3MmmeQ%2FgUBoOpToAYi4YOI%3D&amp;reserved=0
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
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C69d0093b5918433af43808d6453a93f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772515235703789&amp;sdata=%2BnUibGzLJGJue1H1w%2FtznmVvlFZbI%2BPCki%2BYIXdC2VI%3D&amp;reserved=0
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
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C69d0093b5918433af43808d6453a93f7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772515235703789&amp;sdata=%2BnUibGzLJGJue1H1w%2FtznmVvlFZbI%2BPCki%2BYIXdC2VI%3D&amp;reserved=0
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: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2018 13:49:33 +0700

> I personally think that this discussion is unrelated to the device
    > classes since the overhead really comes from the crypto, as several
    > speakers on the microphone noted.

+1

---

From: Brendan Moran <[email-masked]>
Date: Thu, 8 Nov 2018 12:46:55 +0000

Hi Martin,

Perhaps I have misunderstood something. The C99 standard (ISO/IEC 9899:1999) says:

6.7.2.1 Structure and union specifiers
…
12 Each non-bit-field member of a structure or union object is aligned in an implementation defined manner appropriate to its type.

13 Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning.

From my reading, this says that:
1) Alignment of members is implementation defined.
2) Padding in the structure is implementation defined.
3) The only guarantee you have is monotonically increasing address of structure members.

If my reading is correct, then a “proper struct definition” does not change whether or not the compiler is allowed to take liberties with the alignment or padding of a structure. There is no guarantee of consistency between compilers, nor between versions of the same compiler. There may be incidental consistency, but this is not adequate to make an argument about wire format definition, nor about complexity of parsers.

If even just alignment of members is implementation defined (6.7.2.1.12 clearly says it is) then a structure is not adequate to define nor to deserialise a wire format.

Perhaps someone can correct me if I have misinterpreted ISO/IEC 9899:1999.

Best Regards,
Brendan

On 8 Nov 2018, at 05:05, Martin Pagel <Martin.Pagel=[email-masked]<mailto:Martin.Pagel=[email-masked]>> wrote:

Hannes and Matthias,

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
 matthias

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

Cheers
 matthias

u-berlin.de<http://u-berlin.de/>%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com<http://40microsoft.com/>%7

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org<http://etf.org/>%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
microsoft.com<http://microsoft.com/>%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
b2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqc
uOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0
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
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit

---

From: Martin Pagel <[email-masked]>
Date: Thu, 8 Nov 2018 21:30:12 +0000

Hi Brendan,
Yes, the C99 compiler spec contains certain disclaimers as different processor architectures may pad or store certain data structures in different ways, for example how a compiler/processor implements “Int” or pack Boolean arrays in different ways.
The draft circumvents such issues by only using UInt and by aligning on 16bit boundaries. That way the data structure can be mapped directly by any compiler.
Again, for firmware development, this is pretty common practice.
Martin

From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Thursday, November 8, 2018 4:47 AM
To: Martin Pagel <Martin.Pagel=[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]; Matthias Waehlisch <[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Martin,

Best Regards,
Brendan

Hannes and Matthias,

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
 matthias

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

Cheers
 matthias

u-berlin.de<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fu-berlin.de%2F&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368525145&sdata=YRQLioo3qkr7wInqgmy%2FHCpvgONzyxYb7ZD1DopMcy8%3D&reserved=0>%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368535157&sdata=mG4Rm5UTzMhJ3Dtp2XDmU%2Bx0zEV%2B1JiUn6K8FUtYZ14%3D&reserved=0>%7

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368545165&sdata=K%2F1CzS578eTN1Q1utbcOrRKz%2BWTu0m2OtVO%2Biu6ar7Q%3D&reserved=0>%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com%2F&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368545165&sdata=3ftPKCFlKMZC74Abp%2Bj7kssQHOQt2Qc0kzs8vdjw0zw%3D&reserved=0>%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
b2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqc
uOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0
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.

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368555169&sdata=sdY9S%2FdHzNbWpORtLZSPDqlE1E9643zE8i3XhyJl9YU%3D&reserved=0>
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
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368565178&sdata=cabS4zzZwKo%2BauzP4lIjlHRZkACa0Ti%2BiziTumz2Rks%3D&reserved=0>

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ce991ec9c37ca4156335508d645784eec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772780368565178&sdata=cabS4zzZwKo%2BauzP4lIjlHRZkACa0Ti%2BiziTumz2Rks%3D&reserved=0>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 9 Nov 2018 02:00:19 +0000

If you do a web search on “pragma pack” you’ll see an example of what Martin refers to as packing.
It tells the compiler not to insert any padding between fields, so the developer is always in control of the exact structure much like a packet format diagram in an RFC.

This sort of compiler construct is what is often used to implement binary protocols.  It’s a fairly common practice.

It may not be part of C99 but it’s generally supported by compilers in their own way (so if you want cross-platform code, you have to use ifdefs appropriately, but OSS projects often do exactly that).

Dave

From: Suit <[email-masked]> On Behalf Of Martin Pagel
Sent: Friday, November 9, 2018 5:30 AM
To: Brendan Moran <[email-masked]>; Martin Pagel <Martin.Pagel=[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]; Matthias Waehlisch <[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Brendan,

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Brendan Moran
Sent: Thursday, November 8, 2018 4:47 AM
To: Martin Pagel <Martin.Pagel=[email-masked]<mailto:Martin.Pagel=[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Which type of devices?

Hi Martin,

Best Regards,
Brendan

Hannes and Matthias,

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
 matthias

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

Cheers
 matthias

u-berlin.de<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fu-berlin.de%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283336350&sdata=cpRvt98Vc8z3sBcoGgdmLMXuK5fVf96U%2BgG6l9zs4hk%3D&reserved=0>%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283346358&sdata=mWNM4gPbtIxzWtJ8OQGEXJUieDlVr%2FWN5cy2Pe6bQtQ%3D&reserved=0>%7

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
etf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fetf.org%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283356367&sdata=MdSXUriIkdMs2g4RtovNxOvknpt3sYDOfvk%2FFyoefN4%3D&reserved=0>%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40
microsoft.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmicrosoft.com%2F&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283356367&sdata=sgjSnW12a6gw1kZSvXvBBn7HC4Cc7%2B4KtjxucYz567o%3D&reserved=0>%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91a
b2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqc
uOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0
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.

--
Matthias Waehlisch
...  Freie Universitaet Berlin, Computer Science ... https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=ct5txfAAcRM%2BgHw1GoOImrr3bhU8ouByV2kMW%2BjGbHw%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.cs.fu-berlin.de%2F~waehl&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283366375&sdata=u%2B32lS0NCtsmcG00JUGLtIyjndNDNqLd49zxohC%2FrRM%3D&reserved=0>
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
[email-masked]<mailto:[email-masked]>
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cmartin.pagel%40microsoft.com%7Ca39ff4cf1fd74f0dba5d08d645339c7e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636772485305445335&amp;sdata=%2FjHzLtzk04XkWqcuOAAsYjD9Wz%2FK7xxvsqILxP6Rr%2Fc%3D&amp;reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283376383&sdata=%2Fdg2L3tRelnUIyKVJDgp44iSq7OwcAaKuqZN0gAPnBc%3D&reserved=0>

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/suit<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cdthaler%40microsoft.com%7Cbc43b4494264448bded108d645c165bf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636773094283376383&sdata=%2Fdg2L3tRelnUIyKVJDgp44iSq7OwcAaKuqZN0gAPnBc%3D&reserved=0>

---

From: Brendan Moran <[email-masked]>
Date: Fri, 9 Nov 2018 14:18:19 +0000

Hi Dave,

I’ve seen lots of open source projects that rely on pragma pack. Some of them, such as LwIP do so in a safe way, by using pool-allocated memory that is confined to a safe region in memory.

However, I don’t think that relying on pragma pack for general purpose code is a good idea. Here are a few reasons you might want to avoid pragma pack (there may be more!):

1. It’s not part of the standard, so it’s up to you, as a developer, to validate the handling of pragma pack on each target and to ensure that they are compatible. Read the docs, or you might be surprised!

2. As an example of the above, minGW on Windows ignores pragma pack unless you issue -mno-ms-bitfields to the compiler invocation.

3. pragma pack issues different instructions on some architectures: when used with MIPS, some compilers issue unaligned load/store instructions rather than the regular load/store. Architectures that do not support unaligned access will need to issue code for multiple loads, stores, shifts, masks, and ors.

4. Some compilers do not support pragma pack, frequently those targeting proprietary, low end processors of exactly the type that are targeted by this binary format.

5. Unless you can guarantee alignment in keeping with the architecture’s ABI, some accesses will incur an unaligned access overhead, which is not obvious, nor easy to reason about without profiling. (Performance is lower than it should be, and this is architecture-dependent)

6. On some architectures, it can lead to rare and difficult to trace bugs: on ARM v7-m, it’s an exception to issue an unaligned access across memory regions, even if those regions are contiguous. This means that, if you have a buffer allocated across a region boundary and you issue an unaligned access to that buffer, you will trigger an exception, even if that access is legal everywhere else in RAM. I have seen this bug occur in production code.

I don’t like depending on the behaviour of a non-standard extension, only available on some compilers, which is prone to introducing subtle and rarely triggered bugs, in order to make arguments about the performance and efficiency of a proposed standard.

Regardless, I think the important thing is really what the resource utilisation comparison is between a CBOR-encoded manifest and a packed-structure manifest, irrespective of how the packed-structure manifest is interpreted. To make this an easier comparison, I’m working on a example of a special purpose parser, not for CBOR, but for a minimal subset of the manifest described in draft-moran-suit-manifest-03, so that the working group can have numbers available to make an informed decision.

Best Regards,
Brendan Moran

On 9 Nov 2018, at 02:00, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

Dave

From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Pagel
Sent: Friday, November 9, 2018 5:30 AM
To: Brendan Moran <[email-masked]<mailto:[email-masked]>>; Martin Pagel <Martin.Pagel=[email-masked]<mailto:Martin.Pagel=[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Suit] Which type of devices?

Hi Brendan,

Hi Martin,

Best Regards,
Brendan

Hannes and Matthias,

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Hannes Tschofenig
Sent: Wednesday, November 7, 2018 8:35 PM
To: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Suit] Which type of devices?

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Matthias Waehlisch <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 8, 2018 11:02 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Suit] Which type of devices?

Hi Hannes,

Cheers
 matthias

Hi Matthias,

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Matthias Waehlisch
Sent: Thursday, November 8, 2018 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Suit] Which type of devices?

Hi,

Cheers
 matthias

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 9 Nov 2018 20:40:00 -0600

> 5. Unless you can guarantee alignment in keeping with the architecture’s ABI, some accesses will incur an unaligned access overhead, which is not obvious, nor easy to reason about without profiling…

This ("the architecture's ABI") seems like the key point.  Even without
pragma pack, you are still reliant on the architecture's ABI for the
structure layout, padding, and alignment guarantees.  This goes back to
(1), and the obligation of the developer to validate what hey're doing on
the target architectures they are using.  ISO C does not give you enough
guarantees to do this sort of thing at a pure C level.

-Ben

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Nov 2018 09:59:51 +0700

Wrt the C99 argument, I’m a bit on the side “yes, you can use non-portable struct packing” because the rest of your embedded code already is using a ton of them anyway.  (I’d rather not use more bespoke encoding, though.)

But I’m still at a loss for what this is:

> On Nov 8, 2018, at 12:59, Martin Pagel <Martin.Pagel=[email-masked]> wrote:
> 

The manifest is mostly structural information, with a few strings (text or binary) embedded.
When looking at these, you never need to copy the latter, as they are already ready for use in place.
So the only problem might be the structural information, but you have to run through that (“parse it”) for any format.
So what is that “receive buffer" business?  You don’t have to separate the unpacking of the structural data and the use.

Grüße, Carsten

---

From: Martin Pagel <[email-masked]>
Date: Sat, 10 Nov 2018 03:29:48 +0000

Let me try to describe the process in more detail:
From what I understand (correct me if I'm wrong as I'm not a CBOR expert) CBOR uses the first three bits of a field as its type identifier, for example whether the rest is a (5bit) integer or, depending on the following values, is followed by a 16bit or 32bit integer or text string or...   As such format is kind of difficult to parse by code natively, you usually load the CBOR data into a temporary receiving buffer and you use a parser which parses the CBOR structure from beginning to end into a more convenient structure such as a C structure or array of structures. For example the parser would store the 5bit value into a 8bit or 16bit integer variable and drop any of the type identifier info so that the application can work with the data just like any other program variables. During that process, the parser needs about twice the memory of the manifest file: one memory area for the receiving buffer and one for the final data the application can conveniently deal with. 

Hope that helps or let me know if I'm off...
Martin

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Friday, November 9, 2018 7:00 PM
To: Martin Pagel <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Matthias Waehlisch <[email-masked]>; [email-masked]
Subject: Re: [Suit] Which type of devices?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Nov 2018 11:56:30 +0700

You can implement it this way, it is just not a very good approach.
That’s why people have talked about “pull parsers” (i.e., process the information as you go along).
Essentially, in your bespoke internal encoding, you would do the same, so why not process the CBOR right away?
This is not ASN.1.
The main difference is that with a linear serialization, you would process the information front to back, while with bespoke internal representation where everything occurs exactly once and has its place assigned, you have random access.  That worked great for the a.out header in 1971 [1].  But a manifest is not that, you do have to process the alternatives and counters anyway.  (This is similar to the reason why we have moved from a.out to Mach-O or COFF and then some of us to ELF.)

Grüße, Carsten

[1]: https://en.wikipedia.org/wiki/A.out

> On Nov 10, 2018, at 10:29, Martin Pagel <Martin.Pagel=[email-masked]> wrote:
>

---

From: Martin Pagel <[email-masked]>
Date: Sat, 10 Nov 2018 05:08:30 +0000

Yes, a pull parser would rely on the network buffer rather than an application buffer, that might help, but you still have extra parser code. 
MfG
Martin

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: Friday, November 9, 2018 8:57 PM
To: Martin Pagel <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; [email-masked]; Matthias Waehlisch <[email-masked]>
Subject: Re: [Suit] Which type of devices?

Grüße, Carsten

[1]: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FA.out&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C49a7aef5d2ad4bafd4f208d646c8f461%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636774226248026562&amp;sdata=t3LT2jsLCPYwN0UXn6H0KKBQIkBW3X16IqrO%2BEtszwc%3D&amp;reserved=0

> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7CMartin.Pagel%40microsoft.com%7C49a7aef5d2ad4bafd4f208d646c8f461%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636774226248026562&amp;sdata=uKuZCKRsV%2BdDUEk4LOEqZwXYnQAJf6itIcIhl6Z4cOc%3D&amp;reserved=0
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2018 04:45:40 -0500

I just to be clear here.

We are discussing pragma pack limitations because we want to have
a packed structure (one idea is which can be parsed as if it were CBOR,
but must be written with the knowledge that it's a very limited subset).

And we are discussing this in the context of fitting code into class 1
devices, which: 

1) are not not very general
2) require many unique and interesting compiler flags
3) do not genereally run code built with minGW (which is a windows compiler,
   not a cross-compiler for embedded systems)
4) unaligned access issues with structures is the reason one interprets
   CBOR as bytes, not a structure.  I.e. once you build a packed structure
   that survives all the alignment issues, you have invended CBOR.

> I don’t like depending on the behaviour of a non-standard extension, only
> available on some compilers, which is prone to introducing subtle and
> rarely triggered bugs, in order to make arguments about the performance and
> efficiency of a proposed standard.

> Regardless, I think the important thing is really what the resource
> utilisation comparison is between a CBOR-encoded manifest and a
> packed-structure manifest, irrespective of how the packed-structure
> manifest is interpreted. To make this an easier comparison, I’m working on
> a example of a special purpose parser, not for CBOR, but for a minimal
> subset of the manifest described in draft-moran-suit-manifest-03, so that
> the working group can have numbers available to make an informed decision.

I've written C (and a variety of things that were not-quite C code) code for
30 years, at times for devices which were state of the art at the time, and
would be class 1 today.
The crypto overhead is going to dominate.

I think that the best choice is a clear, limited subset of CBOR.
CBOR is pretty damn small.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2018 04:52:23 -0500

Martin Pagel <Martin.Pagel=[email-masked]> wrote:
    > Let me try to describe the process in more detail: From what I
    > understand (correct me if I'm wrong as I'm not a CBOR expert) CBOR uses
    > the first three bits of a field as its type identifier, for example
    > whether the rest is a (5bit) integer or, depending on the following
    > values, is followed by a 16bit or 32bit integer or text string or...
    > As such format is kind of difficult to parse by code natively, you
    > usually load the CBOR data into a temporary receiving buffer and you
    > use a parser which parses the CBOR structure from beginning to end into
    > a more convenient structure such as a C structure or array of
    > structures. For example the parser would store the 5bit value into a

This is certainly how it works with Python or Ruby.
In C, which is not what I'd do.

I'd look at the CBOR blob, parse enough to find out which key signed it,
validate the signature, and then I'd mutate the CBOR into formats I can
use directly.  For instance, setting the upper three bits to zeroes if
I wanted the 5-bit number directly. (That's probably a silly example, because
it's just one byte, but maybe it helps to have a length value in front of a
string)

    > 8bit or 16bit integer variable and drop any of the type identifier info
    > so that the application can work with the data just like any other
    > program variables. During that process, the parser needs about twice
    > the memory of the manifest file: one memory area for the receiving
    > buffer and one for the final data the application can conveniently deal
    > with.

I think that I would build a structure that would point to all the strings
in the original manifest that I needed.  Maybe saving bytes by using offsets
rather than 32-bit pointers.

It just doesn't seem that hard to me, nor do I think it has to take a lot
of space.

---

From: Brendan Moran <[email-masked]>
Date: Mon, 12 Nov 2018 13:35:29 +0000

Hi Michael,

You’re absolutely right. I’ve written an example of a completely minimal manifest parser, for a very limited subset of the manifest I proposed.

The “parser” only returns the information that is needed for each step, so it has several functions that must be called in sequence.

This is a pull parser that interacts with the signature verification primitives to initialise a signature verification context in preparation for verifying the COSE_Sign1 structure that is in the manifest outer wrapper.

All builds were done for ARM Cortex-M4. I built this parser in two ways, depending on the bit-size of CBOR integers. This affects two fields in the minimal manifest subset I chose: the payload size and the sequence number.

The test manifest for this minimal subset was 302 bytes and includes a reference digest for a text description, but that description has been severed.

When assuming that all CBOR integers are 64-bit:
Full Structural verification: 562
Information Extraction: 339

When assuming that all CBOR integers are 32-bit:
Full Structural verification: 542
Information Extraction: 323

Given that this is a very rough first try, I expect there is room for further optimisation.

I’ll post the code shortly. For now, however, we have a maximum lower bound that we can use to discuss the suitability of a fixed-function CBOR parser for a fixed, minimal subset of draft-moran-suit-manifest-03.

Best Regards,
Brendan

> On 12 Nov 2018, at 09:52, Michael Richardson <[email-masked]> wrote:
>
>