Re: [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-08
Roman Danyliw <rdd@cert.org> Fri, 12 July 2019 20:57 UTC
Return-Path: <rdd@cert.org>
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 DB1171201DC for <spasm@ietfa.amsl.com>; Fri, 12 Jul 2019 13:57:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 DV17k6mTbk9C for <spasm@ietfa.amsl.com>; Fri, 12 Jul 2019 13:56:58 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3F512006B for <spasm@ietf.org>; Fri, 12 Jul 2019 13:56:58 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6CKuvns004959; Fri, 12 Jul 2019 16:56:57 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6CKuvns004959
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1562965017; bh=M091/u/LMWgvjQjm8Ugy9TBBupBLjhA552qIfCWYCSA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Rz87QL6OtW1Kj1C6LTHMNiJPvV5xg0to/1+bLF00XgLgCIbzmFxWU1PC0azpmw9WR VTTE3hlngjUGW1TDDEW2xX7iAIuohW6y8LyZ2Q5NGb0ADYwk6VnGFJxruw4aUTr/xb zG4bKEdzrTNuD2RMG46QpIjmTTbenlkS7k7Eoq8k=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6CKusVS020476; Fri, 12 Jul 2019 16:56:54 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 16:56:54 -0400
From: Roman Danyliw <rdd@cert.org>
To: Russ Housley <housley@vigilsec.com>
CC: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: [lamps] AD Review: draft-ietf-lamps-cms-hash-sig-08
Thread-Index: AdU4DFJniyrzBBvrQQ2vMK3V3JcnmwBAY4EAAAay/YA=
Date: Fri, 12 Jul 2019 20:56:53 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33CF7C6@marchand>
References: <359EC4B99E040048A7131E0F4E113AFC01B33CD760@marchand> <AB48616C-F819-486D-AD94-C4EE6EAC621A@vigilsec.com>
In-Reply-To: <AB48616C-F819-486D-AD94-C4EE6EAC621A@vigilsec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/QMiXIJdsbDdMy-nDDT2PNs7t3xk>
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 20:57:02 -0000
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
- [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