Re: [Suit] Wording for integrated payload size

[Brendan Moran <[e-mail]>]

If there is no objection, I’d like to submit this paragraph in an update to the information model. I think this is the last outstanding element that needs to be cleared before this document can be accepted.

Best Regards,
Brendan

On 23 Dec 2019, at 11:07, Brendan Moran <[e-mail]<mailto:[e-mail]>> wrote:

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


Brendan Moran <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
-= IPv6 IoT consulting =-




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://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. 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.