Re: [Suit] Manifest authentication field ordering

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 25 November 2019 23:16 UTC

Return-Path: <mcr@sandelman.ca>
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 C460C120F9F for <suit@ietfa.amsl.com>; Mon, 25 Nov 2019 15:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 A3AS3imngCFl for <suit@ietfa.amsl.com>; Mon, 25 Nov 2019 15:16:16 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF12E120024 for <suit@ietf.org>; Mon, 25 Nov 2019 15:16:15 -0800 (PST)
Received: from dooku.sandelman.ca (unknown [194.42.227.53]) by relay.sandelman.ca (Postfix) with ESMTPS id CADB51F47D; Mon, 25 Nov 2019 23:16:13 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C73871422; Tue, 26 Nov 2019 07:16:08 +0800 (+08)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brendan Moran <Brendan.Moran@arm.com>
cc: suit <suit@ietf.org>
In-reply-to: <5C60D5E3-28FC-4554-AF39-BD80487EF9B5@arm.com>
References: <5C60D5E3-28FC-4554-AF39-BD80487EF9B5@arm.com>
Comments: In-reply-to Brendan Moran <Brendan.Moran@arm.com> message dated "Mon, 25 Nov 2019 12:10:57 +0000."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 26 Nov 2019 00:16:08 +0100
Message-ID: <7995.1574723768@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/31CRNQlFUbuine4DubjLcGghCJo>
Subject: Re: [Suit] Manifest authentication field ordering
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: Mon, 25 Nov 2019 23:16:18 -0000

Brendan Moran <Brendan.Moran@arm.com> wrote:
    > I’ve been looking at PQC authentication primitives, particularly
    > HSS/LMS [1] and XMSS [2]. These signature schemes require the
    > processing of quite large signature blocks: I expect a Winternitz
    > parameter of w=8 to be common, which makes the signature size 1088
    > bytes just for the Winternitz signature, without the Merkle tree
    > components.

    > These large signatures can easily cause the manifest to violate
    > REQ.SEC.MFST.CONST if the authentication section and the manifest are
    > treated as a single unit, specifically:

Thank you for thinking about this now!

    > However, I think we should apply a slightly more relaxed approach here:
    > Only the manifest itself, not the authentication wrapper, needs to fit
    > in internal memory. Conveniently, most of these signature schemes can
    > support a modular processing scheme, where the whole signature does not
    > need to be loaded into RAM at once in order to validate a signature,
    > with no loss of security.

I agree with this idea.

    > 1.  Parse COSE_Sign/COSE_Sign1 object
    > 2.  Construct & digest the Sig_structure
    > 3.  Validate the Sig_structure digest with the COSE_Signature object

I suspect that many will need an illustration.

    > There is another option, but it inflates the size of the authentication
    > wrapper by one digest: instead of using COSE_Sign in detached mode, we
    > place a digest in the COSE_Sign as the payload. That digest is, in
    > turn, the digest of the manifest.

So, we would run a digest (say, SHA256) of the manifest, and then sign that.
The signining operation would (implicitely) create a second digest in the
signature block, which is why you are saying it costs an extra digest.

The problem that I see with this is that we are forced to select a digest at
least as strong as the security of the HSS/LMS/XMSS or future PQC primitive.
With the doubly-signed COSE_Sign payload (once with ECDSA+SHA256, the second
time with the PQC method), then we don't have any specific dependancy in
the PQC path on the SHA256.

Is this a serious concern?  I don't know, because I don't know if SHA256 will
survive.  I think that it will, and there are hash-based signatures that
assume it will, but it seems imprudent to assume this.

    > My recommendation is to make two changes:

    > 1.  Order of fields:
    > *   CWT List
    > *   List of COSE_Sign/COSE_Sign1/COSE_Mac
    > *   Manifest
    > 2.  COSE_Sign contains a SUIT_Digest of the Manifest.

    > This would allow seek-free, fully modular processing of the manifest,
    > without the need to hold both the manifest and any signature primitives
    > in RAM at the same time.

This seems reasonable to me.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-