[secdir] 答复: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06

zhangdacheng <dacheng.zhang@huawei.com> Thu, 27 July 2017 09:16 UTC

Return-Path: <dacheng.zhang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EF57B13188F; Thu, 27 Jul 2017 02:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VBJrvdXhwNNp; Thu, 27 Jul 2017 02:15:59 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1FA127180; Thu, 27 Jul 2017 02:15:58 -0700 (PDT)
Received: from (EHLO lhreml701-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLJ95902; Thu, 27 Jul 2017 09:15:56 +0000 (GMT)
Received: from DGGEMI404-HUB.china.huawei.com ( by lhreml701-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 27 Jul 2017 10:15:54 +0100
Received: from DGGEMI501-MBS.china.huawei.com ([]) by dggemi404-hub.china.huawei.com ([]) with mapi id 14.03.0301.000; Thu, 27 Jul 2017 17:15:50 +0800
From: zhangdacheng <dacheng.zhang@huawei.com>
To: Russ Housley <housley@vigilsec.com>
CC: IETF SecDir <secdir@ietf.org>, IESG <iesg@ietf.org>, curdle <curdle@ietf.org>
Thread-Topic: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06
Thread-Index: AQHTBJmcnToY9SpHqUWCJHwmpqIR0KJju5nQ
Date: Thu, 27 Jul 2017 09:15:49 +0000
Message-ID: <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com>
References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> <CE259DDD-44B7-4B48-950A-A43D3FDDABF5@vigilsec.com>
In-Reply-To: <CE259DDD-44B7-4B48-950A-A43D3FDDABF5@vigilsec.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5979AF4D.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d0355d5fd6156d16a8383073044d4cb5
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4XDTjLtyGBbl2UMtY_G1604kqrg>
Subject: [secdir] =?gb2312?b?tPC4tDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRm?= =?gb2312?b?LWN1cmRsZS1jbXMtZWRkc2Etc2lnbmF0dXJlcy0wNg==?=
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 09:16:01 -0000

Hi, Russ:

See me comments below please.

> 1. In security considerations, the first and the second paragraphs are about how implementations protect the private keys and how they guarantee the quality of random numbers. Normally, this such considerations are out of scope of protocol specifications. But I am ok if the authors would like to keep them. 

These are implementation considerations that impact security.  I think they should stay in the document.

Dacheng: sure.

> 2. In the 4th paragraph of security considerations, ' the same private key SHOULD NOT be used with more than one EdDSA set of parameters.' -> ' the same private key MUST NOT be used with more than one EdDSA set of parameters.' Since we already know that the same private key used for multiple algorithms will cause potential risks, we should use a stronger word here.

I do not think that there is a problem with using the same private key with PureEdDSA and HashEdDSA.  The prudent advice is to avoid mixing the same private key with different parameter, thus the SHOULD NOT.  I point out that RFC 8032 goes even further:

   ... Thus, one can use the same
   key pair for Ed25519, Ed25519ctx, and Ed25519ph and correspondingly
   with Ed448 and Ed448ph.

Dacheng: Ok, I see your point. Then, I think it will be good to make some clarification here since the first sentence of this paragraph strongly argues that ' Using the same private key for different algorithms has the potential of allowing an attacker to get extra information about the private key.' Maybe we can change the second sentence to something like ' For this reason, the same private key SHOULD NOT be used with more than one EdDSA set of parameters, although people believe that no security issue will be caused when using the same private key with PureEdDSA and HashEdDSA [RFC8032]. '

> 3. In the 5th paragraph of security considerations, ' the same hash function should be used for all operations.' ->' the same hash function SHOULD be used for all operations.'

Yes, I agree.

> 4. In the 1st paragraph, 'When signing with Ed25519, the digestAlgorithm SHOULD include id-sha512' ->' When signing with Ed25519, the digestAlgorithm MUST include id-sha512'. 'When signing with Ed448, the digestAlgorithm SHOULD include id-shake256-len' -> 'When signing with Ed448, the digestAlgorithm MUST include id-shake256-len'.

I assume you are talking about Section 3.1 here.  These should not be changed to MUST.  CMS does not require these to be filled in, but stream-oriented processing works better if they are filled in.  Thus, the SHOULD statement.

Dacheng: No problem with that.