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

[Roman Danyliw <[e-mail]>]

Hi Russ!

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

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, July 12, 2019 4:00 PM
> To: Roman Danyliw <[e-mail]>
> Cc: [e-mail]
> 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:
> 
>    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.

Thanks for the history. The above works for me.

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

Works for me.  Thanks.

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

Works for me.  Thanks.

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

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

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

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

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

This works.  Thanks.

Roman

> Russ