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

From: Roman Danyliw <[email-masked]>
Date: Thu, 11 Jul 2019 17:25:57 +0000

Hi!

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.

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

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

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

(5) Editorial matters

** Abstract.  Typo.  s/the the/the/

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

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

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

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

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

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

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

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

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

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

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2019 15:59:44 -0400

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.

> (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…

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.

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

> "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 algo…

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,…

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

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 12 Jul 2019 20:56:53 +0000

Hi Russ!

Thanks for the quick response.  The proposed edits address my concerns.  Minor things inline ...

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, July 12, 2019 4:00 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-08
> 
> 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:
> 

Thanks for the history. The above works for me.

> To make this clear, I suggest adding "As specified in [HASHSIG]," to the front

Works for me.  Thanks.

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

Works for me.  Thanks.

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

I re-read my comment, I'm not sure what I was thinking.  Oops.  Sorry for the noise.

> > ** 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:
> 
> Likewise, as modified by the suggestion above, the first sentence of the
> Introduction also says that HSS/LMS is a hash-based signature algorithm:
> 
> > ** 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.
> >
> > "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:
> 
> > ** 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.
> 

Thanks for making all of the changes described above.

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

Ok.  I was trying suggest an approach to caveat why construction takes so long now (thinking that in the future, improved computation resources could change construction time).

>    structure contains the lms_signature over the public key followed by

This works.  Thanks.

Roman

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2019 19:16:59 -0400

Roman:

Thanks.  I will wait to see what other IETF Last Call comments come along before posting a revision.

Russ

> On Jul 12, 2019, at 4:56 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Russ!
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm