Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 30 May 2017 11:31 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12327129BD8 for <curdle@ietfa.amsl.com>; Tue, 30 May 2017 04:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.523
X-Spam-Level:
X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 o_gQ5Kw_L-Wh for <curdle@ietfa.amsl.com>; Tue, 30 May 2017 04:31:27 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07121120454 for <curdle@ietf.org>; Tue, 30 May 2017 04:31:27 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9468C81235; Tue, 30 May 2017 11:31:26 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9468C81235
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=nmav@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9468C81235
Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.69]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE62318C5A; Tue, 30 May 2017 11:31:25 +0000 (UTC)
Message-ID: <1496143884.7897.5.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Russ Housley <housley@vigilsec.com>, curdle <curdle@ietf.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 30 May 2017 13:31:24 +0200
In-Reply-To: <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com>
References: <CABcZeBMRYwdQnxUuBrCEsM-BeTFfARg3ZFn=tWh+5FMdv2WGYw@mail.gmail.com> <4A227672-E806-4D6E-9E83-714675BF8FE1@vigilsec.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 30 May 2017 11:31:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/WGW2CJqUmtWPhQU6awazDU4nR-Y>
Subject: Re: [Curdle] AD Review: draft-ietf-curdle-cms-eddsa-signatures-05.txt
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 May 2017 11:31:28 -0000

On Mon, 2017-05-08 at 13:32 -0400, Russ Housley wrote:
> > TECHNICAL
> > S 3.1 and 3.2.
> > - Is there some reason to not prescribe exactly one form here?
> >   I.e., require id-sha512 (etc.) or require it not be there?
> > 
> > - Also, TLS has converged on talking about an "identity" hash
> >   for the PureEd forms. Was this discussed and rejected?
> 
> CMS supports signatures with and without signed attributes.  In most
> cases, signed attributes are present.  When signed attributes are
> present, the message-digest attribute MUST be one of the
> attributes.  Eric is suggesting that the “identity” hash could be
> used with Ed25519 and Ed448 when there are no attributes to
> hash.  Using ED25519 as an example, we get:
> 
>    IF (signed attributes are absent)
>    THEN
> 	signedData.digestAlgorithms includes id-hashIdentity
>         signedData.signerInfo.digestAlgorithm = id-hashIdentity
>         signedData.signerInfo.signature = Ed25519(content)
>    ELSE
> 	signedData.digestAlgorithms includes id-sha512
>         signedData.signerInfo.digestAlgorithm = id-sha512
> 	signedData.signerInfo.signedAttrs includes message-digest =
> SHA512(content)
>         signedData.signerInfo.signature =
> Ed25519(DER(signedData.signerInfo.signedAttrs))
> 
> Do others think the use of an algorithm identifier for the “identity”
> hash is better?  The current document include id-sha512 as a warning
> that Ed25519 uses that hash algorithm internally.

I miss the benefit of that change. Given that the flag 'signed
attributes are absent' is sufficient to determine the action to be
done, adding the identity hash identifier, can only create confusion.
The confusion can be because now we have multiple additional states
which provide no additional information.

E.g. the following are simply invalid:
'signed attributes are absent' and digestAlgorithm != id-hashIdentity
'signed attributes are present' and digestAlgorithm = id-hashIdentity

I prefer the original approach due to its simplicity.

regards,
Nikos