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

zhangdacheng <dacheng.zhang@huawei.com> Mon, 24 July 2017 06:27 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 8CA1312EC30; Sun, 23 Jul 2017 23:27:18 -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 gHBDw5Q-iheB; Sun, 23 Jul 2017 23:27:16 -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 3482B120725; Sun, 23 Jul 2017 23:27:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLE17800; Mon, 24 Jul 2017 06:27:13 +0000 (GMT)
Received: from DGGEMI406-HUB.china.huawei.com (10.3.17.144) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 24 Jul 2017 07:27:12 +0100
Received: from DGGEMI501-MBS.china.huawei.com ([169.254.2.52]) by dggemi406-hub.china.huawei.com ([10.3.17.144]) with mapi id 14.03.0301.000; Mon, 24 Jul 2017 14:27:09 +0800
From: zhangdacheng <dacheng.zhang@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>
CC: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-curdle-cms-eddsa-signatures.all@ietf.org" <draft-ietf-curdle-cms-eddsa-signatures.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-curdle-cms-eddsa-signatures-06
Thread-Index: AdMEKyUNUNfXfz9sSLiAuvtL2NvqVA==
Date: Mon, 24 Jul 2017 06:27:08 +0000
Message-ID: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59759342.005E, 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: 501115b7265d815c3a43ba494d3809e6
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/7wqlimMQtNr3kgP46pMvjpf3vVg>
Subject: [secdir] 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: Mon, 24 Jul 2017 06:27:19 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). I think this document can be published after some tiny updates.

The comments are listed as follows:

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. 

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.

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

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

Cheers

Dacheng

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview