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

Steffen Nurpmeso <steffen@sdaoden.eu> Sat, 11 May 2024 21:05 UTC

Return-Path: <steffen@sdaoden.eu>
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 949A2C14F602 for <dcrup@ietfa.amsl.com>; Sat, 11 May 2024 14:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sdaoden.eu header.b="NMQZkxwm"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="DJrqKgc0"
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 KCHSbRF7bAe0 for <dcrup@ietfa.amsl.com>; Sat, 11 May 2024 14:05:05 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 99744C14F5F6 for <dcrup@ietf.org>; Sat, 11 May 2024 14:05:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1715461503; x=1716128169; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-date:resent-from:resent-to: resent-cc:in-reply-to:references:mime-version:content-type: content-transfer-encoding:message-id:mail-followup-to:openpgp: blahblahblah; bh=xh6vF3ZcSpccXbgmWZ2ztIALN/kFe8YcJ6+H5xNnUTM=; b=NMQZkxwmCpQteW1N0J4oa8RcCl/x/8yAaE7x9AR3xeNGNSQ3aIROgs3MRgkNON4GC+6p+CZS Tv72zK2IeLbpDBPOVVpWC0fwLMyOFouHe/z8AblGlR28S0moqE5Af4kvTqHB6ccvcu1cYDNjX5 o1Bc4SiYIlIMzOkzk8xDA3DsH6w3UQZrcwWBm3oZohOQSJd2N5LvpO0Y8qqM8aj6MWdinnBx3s UUhPIc9LmWj/4kQv6Faw3i/zXNzfJUb0x4TFWSdydbPYl6jvFo3r+q7Qjt7tPBOZQWA/b+uYKi lwdNX2lkH/z5JOwm1+4aKFw0w3EpJnL+Tz7yi/Zbi5cCbM8A==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1715461503; x=1716128169; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: author:from:subject:date:to:cc:resent-date:resent-from:resent-to: resent-cc:in-reply-to:references:mime-version:content-type: content-transfer-encoding:message-id:mail-followup-to:openpgp: blahblahblah; bh=xh6vF3ZcSpccXbgmWZ2ztIALN/kFe8YcJ6+H5xNnUTM=; b=DJrqKgc0VonbpSCiy4nLkLiFdt4ExvjOxulnFm+9d8fIXG4dMR3gESneFSy7k3jS0xyAkZQ4 Bpyj5kTvfVmgBQ==
Date: Sat, 11 May 2024 23:05:01 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <20240511210501.xC8hJXru@steffen%sdaoden.eu>
In-Reply-To: <Zj79NxPmqtBwp-6r@chardros.imrryr.org>
References: <20240509203958.F19D933CD1@rfcpa.amsl.com> <55570A01-CF1B-4D47-B74A-D3BDBDD2E65E@amsl.com> <CAN8C-_KycC_9g5Tviawp8P4YDqzHAptzTiw=i10QhL9JtWouug@mail.gmail.com> <CAL0qLwZ0KYzbMRVfizwc4uKZEVN19C4UoWj8=pK5viT2i4PW+w@mail.gmail.com> <20240510223917.mvkXC0XH@steffen%sdaoden.eu> <Zj79NxPmqtBwp-6r@chardros.imrryr.org>
Mail-Followup-To: Viktor Dukhovni <ietf-dane@dukhovni.org>, dcrup@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
User-Agent: s-nail v14.9.24-621-g0d1e55f367
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Message-ID-Hash: ZH7RLUZ5O42EBCFJEAWOGKRLJSEP6SBN
X-Message-ID-Hash: ZH7RLUZ5O42EBCFJEAWOGKRLJSEP6SBN
X-MailFrom: steffen@sdaoden.eu
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: dcrup@ietf.org, Steffen Nurpmeso <steffen@sdaoden.eu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Dcrup] Re: [Editorial Errata Reported] RFC8463 (7930)
List-Id: DKIM Crypto Update <dcrup.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/ZvWQPrvlj-IDbmgMSMdTokdu_8g>
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>

