Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 11 Sep 2019 15:18:37 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-lamps-cms-hash-sig-09: 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-lamps-cms-hash-sig/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks, Russ, as always, for a clear and well-written document.
Some editorial nits:

— Section 1.3 —

   Each of these advances pose a
   threat to widely deployed digital signature algorithms.

“poses”, to match the singular “each”.

    Recent advances in cryptoanalysis [BH2013]

“cryptanalysis”, no “o”.

   The HSS/LMS signature algorithm does not depend on the difficulty of
   discrete logarithm or factoring, as a result these algorithms are

Comma splice.  Make it a semicolon.

— Section 2.2 —

   The second parameter is
   the number of bytes output by the hash function, m, which is the
   amount of data associated with each node in the tree.

It’s a small thing, but I think the “m” is misplaced where it is, and suggest
“…the number of bytes, m, output by the hash function….”

— Section 3 —

   Each format includes a counter and type
   codes that indirectly providing all of the information that is needed

“provide”

— Section 5 —

   When signed attributes are absent, the HSS/LMS signature is computed
   over the content.  When signed attributes are present, a hash is
   computed over the content using the same hash function that is used
   in the HSS/LMS tree, and then a message-digest attribute is
   constructed to contain the resulting hash value, and then the result
   of DER encoding the set of signed attributes (which MUST include a
   content-type attribute and a message-digest attribute, and then the
   HSS/LMS signature is computed over the DER-encoded output.

You’re missing a “)” there, which makes it a bit odd.  I think it should be
“(which MUST include a content-type attribute and a message-digest attribute),
and then….”

         digestAlgorithm MUST contain the one-way hash function used to in
         the HSS/LMS tree.

Remove “to”.

— Section 6 —

   While the consequences of an inadequate pseudo-random
   number generator (PRNGs) to generate these values is much less severe
   than the generation of private keys

“than in the generation”

— Appendix —
Just a note that I did not review the ASN.1 module.

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Sep 2019 17:14:19 -0400

Thanks for the careful review.

> “poses”, to match the singular “each”.

Fixed.

>   Recent advances in cryptoanalysis [BH2013]

Indeed.  Fixed.

> Comma splice.  Make it a semicolon.

How about:

   Since the HSS/LMS signature algorithm does not depend on the
   difficulty of discrete logarithm or factoring, the HSS/LMS signature
   algorithm is considered to be post-quantum secure.

> “…the number of bytes, m, output by the hash function….”

How about:

   The second parameter is
   the number of bytes output by the hash function, m, and it is the
   amount of data associated with each node in the tree. 

>   codes that indirectly providing all of the information that is needed

Fixed.

> “(which MUST include a content-type attribute and a message-digest attribute),

This text was changed to address a comment from Ben Kaduk.  It now says:

   When signed attributes are absent, the HSS/LMS signature is computed
   over the content.  When signed attributes are present, a hash is
   computed over the content using the same hash function that is used
   in the HSS/LMS tree, and then a message-digest attribute is
   constructed with the hash of the content, and then the HSS/LMS
   signature is computed over the DER-encoded set of signed attributes
   (which MUST include a content-type attribute and a message-digest
   attribute).  In summary:

      IF (signed attributes are absent)
      THEN HSS_LMS_Sign(content)
      ELSE message-digest attribute = Hash(content);
           HSS_LMS_Sign(DER(SignedAttributes))

>         digestAlgorithm MUST contain the one-way hash function used to in

Fixed.

>   than the generation of private keys

Sure.  Fixed.

> Just a note that I did not review the ASN.1 module.

Gee, why not?  ;-)

Russ

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Sep 2019 14:46:48 -0700

Thanks for the reply, Russ.  Just on the one thing that remains open;

>    amount of data associated with each node in the tree.

It retains the fault that "m" is not the hash function, and "by the
hash function, m," makes it look like it is.  I still think you're
better off moving "m" to one of these positions:

"The second parameter, m, is the number of bytes output by the hash function"
"The second parameter is the number of bytes, m, output by the hash function"

But I'll grant that I'm being picky about the wording, and that it's
not likely to be confusing in practice.  So if you think it's best
with the "m" where you have it, we're done here, and thanks for
considering my suggestions and accepting most of them.

Barry

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Sep 2019 17:50:04 -0400

> On Sep 16, 2019, at 5:46 PM, Barry Leiba <[email-masked]> wrote:
> 

I guess I missed your point on the first reading.

How about:

   The second parameter, m,
   is the number of bytes output by the hash function, and it is the
   amount of data associated with each node in the tree.

Russ

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Sep 2019 14:52:42 -0700

Perfect; thanks.

b