Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-08

[Russ Housley <[e-mail]>]

Roman:

Thanks for the careful review.  There are a couple of places where I do not understand your comment, but I have implemented the others in my edit buffer.  I hope we can sort out the others quickly.

> The following is my AD review of draft-ietf-lamps-cms-hash-sig-08.  Given the substance of these comments, it can be handled with IETF LC comments.
> 
> (1) Section 1.3.  Per the paragraph starting with "Today, RSA is often used to digitally sign software updates", why is this discussion about software updates in this draft?  If this is to motivate the weakness of these algorithms?  If so, why not also talk certificates?  An example using DSS?  IMO, this paragraph isn't needed.

This paragraph used to be in the security considerations.  It was suggested that the paragraph provides more of a motivation for why someone might want to implement the algorithm, so it was moved here.  I would like to keep the linkage for RFC 4108, but the rest of the paragraph can probably go away.  I suggest the linkage to RFC 4108 can be added to the 4th paragraph, which would result in:

   The HSS/LMS signature algorithm does not depend on the difficulty of
   discrete logarithm or factoring, as a result these algorithms are
   considered to be post-quantum secure.  One use of post-quantum secure
   signatures is the protection of software updates, perhaps using the
   format described in [FWPROT], to enable deployment of software that
   implements new cryptosystems.

> (2) Section 2.2.  Per "... a typecode indicating the particular LMS algorithm ...", where is typecode defined?

To make this clear, I suggest adding "As specified in [HASHSIG]," to the front of that paragraph.

> (3) Section 2.3, when describing the components of the LM-OTS signature value, y[] is not explained

To be explicit, I suggest: ... and a sequence of hash values (y[0] through y[p-1]) that correspond to the elements of the public key ...

> (4) Section 5.  How is the object identifier should be used for the content-type?

I do not understand this question.  None of the object identifiers in this document are used as to identify a content type.  There is a signature algorithm identifier and an ASN.1 module identifier.  The content type would be set depending on what is being signed.  As a result, this algorithm-specific document has nothing to say about content type.

> (5) Editorial matters
> 
> ** Abstract.  Typo.  s/the the/the/

Fixed.

> ** Abstract and Section 1.  Expand HSS/LMS on first use

Fixed.

> ** Abstract.  Editorial.  It seems odd to wait till the third paragraph to explain what is HSS/LMS.  Perhaps sentence one should be what is HSS/LMS (sentence 1).

The Abstract is only one paragraph, and the very first sentence does say that HSS/LMS is a hash-based signature algorithm:

   This document specifies the conventions for using the the HSS/LMS
   hash-based signature algorithm with the Cryptographic Message Syntax
   (CMS).  In addition, the algorithm identifier and public key syntax
   are provided.  The HSS/LMS algorithm is one form of hash-based
   digital signature; it is described in RFC 8554.

Likewise, as modified by the suggestion above, the first sentence of the Introduction also says that HSS/LMS is a hash-based signature algorithm:

   This document specifies the conventions for using the Hierarchical
   Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based
   signature algorithm with the Cryptographic Message Syntax (CMS) [CMS]
   signed-data content type.

> ** Section 1.3.  Would this section be better titled as "Motivation"?

Yes, I like that better.

> ** Section 1.3.  Editorial (remove colloquialism).  s/some researchers/researcher/

Changed.

> ** Section 1.3.  FWIW, I didn't find the quote compelling contextually.  Six years ago it suggests significant changes are coming but there is no follow-up on whether they were correct with the benefit of hindsight.  Likewise, the relevant advances in quantum computers isn't cited.
> 
> The reference is helpful.  Perhaps I would have just said:
> 
> "There have been recent advances in cryptoanalysis [BH2013] and in the development of quantum computers [insert ref].  Each of these advances pose a threat to widely deployed digital signature algorithms.  There is a need to prepare for a day that cryptosystems such as RSA and DSA that depend on discrete logarithm and factoring cannot be depended upon."

I suggest:

   Recent advances in cryptoanalysis [BH2013] and progress in the
   development of quantum computers [NAS2019] pose a threat to widely
   deployed digital signature algorithms.  As a result, there is a need
   to prepare for a day that cryptosystems such as RSA and DSA that
   depend on discrete logarithm and factoring cannot be depended upon.

and:

   [NAS2019] National Academies of Sciences, Engineering, and Medicine,
              "Quantum Computing: Progress and Prospects", The National
              Academies Press, DOI 10.17226/25196, 2019.

> ** Section 1.3.  The text "Hash-based signatures [HASSIG] are currently defined ... An IANA registry is defined ..." is duplicated almost verbatim again in Section 2.  Why is it needed twice.  IMO, it can be removed here.

Agree.  It is removed.

> ** Section 1.3. LM-OTS signature generation needs a reference.

That paragraph was removed based on the previous comment.

> ** Section 2.  Provide a reference to the IANA registry.

Reference added for:

https://www.iana.org/assignments/leighton-micali-signatures/leighton-micali-signatures.xhtml

> ** Section 2.1.  Per "Otherwise, generation of the entire tree might take weeks on longer", perhaps add "on a current <insert system type>".

The number of hash computations is huge to construct the entire tree, that is why HSS breaks it into manageable chunks.  The system type is not the issue at all.

> ** Section 2.1.  Cite the functions (i.e., u32str() is from [HASHSIG]) and string notation (i.e., "||" is concat)

On first use of these, I added:

where, u32str() and || are used as defined in [HASHSIG].

> ** s/in Section 3.3/in struct signed_public_key in Section 3.3/

I suggest:

   where, as defined in Section 3.3 of [HASHSIG], the signed_public_key
   structure contains the lms_signature over the public key followed by
   the public key itself.

Russ