Re: [Suit] Wording for integrated payload size

Russ Housley <housley@vigilsec.com> Fri, 06 December 2019 20:32 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4867D12006D for <suit@ietfa.amsl.com>; Fri, 6 Dec 2019 12:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M10r9gHBoCOj for <suit@ietfa.amsl.com>; Fri, 6 Dec 2019 12:32:43 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EE212006B for <suit@ietf.org>; Fri, 6 Dec 2019 12:32:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id ADB66300B0B for <suit@ietf.org>; Fri, 6 Dec 2019 15:32:41 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gIFBIJy6ZSd4 for <suit@ietf.org>; Fri, 6 Dec 2019 15:32:40 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 2CB99300AE0; Fri, 6 Dec 2019 15:32:40 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <734509A8-7562-4B47-AAE5-54F840C4A298@arm.com>
Date: Fri, 06 Dec 2019 15:32:40 -0500
Cc: suit <suit@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <355773AB-A971-4690-9958-D32B24CAE23A@vigilsec.com>
References: <734509A8-7562-4B47-AAE5-54F840C4A298@arm.com>
To: Brendan Moran <Brendan.Moran@arm.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/T3XKWD-JNbW4VZv_hnwJwnVK8uo>
Subject: Re: [Suit] Wording for integrated payload size
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 20:32:45 -0000

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 <Brendan.Moran@arm.com> wrote:
> 
> 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
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit