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

Barry Leiba <> Mon, 01 June 2020 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CABA63A152E; Mon, 1 Jun 2020 13:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MuNv9ggdgyKV; Mon, 1 Jun 2020 13:15:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F8DB3A152D; Mon, 1 Jun 2020 13:15:06 -0700 (PDT)
Received: by with SMTP id s18so8376169ioe.2; Mon, 01 Jun 2020 13:15:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DSHuQZxKOOnnKnf0hYwbcus9E8Gn9WIOWzyeUpSOAdw=; b=PC7AgQYlG2jevYCnZ2Q9NnwUn8JEgjBaKp+rsHj/cnE4dO++vSehEPJHekK00NeVi/ UTgoXDt9HWRjAU8hv9PsuDLyfXvfv/8KBav3WmODXUopNir/8qOd97nyMjUKGNseBBIo YH1V6v3IHLD6qhaMXHDYL6z4pAadCHGMLnzQxURsirx3qyT2rhQ+DyKm41ewLAeWESW1 HUWaK1H4KEocFlPp+kSM7RMLqhY2aRMV3T0XYdiF1Hkrtx4KCg2ZTAd1LhkEawvMGMDj ojFvuE40yLdGrTnCNDVoslzmvg3IJF1kIcWLQum2BO13yuYcjPqYEuVOGmff69Lryc6Q E40A==
X-Gm-Message-State: AOAM5334ih2k6NmPu58z67M3RGkxJOZ6MoSMfiHdM2wbi14tOV6dJgMX 9si6/iUb12p+e33d0S4CKHNivXvbxUgI2MmM+V4=
X-Google-Smtp-Source: ABdhPJyi9GBnJSpomEU/GvF7AtHDq3RxIw8ZTbv3Dddikm2eEJ7MsqP/gCCEnFbcPkNZjFtGlmzu75zu08go9nm2rwU=
X-Received: by 2002:a02:cd89:: with SMTP id l9mr21878209jap.88.1591042504940; Mon, 01 Jun 2020 13:15:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <000001d6384e$3b3ac480$b1b04d80$>
In-Reply-To: <000001d6384e$3b3ac480$b1b04d80$>
From: Barry Leiba <>
Date: Mon, 1 Jun 2020 16:14:53 -0400
Message-ID: <>
To: Jim Schaad <>
Cc: Warren Kumari <>, The IESG <>, Ivaylo Petrov <>,,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [COSE] Warren Kumari's No Objection on draft-ietf-cose-hash-algs-04: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jun 2020 20:15:08 -0000

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.  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


On Mon, Jun 1, 2020 at 3:53 PM Jim Schaad <> wrote:
> -----Original Message-----
> From: Warren Kumari via Datatracker <>
> Sent: Monday, June 1, 2020 6:26 AM
> To: The IESG <>
> Cc:;;; Ivaylo Petrov <>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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.