Re: [Suit] Wording for integrated payload size

[Brendan Moran <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> wrote:

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

Dave

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

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.

_______________________________________________
Suit mailing list
[e-mail]<mailto:[e-mail]>
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

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.