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

Russ Housley <housley@vigilsec.com> Fri, 12 July 2019 23:17 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975451200B5 for <spasm@ietfa.amsl.com>; Fri, 12 Jul 2019 16:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqSTWB9IehFR for <spasm@ietfa.amsl.com>; Fri, 12 Jul 2019 16:17:03 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2C1120071 for <spasm@ietf.org>; Fri, 12 Jul 2019 16:17:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3AE1F300AB6 for <spasm@ietf.org>; Fri, 12 Jul 2019 18:57:45 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WAowthrBT_jn for <spasm@ietf.org>; Fri, 12 Jul 2019 18:57:43 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id DD5E03009FF; Fri, 12 Jul 2019 18:57:42 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33CF7C6@marchand>
Date: Fri, 12 Jul 2019 19:16:59 -0400
Cc: "spasm@ietf.org" <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <88159848-8B39-4A78-A506-1E96D43AEBF0@vigilsec.com>
References: <359EC4B99E040048A7131E0F4E113AFC01B33CD760@marchand> <AB48616C-F819-486D-AD94-C4EE6EAC621A@vigilsec.com> <359EC4B99E040048A7131E0F4E113AFC01B33CF7C6@marchand>
To: "Roman D. Danyliw" <rdd@cert.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/2FB3wb9PYpyTrkFbqxpw7vsXCCE>
Subject: Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-08
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 23:17:06 -0000

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 <rdd@cert.org> wrote:
> 
> Hi Russ!
> 
> Thanks for the quick response.  The proposed edits address my concerns.  Minor things inline ...
> 
>> -----Original Message-----
>> From: Russ Housley [mailto:housley@vigilsec.com]
>> Sent: Friday, July 12, 2019 4:00 PM
>> To: Roman Danyliw <rdd@cert.org>
>> Cc: spasm@ietf.org
>> 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
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm