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

Russ Housley <housley@vigilsec.com> Mon, 24 July 2017 16:26 UTC

Return-Path: <housley@vigilsec.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 90BD0131EA0 for <secdir@ietfa.amsl.com>; Mon, 24 Jul 2017 09:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NVLAdF92nqJy for <secdir@ietfa.amsl.com>; Mon, 24 Jul 2017 09:26:23 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF491131E97 for <secdir@ietf.org>; Mon, 24 Jul 2017 09:26:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0D04D300557 for <secdir@ietf.org>; Mon, 24 Jul 2017 12:26:23 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2oNqBvNyn7NG for <secdir@ietf.org>; Mon, 24 Jul 2017 12:26:21 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2A802300288; Mon, 24 Jul 2017 12:26:21 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com>
Date: Mon, 24 Jul 2017 12:26:20 -0400
Cc: IETF SecDir <secdir@ietf.org>, IESG <iesg@ietf.org>, curdle <curdle@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE259DDD-44B7-4B48-950A-A43D3FDDABF5@vigilsec.com>
References: <879E76B64CF340468BF5E4DE504C22420160B1FA@dggemi501-mbs.china.huawei.com>
To: zhangdacheng <dacheng.zhang@huawei.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/HOM82wwQ56bNKwV1aRLRTnI2bPY>
Subject: Re: [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 16:26:26 -0000

Dacheng:

Thanks for taking the time to review the document.

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

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

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

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

Russ