Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)

Warren Kumari <warren@kumari.net> Tue, 02 June 2020 19:35 UTC

Return-Path: <warren@kumari.net>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC66E3A0F7A for <cose@ietfa.amsl.com>; Tue, 2 Jun 2020 12:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 2BLDRQ9mEyMl for <cose@ietfa.amsl.com>; Tue, 2 Jun 2020 12:35:49 -0700 (PDT)
Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 D22AE3A0F75 for <cose@ietf.org>; Tue, 2 Jun 2020 12:35:48 -0700 (PDT)
Received: by mail-lj1-x242.google.com with SMTP id m18so14044065ljo.5 for <cose@ietf.org>; Tue, 02 Jun 2020 12:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rYeL0P3wVQtbneEYPGOioR6biB7iBUJeTmKrngbtHv0=; b=r5usDJAN9CHRViMl2Ttor7kIkBjttiu5hLAWdA63jt0tbM3Q1XgnY+OGyfJkNlGUVz qSiCAtYJ1l1i9bHKJx6JO/HcR2o+9MlSZGfCnGKsqqRsD/gCgS8569yp0hc0mXeOXUAN saC6s2diaHKWdGoddTO8viOrGmMdmmZ4UbGWdmE0+qR78nUtsb7ukx3ExhR6uGr5xBx9 Hz4HMelAnnufdEz0d91cjcrxT5cD47FkS3xnGq8OcnbJf0tMnR2gFNWuTT2LbwYDnYjp pSVZFJseTFfrr09ncy0rXpFa7NWEAiXKGTcd0/fg4u0weoebAj+HQJuB1yOSOjKJlV9i Nz5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rYeL0P3wVQtbneEYPGOioR6biB7iBUJeTmKrngbtHv0=; b=ZDWJsHBghBQ16IGt0AjsP8s64ebjpFvrnRMQ+d0CLGcZHmSHDrRuT4Rfut36ENfb11 jzJ/2fS5nIJtHRHu19YeNnR5Zg+i/qLqleBc1uQu0aOiMhge2Whbr844frFJzXUrCoqE +Fuwhi8iq1ULKOg7o4uJLdsvpR/nCXIbs8ljJlSlsFqUtXgHWoUiwFn/Uk39tzmIlVg0 TFzSNp2ntN+d0UJx+0WSpSl11ALBqnA+iRgy3DGmUC8URsIIgg0suxTGp129CSqxhdaz 0l70PXPj8rlPKTBQ0vKiBBOUJPwJQ/3FyKSKj6nyNYAbRvhUf6ev+Z5U24iKmsOEOQox 833Q==
X-Gm-Message-State: AOAM5315FgkCT0HHkZ/2/fkVFaXiregswD8qilb4IaBlRHfxSwh8NxNU J4LBr4I7tPRlqN4aedXwf2iNPEmJsH1oLNFoBdrnnA==
X-Google-Smtp-Source: ABdhPJw7jtj9EGWQdBNW+xkKLfyn8Yjr+AXSKtb4piBYiPctnHJnlWOyQNch8zXenF3GnQNxG/DcnKHhoB4OGnlhmMM=
X-Received: by 2002:a2e:6c15:: with SMTP id h21mr317074ljc.403.1591126546526; Tue, 02 Jun 2020 12:35:46 -0700 (PDT)
MIME-Version: 1.0
References: <159101794967.27986.902730371235702504@ietfa.amsl.com> <000001d6384e$3b3ac480$b1b04d80$@augustcellars.com> <CALaySJ+u5fgKJTB5HBiAY=_9MCFh0+QEPV6w1AEH9P-Qtw=4NQ@mail.gmail.com> <CAHw9_i+O4Z9XyyZwchSojRTukTk_fCiuPmgmZgO5Fzxgrz_8Xg@mail.gmail.com> <005c01d63907$7d7bfbc0$7873f340$@augustcellars.com>
In-Reply-To: <005c01d63907$7d7bfbc0$7873f340$@augustcellars.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 2 Jun 2020 15:35:09 -0400
Message-ID: <CAHw9_iL-6boW5V3QCwOJTihyrNJ_1MA0AmE39=x5xyqx+fyTWA@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>, Ivaylo Petrov <ivaylo@ackl.io>, cose-chairs@ietf.org, draft-ietf-cose-hash-algs@ietf.org, cose@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/in1sQZnaI-CQF6uzsFtX4TK2i-U>
Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 19:35:52 -0000

