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
- [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-… Roman Danyliw
- Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-… Russ Housley
- Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-… Roman Danyliw
- Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-… Russ Housley