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

From: Jim Schaad <[email-masked]>
Date: Wed, 20 Mar 2019 09:06:48 +0100

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.

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.

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

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

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?

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.

Jim

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Mar 2019 17:02:47 -0400

> 1.  Section 2.1: Same comment as for LAMPS about stand-along tree

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

> function generates.  I don't know that this would ever be used but it is

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

Correct.  I will add that.

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

Okay.  I will add it here too.

> key each time I build a signature.  Should this be restated to allow for

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.

> 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