Re: [COSE] Review of draft-ietf-cose-hash-sig-01

Russ Housley <housley@vigilsec.com> Wed, 20 March 2019 21:02 UTC

Return-Path: <housley@vigilsec.com>
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 A38E3129AA0 for <cose@ietfa.amsl.com>; Wed, 20 Mar 2019 14:02:52 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 xE8lOPjDV8fN for <cose@ietfa.amsl.com>; Wed, 20 Mar 2019 14:02:50 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831B0124BF6 for <cose@ietf.org>; Wed, 20 Mar 2019 14:02:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B8583300AB3 for <cose@ietf.org>; Wed, 20 Mar 2019 16:44:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Nm0BFIeksIHL for <cose@ietf.org>; Wed, 20 Mar 2019 16:44:31 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id F10A330024F; Wed, 20 Mar 2019 16:44:30 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <010e01d4def3$dff43610$9fdca230$@augustcellars.com>
Date: Wed, 20 Mar 2019 17:02:47 -0400
Cc: cose <cose@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F6B7C86-BDC0-4114-A69F-7E428D184DEA@vigilsec.com>
References: <010e01d4def3$dff43610$9fdca230$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/gltSzmfG6nm4Lu9vAD6QzqccLGQ>
Subject: Re: [COSE] Review of draft-ietf-cose-hash-sig-01
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: Wed, 20 Mar 2019 21:02:53 -0000

Jim:

> First, I don't think I have any technical issues with how to use this with
> COSE, that said I find there are numerous issues about the description of
> HSS/LMS.
> 
> 1.  Section 2.1: Same comment as for LAMPS about stand-along tree
> definition.

I will try to align the LAMPS and COSE documents now that the LAMPS document has been sent to the IESG.

> 2.  Section 2.2: LMS systems have three not two parameters, Hash Function, #
> of bytes used, tree depth.  It is possible to use fewer bytes than the hash
> function generates.  I don't know that this would ever be used but it is
> more correct.

The exchange with Scott Fluhrer indicates that the shortened hash is possible, but it is not clear why one would do that.

> 3.  Section 2.2: The registry would also allow for new hash functions to be
> used as well.

Correct.  I will add that.

> 4. Section 2.3: See comment #2 about adding hash function

Okay.  I will add it here too.

> 5.  Section 4.1:  In paragraph 3, implementation currently violates the
> conditions in this paragraph.  I am resigning the same input with the same
> key multiple times because I need to generate the signature on the public
> key each time I build a signature.  Should this be restated to allow for
> that to occur?

Paragraph 3 says:

   The generation of private keys relies on random numbers.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to reproduce the PRNG environment that produced the keys,
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult.  [RFC4086] offers important guidance in
   this area.

I do not understand what you want to change.

> 6. Section 4.1:  I think that it might be worth while having a statement
> about the use of appendix A in [HASHSIG].  The use of this does two things:
> 1) it decreases the size of the private key and 2) it decreases the
> effective size of the private key down to the seed value rather than having
> all of the LMOTS keys generated independently.

The Introduction includes:

  ...  The HSS/LMS private key can be very
   small when the signer is willing to perform additional computation at
   signing time; alternatively, the private key can consume additional
   memory and provide a faster signing time.

What security consideration does this raise?

Russ