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

zhangdacheng <dacheng.zhang@huawei.com> Fri, 28 July 2017 09:18 UTC

Return-Path: <dacheng.zhang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F814126E64; Fri, 28 Jul 2017 02:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga2dx80OXdT9; Fri, 28 Jul 2017 02:18:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C42D127136; Fri, 28 Jul 2017 02:18:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLL65322; Fri, 28 Jul 2017 09:18:30 +0000 (GMT)
Received: from DGGEMI404-HUB.china.huawei.com (10.3.17.142) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Jul 2017 10:18:28 +0100
Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.52]) by dggemi404-hub.china.huawei.com ([10.3.17.142]) with mapi id 14.03.0301.000; Fri, 28 Jul 2017 17:18:20 +0800
From: zhangdacheng <dacheng.zhang@huawei.com>
To: Russ Housley <housley@vigilsec.com>
CC: curdle <curdle@ietf.org>, IESG <iesg@ietf.org>, IETF SecDir <secdir@ietf.org>
Thread-Topic: [Curdle] 答复: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06
Thread-Index: AQHTBJmcnToY9SpHqUWCJHwmpqIR0KJju5nQgAOseQCAAZNBcA==
Date: Fri, 28 Jul 2017 09:18:19 +0000
Message-ID: <879E76B64CF340468BF5E4DE504C22420160BF93@dggemi501-mbs.china.huawei.com>
References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com> <CE259DDD-44B7-4B48-950A-A43D3FDDABF5@vigilsec.com> <879E76B64CF340468BF5E4DE504C22420160BC01@dggemi501-mbs.china.huawei.com> <E8D09FCA-3556-4735-B565-42ACC0F8E6C2@vigilsec.com>
In-Reply-To: <E8D09FCA-3556-4735-B565-42ACC0F8E6C2@vigilsec.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.167.227]
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.0A020202.597B0166.0120, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.52, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8f00d14e0d2cc21ec37eee1e0b30efff
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/nJiqyhrzBl5jVEVw6Oxfhn5GdD4>
Subject: [secdir] 答复: [Curdle] 答复: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06
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: Fri, 28 Jul 2017 09:18:35 -0000

Great!

-----邮件原件-----
发件人: Russ Housley [mailto:housley@vigilsec.com] 
发送时间: 2017年7月28日 1:14
收件人: zhangdacheng <dacheng.zhang@huawei.com>
抄送: curdle <curdle@ietf.org>; IESG <iesg@ietf.org>; IETF SecDir <secdir@ietf.org>
主题: Re: [Curdle] 答复: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06

Dacheng:

Trimming the parts where we have reached agreement...

>> 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]. '

How about:

Using the same private key with different algorithms has the potential to leak extra information about the private key to an attacker.  For this reason, the same private key SHOULD NOT be used with more than one set of EdDSA parameters, although people believe that there are no security concerns when using the same private key with PureEdDSA and HashEdDSA [EDDSA].

Russ