[Dcrup] Re: [standards] [Editorial Errata Reported] RFC8463 (7930)

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 13 May 2024 12:26 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dcrup@ietfa.amsl.com
Delivered-To: dcrup@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D431CC1522B9 for <dcrup@ietfa.amsl.com>; Mon, 13 May 2024 05:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouxAVEJPSKWL for <dcrup@ietfa.amsl.com>; Mon, 13 May 2024 05:26:21 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1009FC15198F for <dcrup@ietf.org>; Mon, 13 May 2024 05:26:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1715603208; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to : from; bh=chVhiK9gx+Szbpc7hqr7DWkGBET6dF+EJp8g/PcR9n0=; b=bnV5y4/X4PJ2E9zipvKSn4h3RDuj4nQCa/qKQ+aRjHDlwHKQupepA3avRHHN+AIaOYSYA GyZtIhrv1M8x8z6HJw+0wgN2VU+91C0sUDkk/aFlU3wEV13t+aktQQ9LkWkOLRAHGi+7S6G Za/MlM9fdjuHjjnqokf/zvbDNH59aPk=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 98DB88DF27A; Mon, 13 May 2024 08:26:48 -0400 (EDT)
Date: Mon, 13 May 2024 08:26:48 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dcrup@ietf.org
Message-ID: <ZkIHCNGIFC3jXdDf@chardros.imrryr.org>
References: <20240511201039.lf46znlR@steffen%sdaoden.eu> <20240511201754.H_LMdv5z@steffen%sdaoden.eu> <20240511223227.IW5-DSdi@steffen%sdaoden.eu> <5a7773ad-e54d-a88c-99f6-064a3d4c4e90@taugh.com> <d2780795-8772-4578-96dc-0d351451e475@tana.it>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <d2780795-8772-4578-96dc-0d351451e475@tana.it>
Message-ID-Hash: UN7ZHLG3HBWZYQBYROYBQ2H6YI3T77K6
X-Message-ID-Hash: UN7ZHLG3HBWZYQBYROYBQ2H6YI3T77K6
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dcrup.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Dcrup] Re: [standards] [Editorial Errata Reported] RFC8463 (7930)
List-Id: DKIM Crypto Update <dcrup.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/Rt-OBxAZjd6kGFAnUQnGBYG35BE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dcrup>
List-Help: <mailto:dcrup-request@ietf.org?subject=help>
List-Owner: <mailto:dcrup-owner@ietf.org>
List-Post: <mailto:dcrup@ietf.org>
List-Subscribe: <mailto:dcrup-join@ietf.org>
List-Unsubscribe: <mailto:dcrup-leave@ietf.org>

On Mon, May 13, 2024 at 01:15:59PM +0200, Alessandro Vesely wrote:

> I'm not much into crypto, so I don't understand why Section 4 of RFC
> 8032 says HashEdDSA would be less collision resistant (after SHA256)
> than PureEdDSA. However, I understand single-pass interface for
> creating signatures.

The construction of pure EdDSA makes it difficult to exploit collisions
in the underlying hash function, because the message is prefixed with
an octet-string that an attacker cannot predict, and depends on both
the message and the signer's secret key (a deterministic variant of
Schnorr signatures).

This is not the case with the Hash (ph) variants, which digest the
input before signing.

> It seems to me we're using HashEdDSA, aren't we?

No, because of "domain separation", HashDSA(m) != PureDSA(hash(m)), even
if the chosen hash is SHA512, but in any case HashDSA always uses
SHA512, whereas with DKIM, SHA256 is the more likely choice.

See https://datatracker.ietf.org/doc/html/rfc8032#section-2

   dom2(x, y)     The blank octet string when signing or verifying
                  Ed25519.  Otherwise, the octet string: "SigEd25519 no
                  Ed25519 collisions" || octet(x) || octet(OLEN(y)) ||
                  y, where x is in range 0-255 and y is an octet string
                  of at most 255 octets.  "SigEd25519 no Ed25519
                  collisions" is in ASCII (32 octets).

and the use of dom2() in https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.6

-- 
    Viktor.