Subject: [Suit] Wording for integrated payload size

From: Brendan Moran <[email-masked]>
Date: Fri, 6 Dec 2019 14:18:30 +0000

To finalise the information model, we need to address the issue raised at ietf106: how big can an integrated payload be? The suggestion made at the meeting was that no specific requirement should be made, but that the information model needed some text to explain the tradeoffs in size of payload. Here is my proposal for that text.

Best Regards,
Brendan

When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. If the manifest is too large to fit in RAM, then it must be processed modularly; first evaluating delegation chains, then the security container, then processing the actual manifest, which includes verifying the integrated payload. While the manifest has been organised to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored to nonvolatile storage prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded and these costs vary with the size of the integrated payload.
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: Russ Housley <[email-masked]>
Date: Fri, 6 Dec 2019 15:32:40 -0500

Brendan:

I agree with the approach that you are taking here, but I am not sure that every implementation will perform the checks in that order.  They all need to be checked, but as long as they are all checked before the firmware is installed, then the implementation should be considered conformant.  I think the following would be better:

....   If the manifest is too large to fit in RAM, then it must be processed modularly, which includes evaluating delegation chains, validating the security container, processing the actual manifest, and verifying the integrated payload. ...

Russ

> On Dec 6, 2019, at 9:18 AM, Brendan Moran <[email-masked]> wrote:
> 
> When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. If the manifest is too large to fit in RAM, then it must be processed modularly; first evaluating delegation chains, then the security container, then processing the actual manifest, which includes verifying the integrated payload. While the manifest has been organised to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored to nonvolatile storage prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, 
> authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded and these costs vary with the size of the integrated payload.
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: David Brown <[email-masked]>
Date: Wed, 11 Dec 2019 10:54:51 -0700

On Fri, Dec 06, 2019 at 03:32:40PM -0500, Russ Housley wrote:

> I agree with the approach that you are taking here, but I am not
> sure that every implementation will perform the checks in that
> order.  They all need to be checked, but as long as they are all
> checked before the firmware is installed, then the implementation
> should be considered conformant.  I think the following would be
> better:
> 
> .....   If the manifest is too large to fit in RAM, then it must be
> processed modularly, which includes evaluating delegation chains,
> validating the security container, processing the actual manifest,
> and verifying the integrated payload. ...

I have some similar concerns about this assumption that the manifest
must be in RAM.  With the existing MCUboot implementation we always
process the manifest directly in-place in flash.  There are steps of
this processing that are done at every boot (we need to verify the
signature of the image before booting).

What is unclear to me is whether this wording is talking about the raw
manifest itself, or some kind of in-memory decoded CBOR.  I would
expect smaller targets to always interpret the manifest directly, and
not decode it into some kind of intermediate representation.

David

---

From: Dave Thaler <[email-masked]>
Date: Wed, 11 Dec 2019 18:51:32 +0000

Grammatical comment:  "stored to" reads oddly to me.
I'd suggest replacing with either "stored in" or "saved to".

Dave

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Brendan Moran
Sent: Friday, December 6, 2019 6:19 AM
To: suit <[email-masked]>
Subject: [Suit] Wording for integrated payload size

Best Regards,
Brendan

_______________________________________________
Suit mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C9d5dbf0c98c845d1453508d77a573609%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637112387316385698&amp;sdata=jvELlCP5PxSIqjoHOAG1NZkXyyn8oc2CPuOm6g5WaTs%3D&amp;reserved=0

---

From: Brendan Moran <[email-masked]>
Date: Tue, 17 Dec 2019 12:04:42 +0000

Russ,

I see why the use of RAM as a requirement is surprising. There are two requirements here. I believe that one of them is required and one is optional.

It is required that the manifest be held invariant between verification and processing. This could mean storing in internal RAM or NVRAM, storing in a secure external memory, etc.
It is desirable, depending on system factors, to ensure that a manifest is verified prior to storing to NVRAM. This is most pertinent when the NVRAM wears or when NVRAM writes are energy expensive. This, however, is a download & update concern, not a bootloader concern.