On Tue, Jun 2, 2020 at 1:59 PM Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>
> -----Original Message-----
> From: Warren Kumari <warren@kumari.net>
> Sent: Tuesday, June 2, 2020 6:52 AM
> To: Barry Leiba <barryleiba@computer.org>
> Cc: Jim Schaad <ietf@augustcellars.com>om>; The IESG <iesg@ietf.org>rg>; Ivaylo Petrov <ivaylo@ackl.io>io>; cose-chairs@ietf.org; draft-ietf-cose-hash-algs@ietf.org; cose@ietf.org
> Subject: Re: Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)
>
> On Mon, Jun 1, 2020 at 4:15 PM Barry Leiba <barryleiba@computer.org> wrote:
> >
> > Put another way, I think that Warren is asking if a bad actor can
> > trick you into downloading something anyway, and only after to wasted
> > the download will you find out that you shouldn't have bothered.
>
> Nah, not quite -- "Doing indirect signing allows for a signature to be validated without first downloading all of the content associated with the signature.  This capability can be of  even greater importance in a constrained environment as not all of  the content signed may be needed by the device."
>
> Sorry, I'm still not getting it
>
> I can see a signature over something like a manifest, listing all of the "things" (firmware blocks, files, whatever). I can download this, and validate the signature, and know that the manifest came from the e.g device manufacturer. I can then look through and find the thing (let's pretend it's a URL to a firmware update), go fetch that, hash it and then check that the "Hash of the bytes of the update" match what was in the manifest.
> But, in both of these cases, I have to download the entire thing that is signed or hashed (first the manifest, and all of the bytes of the update *for my device type*).
>
> In another example, if this were a book, if I only cared about the chapter about doughnuts, I would check the index (and signature over the index), and then go hash the chapter that the index points to, and make sure that it matches -- but, I've still had to a: check the signature on the index (which requires the entire index) and b: hash the entire doughnuts chapter (which means I need the entire doughnuts chapter). Yes, I don't need to hash the chapter on macarons or Mille feuilles, but I'm still having to download / hash the content associated with the signature...
>
> Or, is this just saying that the index contains hashes for the individual blocks (chapters), and so I just need to download the entire index and check the signature, and then the block(s) that I care about (and that the hashes match what is in the index)?
>
> [JLS] This is the case, all we have is an index that contains the hashes of the individual blocks.  You only need to download what you care about.  Thus you don't need to download the chapter on macarons, even though you have the pointer and hash of that data.  If you later become interested in macarons you can down load that chapter and check that it has the correct hash.
>


Oh, well that's all good then, but certainly isn't what I'd initially
thought the text was trying to say.

Perhaps something like:
"Indirect signing allows for a signature over a set of hashes of
chunks of content to be validated without first
downloading all of the content. This capability
can be of even greater importance in a constrained environment, as the
device needs only download and hash the chunks it is interested in." ?

Of course, this is all just a comment, and this might be blindingly
obvious to everyone else / the intended audience (AKA, I will not be
offended if you choose to ignore this / leave it as is...)

Thanks for the explanation,
W

> Jim
>
> I'm really not trying to be difficult, I'm just confused...
> W
>
>
> > The
> > answer to that is, "Sure."  The point here is that the download can be
> > saved most of the time, during normal operation.  And the signature
> > protects against the abnormal situations (such as someone trying to
> > spoof an update).  Nothing is perfect, but the combination is
> > beneficial.
> >
> > Barry
> >
> > On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad <ietf@augustcellars.com> wrote:
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Warren Kumari via Datatracker <noreply@ietf.org>
> > > Sent: Monday, June 1, 2020 6:26 AM
> > > To: The IESG <iesg@ietf.org>
> > > Cc: draft-ietf-cose-hash-algs@ietf.org; cose-chairs@ietf.org;
> > > cose@ietf.org; Ivaylo Petrov <ivaylo@ackl.io>io>; ivaylo@ackl.io
> > > Subject: Warren Kumari's No Objection on
> > > draft-ietf-cose-hash-algs-04: (with COMMENT)
> > >
> > > Warren Kumari has entered the following ballot position for
> > > draft-ietf-cose-hash-algs-04: No Objection
> > >
> > > When responding, please keep the subject line intact and reply to
> > > all email addresses included in the To and CC lines. (Feel free to
> > > cut this introductory paragraph, however.)
> > >
> > >
> > > Please refer to
> > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > for more information about IESG DISCUSS and COMMENT positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found here:
> > > https://datatracker.ietf.org/doc/draft-ietf-cose-hash-algs/
> > >
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > COMMENT:
> > > --------------------------------------------------------------------
> > > --
> > >
> > > Thank you for writing this - it was an interesting read.
> > >
> > > I do have one issue, which I cannot tell if it is simply me being dumb, or if the text needs more work.
> > >
> > > “ Doing indirect signing allows for a signature to be validated without first downloading all of the  content associated with the signature.  This capability
> > > can be of   even greater importance in a constrained environment as not all of
> > >  the content signed may be needed by the device.”
> > >
> > > I’m unclear how this works —  itseems clear enough that I can verify that the signature matches the hash, but doesn’t the device need to still download and compute the hash over all of the content?
> > >
> > > Otherwise I could take a hash and signature from content A, and claim that it is for content B. Sure, if the signature **doens’t** match the hash I know not to bother downloading the content at all, but if the sig does match the hash I still need to download the content to check that the hash is for this content....
> > >
> > > Please help educate me!
> > >
> > > [JLS] I am more than willing to help educate.  You are going to be seeing some of this from the SUIT people as well.  For a firmware type update you might defined a structure that looks like:
> > > FirmwareBlock  = Array of (
> > >         Text description of block
> > >         Hardware target
> > >         Version number
> > >         URL to the bytes of the update
> > >         Hash algorithm identifier
> > >         Hash of the bytes of the update
> > >
> > > A message containing an array of these blocks is created, a COSE signed message is then created containing this array of blocks as the content of the message and sent to the piece of hardware.
> > >
> > > The hardware can then validate the signed message, walk the array of blocks, if the block applies download the bytes pointed to by the URL, hash the bytes downloaded and compare the hash values.  If the hash values match then the bytes can be applied to the device.  This allows a device to only download the bytes that are needed, ignoring those which have either already been applied or which are not relevant to the device.
> > >
> > > This is what I call an indirect signature, the block of data pointed to by the URL is not part of the message is implicitly signed since the hash of the data block is signed rather than the actual data.  It is interesting to note that this is the way that CMS has always worked, the hash of the message is placed in an array of attributes and that array of attributes is what is signed by the signature algorithm.
> > >
> > > Nit: “ A pointer to the value that was hashed.  this could” —
> > > s/this/This/
> > >
> > > [JLS] Fixed.
> > >
> > >
> > >
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf