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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 14 May 2024 02:30 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 AA50CC14F5FA for <dcrup@ietfa.amsl.com>; Mon, 13 May 2024 19:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 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_DNSWL_MED=-2.3, 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 WH5qLJfbeviH for <dcrup@ietfa.amsl.com>; Mon, 13 May 2024 19:30:45 -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 23D4CC2055E1 for <dcrup@ietf.org>; Mon, 13 May 2024 19:30:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1715653871; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to : content-transfer-encoding : from; bh=EnTWElbK6xqFfCyMMPdxR8eBZf2cKZbopBbaNS+02L4=; b=y2StaI+9utkM2APx8MmkyrtaYx+/ogIf3d9/vDSMXDYTuET8a/vST1xcUJtX+z2d5wHQm E4wj80rCN5vovwSfOQc78TyDH/WlQiyyCPNZHTOX3/BcXEzHjYpQD/ffnlR+ocrq6leKJXA HWh14McAMW+fU1eyd4LbfMmEeqGAcM0=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id B50218DF27A; Mon, 13 May 2024 22:31:11 -0400 (EDT)
Date: Mon, 13 May 2024 22:31:11 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: Steffen Nurpmeso <steffen@sdaoden.eu>
Message-ID: <ZkLM72PMJeWpet5C@chardros.imrryr.org>
References: <ZkAOictS1ygyIBZe@chardros.imrryr.org> <20240512005258.N-lL8YIA@steffen%sdaoden.eu> <CAL0qLwYPtxxDhYEjH0D5YkcXBf6Qy6Xcux7PdvFtwhJzpaUxyg@mail.gmail.com> <ACD165BA-9195-480E-9FA0-44A44097E6A8@isdg.net> <20240513203259.hFdFtvyd@steffen%sdaoden.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <20240513203259.hFdFtvyd@steffen%sdaoden.eu>
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: R5Z52PZCMUEXBE6INNNJID7CHGMPBEZ3
X-Message-ID-Hash: R5Z52PZCMUEXBE6INNNJID7CHGMPBEZ3
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
CC: Hector Santos <hsantos@isdg.net>, "Murray S. Kucherawy" <superuser@gmail.com>, John R Levine <johnl@taugh.com>, dcrup@ietf.org
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/VEOUSId1b0LD1arYxD-yQepQ1Xo>
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 10:32:59PM +0200, Steffen Nurpmeso wrote:

> "It is ok", but i want to say again (there were some private
> emails and i have forgotten where i said what, i am talking too
> much, anyway) that RFC 8463 uses *three* digests, whereas RFC 6376
> wants *two*.

The main disconnect here is that you're hyper-focused on implementation
details, while the IETF deals with *specifications*.

The specification is clear and concise:

   The Ed25519-SHA256 signing algorithm computes a message hash as
   defined in Section 3 of [RFC6376] using SHA-256 [FIPS-180-4-2015] as
   the hash-alg.  It signs the hash with the PureEdDSA variant Ed25519,
   as defined in RFC 8032, Section 5.1 [RFC8032].  Example keys and
   signatures in Appendix A are based on the test vectors in RFC 8032,
   Section 7.1 [RFC8032].

Yes, this results in a different code path for RSA vs. EdDSA, due to API
differences in, where RSA signing typically includes the digest
operation, while pure EdDSA over a pre-computed message digest does not.
This may be a modest inconvenience to an implementor, but so be it.

If there is a issue of clarity it is actually in RFC6376, where the
signature is described as a private-key (decrypt) operation over a
pre-computed signature, but in fact for RSA what is used is an
RSAwith<SomeHash> hash and sign operation.

As explained upthread, the difference is the presence of the hash OID
in the signed payload, which consists of:

    - PKCS#1 padding
    - Hash algorithm OID
    - NULL parameters
    - digest octet string

Where a literal reading of RFC6376 might have expected:

    - PKCS#1 padding
    - digest octet string

Because the algorithm signalling in the DNS TXT record, and, with the
former, a naïve implementation might not check that the hash used in the
signature is actually the one promised by the DKIM DNS record.  One,
might, e.g. accept an RSAwithSHA1 signature of the same headers and
DKIM-Signature template (with "b=" empty).

There really ought to have been more text in RFC6376 about what's
actually expected, than just:

      NOTE: Many digital signature APIs provide both hashing and
      application of the RSA private key using a single "sign()"
      primitive.  When using such an API, the last two steps in the
      algorithm would probably be combined into a single call that would
      perform both the "a-hash-alg" and the "sig-alg".

Because that's not actually accurate, due to the inclusion of the digest
OID in the signature payload in the "single" primitive.

Regardless, the specifications are they are, and you just need to read
them with care, test your understanding, and interoperate.

-- 
    Viktor.