Re: [lamps] New Version Notification for draft-ietf-lamps-cms-hash-sig-00.txt

Daniel Van Geest <Daniel.VanGeest@isara.com> Sun, 23 September 2018 15:45 UTC

Return-Path: <Daniel.VanGeest@isara.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 52CF4130E05 for <spasm@ietfa.amsl.com>; Sun, 23 Sep 2018 08:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 O0uDNByN-cJA for <spasm@ietfa.amsl.com>; Sun, 23 Sep 2018 08:45:16 -0700 (PDT)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 D73FD130E01 for <spasm@ietf.org>; Sun, 23 Sep 2018 08:45:15 -0700 (PDT)
Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip1.isaracorp.com with ESMTP; 23 Sep 2018 15:45:12 +0000
Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR01.isaracorp.com (10.5.8.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1466.3; Sun, 23 Sep 2018 11:45:12 -0400
Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1466.003; Sun, 23 Sep 2018 11:45:12 -0400
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: Russ Housley <housley@vigilsec.com>, SPASM <spasm@ietf.org>
Thread-Topic: [lamps] New Version Notification for draft-ietf-lamps-cms-hash-sig-00.txt
Thread-Index: AQHURJGd3FhU+mTXlk+eAOgH9lLEPKT+hEUA
Date: Sun, 23 Sep 2018 15:45:12 +0000
Message-ID: <A5BB78E9-BC2F-4435-BB14-007972DEA1A8@isara.com>
References: <153609366946.14267.16426510024257902857.idtracker@ietfa.amsl.com> <5AB05085-94A0-4ECB-BB57-2360087345D4@vigilsec.com>
In-Reply-To: <5AB05085-94A0-4ECB-BB57-2360087345D4@vigilsec.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.5.17.158]
Content-Type: text/plain; charset="utf-8"
Content-ID: <82BC48CB136ADB43BE40DD8A592EB4ED@isara.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/tGTrASQXNEK03SL3_Mv3sfg7QYc>
Subject: Re: [lamps] New Version Notification for draft-ietf-lamps-cms-hash-sig-00.txt
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: Sun, 23 Sep 2018 15:45:18 -0000

Hi Russ, some comments.

1. Regarding the recommendation that SHA-256 be used to compute the message digest.
The LM-OTS signature generation prepends a random string (plus other metadata) to the message before hashing it [1]:
        Q = H(I || u32str(q) || u16str(D_MESG) || C || message)
This reduces the chances of being able to find collisions, effectively changing the problem to finding a second preimage.  A second preimage can be found in O(2^(n/2)) queries with Grover's algorithm.  For SHA-256 this is O(2^128), which is sufficiently secure.

But by using SHA-256 to compute the message digest in CMS, and passing that digest to HSS to be (randomized-hashed and) signed, this removes the advantage given by the randomized hash.  An attacker could look for collisions on the CMS pre-hash instead of the HSS randomized hash.  A quantum computer can find collisions in O(2^(n/3)) queries[2], or O(2^85.3) for SHA-256, which is probably not sufficiently secure.  That said, there are arguments[3] that the hardware cost for the algorithm in [2] is greater than the query cost.  This argument makes certain assumptions on hardware limitations, and I don't think it precludes the possibility of a quantum algorithm with the same query complexity as [2] but with better hardware costs.

So anyways, for this draft you might want to consider that a SHA-256 message digest within CMS might provide insufficient security against a quantum collision attack and recommend SHA-512 (or SHA-384) instead.


2. The draft's ASN.1 module defines the HSS public key (pk-HSS-LMS-HashSig), but the rest of the draft makes no mention of HSS public key algorithm identifier or properties (parameters, key usage, public key encoding).  Is this something that should be specified in this draft?  In another draft?  My employer has seen interest in HSS (and XMSS) for root certificates and code signing certificates so I was going to write and propose a draft for HSS/XMSS in X.509 certificates to support those use cases.  If the public key is well defined in the CMS draft I can reference it, or I can take on the definition.


3. It had been suggested by Panos in this draft's call to add to the recharter that it be expanded to include other hash-based signatures like XMSS.  Since that was not included in the recharter, is it off the table?


4. Nits:
- Several places in Section 3 id-alg-hss-lms-hashsig is referred to as an algorithm identifier, but it is an object identifier.
- in 2.1 signed_public_key is misspelled as sigend_public_key in one place.
- draft-mcgrew-hash-sigs-13 defines Nspk = L-1 where L is the number of levels, and then an HSS signature as:
    u32str(Nspk) || signed_pub_key[0] || ... || signed_pub_key[Nspk-1] || sig[Nspk]
The CMS draft isn't consistent with that, so this:
	   The elements of the HSS signature value for a tree with Nspk levels
	   can be summarized as:

	      u32str(Nspk) ||
	      signed_public_key[1] ||
	      signed_public_key[2] ||
	         ...
	      sigend_public_key[Nspk-1] ||
	      signed_public_key[Nspk] ||
	      lms_signature_on_message
should be:
	   The elements of the HSS signature value for a tree with L levels
	   can be summarized as:

	      u32str(L-1) ||
	      signed_public_key[0] ||
	      signed_public_key[1] ||
	         ...
	      signed_public_key[L-2] ||
	      lms_signature_on_message
or something to the same effect.

Thanks,
Daniel

[1] https://tools.ietf.org/html/draft-mcgrew-hash-sigs-13#section-4.5
[2] https://www.cs.princeton.edu/~mzhandry/docs/papers/QCol.pdf
[3] https://cr.yp.to/hash/collisioncost-20090823.pdf



On 2018-09-04, 10:55 PM, "Spasm on behalf of Russ Housley" <spasm-bounces@ietf.org on behalf of housley@vigilsec.com> wrote:

    Throughout the document, the terminology was changed to make it clear that this hs about HSS/LMS hash-based signatures.
    
    Russ
    
    
    > A new version of I-D, draft-ietf-lamps-cms-hash-sig-00.txt
    > has been successfully submitted by Russ Housley and posted to the
    > IETF repository.
    > 
    > Name:		draft-ietf-lamps-cms-hash-sig
    > Revision:	00
    > Title:		Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)
    > Document date:	2018-08-31
    > Group:		lamps
    > Pages:		13
    > URL:            https://www.ietf.org/internet-drafts/draft-ietf-lamps-cms-hash-sig-00.txt
    > Status:         https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/
    > Htmlized:       https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-00
    > Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig
    > 
    > 
    > Abstract:
    >   This document specifies the conventions for using the the HSS/LMS
    >   hash-based signature algorithm with the Cryptographic Message Syntax
    >   (CMS).  The HSS/LMS algorithm is one form of hash-based digital
    >   signature; it is described in [HASHSIG].
    > 
    > 
    > 
    > 
    > Please note that it may take a couple of minutes from the time of submission
    > until the htmlized version and diff are available at tools.ietf.org.
    > 
    > The IETF Secretariat
    > 
    
    _______________________________________________
    Spasm mailing list
    Spasm@ietf.org
    https://www.ietf.org/mailman/listinfo/spasm