Re: [Suit] Wording for integrated payload size

David Brown <david.brown@linaro.org> Wed, 11 December 2019 17:54 UTC

Return-Path: <david.brown@linaro.org>
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 0AA061200DB for <suit@ietfa.amsl.com>; Wed, 11 Dec 2019 09:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=linaro.org
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 8evVn9LAItQc for <suit@ietfa.amsl.com>; Wed, 11 Dec 2019 09:54:55 -0800 (PST)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA08120099 for <suit@ietf.org>; Wed, 11 Dec 2019 09:54:55 -0800 (PST)
Received: by mail-qt1-x833.google.com with SMTP id z15so7038294qts.5 for <suit@ietf.org>; Wed, 11 Dec 2019 09:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=IVDDxBrNStnFGjg08TGBC01QLJtNuaI/7GsAsbe0tQ4=; b=hP/WbV8T1hbXkBBoz9XqfD8IjDdWrry89xInrKAfaE+Ft1xWgHxOdxzqaORDIvyN2n Y8zbXj4Y6y9i+d6pbyOoyGeIxFTReqqWl4V5luMz4htFCA5QPSYI0UcUJhlcRuJl+cDm gc2C8vzNAXxqtKCayiZiU8W/pNXOfRlN7Ia4RsiOALqt2mkmtuHQjT5X5uROAAKEwSIw D/OJaUI04PS3lFCd9treY2hkWW01gwReqISRukF58aVO08XszSoKJcPm+G6hoBFkAjAc TEJwlhOfKMmtQgmivk9N98ZVtQz6v7SXnBDD+h/RhbRIlsC4+x4bS3YPyKiVegyYqUrZ nMFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IVDDxBrNStnFGjg08TGBC01QLJtNuaI/7GsAsbe0tQ4=; b=DuERuztWOPATDxLtnTRH422T2Y6wK2eM9pyv+peWpF7YkrL+Ji1tsGluWw/YLVEmUe po+u1udBg79Rs4W13amDvfFax6fS9/IhBOjCOnkT+GHbOScZg9dKYv5+P0HDenLE1ZTS KuQyRFucup3bZae7YUbahV+32uHs5YJXFc/rfJH1zPoPcMIUVQ1sfWAsTh8cBhtloILx u7Ip/HSoZTEyLv+sCDxnNKaLmkVFcu4HY7X05nThrtwVoY0yBi+lVfikwsbgy6AeKMzn Tj4pEr/++IdfwyRpzHnYlVBGvMv4h2eWN+5f85KxYAvOLYO1pd1QwMfIuF8+oDwraZ7Y Uw6Q==
X-Gm-Message-State: APjAAAU1QMmO3evWUmPPXhJ4yFrXLpK6MjW6TzsaxkHQrQlUs4WNjpmz EO6ibTvaILG+6Rvi60HvHv7NzKhhJfmUTw==
X-Google-Smtp-Source: APXvYqyh72nfmmBl1EWPmIQQOmCaMmfWV18qDxU2xv8MPHFtCMRh2UuLWXU6F/tb3D0uBqTWkKIQCg==
X-Received: by 2002:aed:23bb:: with SMTP id j56mr3834906qtc.315.1576086894408; Wed, 11 Dec 2019 09:54:54 -0800 (PST)
Received: from davidb.org (cn-co-b07400e8c3-142422-1.tingfiber.com. [64.98.48.55]) by smtp.gmail.com with ESMTPSA id b42sm1173860qtb.36.2019.12.11.09.54.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Dec 2019 09:54:53 -0800 (PST)
Date: Wed, 11 Dec 2019 10:54:51 -0700
From: David Brown <david.brown@linaro.org>
To: Russ Housley <housley@vigilsec.com>
Cc: Brendan Moran <Brendan.Moran@arm.com>, suit <suit@ietf.org>
Message-ID: <20191211175451.GB832567@davidb.org>
References: <734509A8-7562-4B47-AAE5-54F840C4A298@arm.com> <355773AB-A971-4690-9958-D32B24CAE23A@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <355773AB-A971-4690-9958-D32B24CAE23A@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/dxC71hx8oEol_YogMmwWD1oUuKU>
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: Wed, 11 Dec 2019 17:54:57 -0000

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