Here’s a rephrased version of the previous excerpt.

Best Regards,
Brendan

When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. The manifest must be held invariant between verification and processing, so a larger manifest will consume more memory with invariance guarantees, for example internal RAM or NVRAM, or external secure memory. If the manifest exceeds the available invariant memory, then it must be processed modularly, evaluating each of: delegation chains, the security container, and the actual manifest, which includes verifying the integrated payload. If the security model calls for downloading the manifest and validating it before storing to NVRAM in order to prevent wear to NVRAM and energy expenditure in NVRAM, then either increasing memory allocated to manifest storage or modular processing of the received manifest may be required. While the manifest has been organised to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored in NVRAM prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded and these costs vary with the size of the integrated payload.

On 11 Dec 2019, at 18:51, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

Dave

-----Original Message-----
From: Suit <[email-masked]<mailto:[email-masked]>> On Behalf Of Brendan Moran
Sent: Friday, December 6, 2019 6:19 AM
To: suit <[email-masked]<mailto:[email-masked]>>
Subject: [Suit] Wording for integrated payload size

Best Regards,
Brendan

_______________________________________________
Suit mailing list
[email-masked]<mailto:[email-masked]>
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C9d5dbf0c98c845d1453508d77a573609%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637112387316385698&amp;sdata=jvELlCP5PxSIqjoHOAG1NZkXyyn8oc2CPuOm6g5WaTs%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Dec 2019 14:38:02 -0500

Brendan Moran <[email-masked]> wrote:
    > I see why the use of RAM as a requirement is surprising. There are two
    > requirements here. I believe that one of them is required and one is
    > optional.

    > It is required that the manifest be held invariant between verification and
    > processing. This could mean storing in internal RAM or NVRAM, storing in a
    > secure external memory, etc.

I think that you are also attempting to defend against hardware attacks where
the contents of memory get changed mid-process.  That's not *explicitely*
stated in the text.

But, it's why you speak about internal RAM (vs RAM), and I guess "secure
external memory" means that it has some cryptographic checks not attackable
From outside the SoC.

Maybe the attempt to abstract the text is detracting from understanding?

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

---

From: Brendan Moran <[email-masked]>
Date: Mon, 23 Dec 2019 11:07:46 +0000

When I talk about holding memory invariant, I’m referring to another part of the information model. Specifically, REQ.SEC.MFST.CONST. I mistakenly used “invariant” rather than “immutable” in the snippet that I shared.

Is this version clearer?

Best Regards,
Brendan

When an integrated payload is provided, this increases the size of the manifest. Manifest size can cause several processing and storage concerns that require careful consideration. The payload can prevent the whole manifest from being contained in a single network packet, which can cause fragmentation and the loss of portions of the manifest in lossy networks. This causes the need for reassembly and retransmission logic. The manifest must be held immutable between verification and processing (see [REQ.SEC.MFST.CONST](#req-sec-mfst-const)), so a larger manifest will consume more memory with immutability guarantees, for example internal RAM or NVRAM, or external secure memory. If the manifest exceeds the available immutable memory, then it must be processed modularly, evaluating each of: delegation chains, the security container, and the actual manifest, which includes verifying the integrated payload. If the security model calls for downloading the manifest and validating it before storing to NVRAM in order to prevent wear to NVRAM and energy expenditure in NVRAM, then either increasing memory allocated to manifest storage or modular processing of the received manifest may be required. While the manifest has been organised to enable this type of processing, it creates additional complexity in the parser. If the manifest is stored in NVRAM prior to processing, the integrated payload may cause the manifest to exceed the available storage. Because the manifest is received prior to validation of applicability, authority, or correctness, integrated payloads cause the recipient to expend network bandwidth and energy that may not be required if the manifest is discarded and these costs vary with the size of the integrated payload.

On 17 Dec 2019, at 19:38, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Brendan Moran <[email-masked]<mailto:[email-masked]>> wrote:
I see why the use of RAM as a requirement is surprising. There are two
requirements here. I believe that one of them is required and one is
optional.

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