Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

Carsten Bormann <cabo@tzi.org> Tue, 28 July 2020 21:14 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2903D3A07FC for <cbor@ietfa.amsl.com>; Tue, 28 Jul 2020 14:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 A2nJXbF57bTB for <cbor@ietfa.amsl.com>; Tue, 28 Jul 2020 14:13:59 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59D0F3A07EE for <cbor@ietf.org>; Tue, 28 Jul 2020 14:13:59 -0700 (PDT)
Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BGTts6SsXzyWb; Tue, 28 Jul 2020 23:13:57 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com>
Date: Tue, 28 Jul 2020 23:13:57 +0200
Cc: Brendan Moran <Brendan.Moran@arm.com>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 617663637.328707-b3fa56c40a1872201397e42e19a92290
Content-Transfer-Encoding: quoted-printable
Message-Id: <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org>
References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/1EDqymH0aVFSG61rlcYy5dcCUmY>
Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 21:14:02 -0000

> On 2020-07-28, at 19:18, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> [Brendan] One of the questions that I have is the order of compressing and applying security operations.  If you are using a pull parser do you think it is going to be easier (we can talk about more secure later) to do the hashing on the compressed or uncompressed version.  

Whoa.  We normally hash byte strings.
So are you proposing that, say, a compressed version is received, it is uncompressed, re-serialized in deterministic encoding, and then hashed?

> This could be an even harder question to ask with the use of an external dictionary.  There is one potential benefit w/ COSE in that the hash of the dictionary could be included as external data.

There are two aspects here:
— how do we make sure the external dictionary cannot be surreptitiously exchanged by an attacker
— how do we make sure there is an unambiguous way to integrate the external dictionary/-ies into the prefix and sharing tables?

I have a design for the latter that I still need to write up.

For the former, a COSE hash algorithm + the hash would do; the dictionary would be hashed as an encoded CBOR data item.  There is a question whether there should be a way to put in a (compact!) identifier for the dictionary as well, so the hash in the external data isn’t a trapdoor function.

Grüße, Carsten