Viktor Dukhovni wrote in
 <Zj79NxPmqtBwp-6r@chardros.imrryr.org>:
 |On Sat, May 11, 2024 at 12:39:17AM +0200, Steffen Nurpmeso wrote:
 |> Here is key and data
 |> 
 |> cat <<'_EOT' | python3 rfc8032-ed25519.py
 |> nWGxne/9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A=
 |> ZnJvbTpKb2UgU2l4UGFjayA8am9lQGZvb3RiYWxsLmV4YW1wbGUuY29tPg0KdG86U3V6aWUg\
 |> USA8c3V6aWVAc2hvcHBpbmcuZXhhbXBsZS5uZXQ+DQpzdWJqZWN0OklzIGRpbm5lciByZWFk\
 |> eT8NCmRhdGU6RnJpLCAxMSBKdWwgMjAwMyAyMTowMDozNyAtMDcwMCAoUERUKQ0KbWVzc2Fn\
 |> ZS1pZDo8MjAwMzA3MTIwNDAwMzcuNDYzNDEuNUY4SkBmb290YmFsbC5leGFtcGxlLmNvbT4N\
 |> CmRraW0tc2lnbmF0dXJlOnY9MTsgYT1lZDI1NTE5LXNoYTI1NjsgYz1yZWxheGVkL3JlbGF4\
 |> ZWQ7IGQ9Zm9vdGJhbGwuZXhhbXBsZS5jb207IGk9QGZvb3RiYWxsLmV4YW1wbGUuY29tOyBx\
 |> PWRucy90eHQ7IHM9YnJpc2JhbmU7IHQ9MTUyODYzNzkwOTsgaD1mcm9tIDogdG8gOiBzdWJq\
 |> ZWN0IDogZGF0ZSA6IG1lc3NhZ2UtaWQgOiBmcm9tIDogc3ViamVjdCA6IGRhdGU7IGJoPTJq\
 |> VVNPSDlOaHRWR0NRV05yOUJySUFQcmVLUWpPNlNuN1hJa2ZKVk96djg9OyBiPQ==
 |> _EOT
 |
 |Perhaps you failed to hash the data with SHA256 prior to passing it to
 |PureEdDSA (Ed25519) for signing.  The signature input should be the raw
 |binary data hash, whose hex dump is below:
 |
 |    $ printf "%s\n" 'ZnJvbTpKb2UgU2l4UGFjayA8am9lQGZvb3RiYWxsLmV4YW1wbGUuY2\
 |    9tPg0KdG86U3V6aWUgUSA8c3V6aWVAc2hvcHBpbmcuZXhhbXBsZS5uZXQ+DQpzdWJqZWN0O\
 |    klzIGRpbm5lciByZWFkeT8NCmRhdGU6RnJpLCAxMSBKdWwgMjAwMyAyMTowMDozNyAtMDcw\
 |    MCAoUERUKQ0KbWVzc2FnZS1pZDo8MjAwMzA3MTIwNDAwMzcuNDYzNDEuNUY4SkBmb290YmF\
 |    sbC5leGFtcGxlLmNvbT4NCmRraW0tc2lnbmF0dXJlOnY9MTsgYT1lZDI1NTE5LXNoYTI1Nj\
 |    sgYz1yZWxheGVkL3JlbGF4ZWQ7IGQ9Zm9vdGJhbGwuZXhhbXBsZS5jb207IGk9QGZvb3RiY\
 |    WxsLmV4YW1wbGUuY29tOyBxPWRucy90eHQ7IHM9YnJpc2JhbmU7IHQ9MTUyODYzNzkwOTsg\
 |    aD1mcm9tIDogdG8gOiBzdWJqZWN0IDogZGF0ZSA6IG1lc3NhZ2UtaWQgOiBmcm9tIDogc3V\
 |    iamVjdCA6IGRhdGU7IGJoPTJqVVNPSDlOaHRWR0NRV05yOUJySUFQcmVLUWpPNlNuN1hJa2\
 |    ZKVk96djg9OyBiPQ==' |
 |        openssl base64 -A -d |
 |        openssl dgst -sha256 -binary |
 |        xxd -p -c64
 |    48ce9a2c710ece1710ff156996b836a7f45470e43efe5643074d6e1690ed62e7
 |
 |When I fail to hash the data, the signature I obtain is:
 |
 |    QGeDV9CRdXSybek0z54GoycZ4/kl1PsNnGoOsCZ0ZOOwiGYFE8Ft0SZpy1XLW/fw
 |    lwNFC1k6VaxsnQAH8+9cAA==
 |
 |which mathes your proposed erratum.  Mystery solved.

No, you do not do that with DKIM?  You prepare the canonicalized
header including the almost-complete dkim-signature one, and then
DigestSign() it.  SHA-256 does have no meaning for the signature
for the ED25519 case, no?  You would digest it multiple times for
no reasons, first with SHA-256, then again with SHA-512?
Why would you do something like this?
RFC 8463 also says

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

Where does this tell that you, different to RSA, have to create
a SHA-256 digest on the headers and then sign *that*, instead of
using SHA-256 for the only the body and then the ED25519-builtin
digest for the signature?  Message hash is body.

Why would you sign the header twice?  This is not a vivid part of
RFC 8463.
Maybe this is why the big players do not implement it, what
a tremendous effort for no reasons, shall this really be meant?

*Double-digesting* the header?
That is not part of RFC 8463.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)