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

Steffen Nurpmeso <steffen@sdaoden.eu> Thu, 16 May 2024 22:29 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 8B014C14F749; Thu, 16 May 2024 15:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 (2048-bit key) header.d=sdaoden.eu header.b="cHx96fgX"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="xTe0K2ZL"
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 7hjzJRGKl1y1; Thu, 16 May 2024 15:29:31 -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 2FD7AC15107F; Thu, 16 May 2024 15:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1715898564; x=1716565230; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding: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=Ec5m0DOS3HbMCObYEykmH4U2Y2SGGU1QzhQhjkK9Mv8=; b=cHx96fgXLVyN9FqTohZwjV8gjzwp8P/6mhQgid1Flz+cUtOUChPNrszsiAXOEESUoqzodNbK mUAuKchL2jOqFpnTO/cQRDiDpqlWj5Ti8B76Zc94T4I66tOmvwi0cBJEnKkQ68NtwaQ0v65UJ2 wG7kwfCSJAk2RvoDZg6vMMyjN7BxVx1X4pdicfsJN5AYeZ0EhYUkiZG6ZaRfpGYLZBhbvLkzoM IymqNwT3JWxj1oNgmAuF6ZA0jHiATvz6EBeNgrrKuEVGcKhCI0xCArl3JMEkPkV3BWAIcyIskf S0hnwapeEaFfQmCK5JFZEjQ+ss+bomQIradKyTVHjWVjAIiA==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1715898564; x=1716565230; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding: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=Ec5m0DOS3HbMCObYEykmH4U2Y2SGGU1QzhQhjkK9Mv8=; b=xTe0K2ZLE1wRAjG8Gto78F/xEBaNF2LU0vP2C4QA3qrqqdTYyzddskzsf+JF7XghydDLDeqz jyxZ9JNuaiLWBQ==
Date: Fri, 17 May 2024 00:29:22 +0200
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
Message-ID: <20240516222922.RlI6iUKT@steffen%sdaoden.eu>
In-Reply-To: <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.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> <ZkLM72PMJeWpet5C@chardros.imrryr.org> <20240515001817.saYJ-VOe@steffen%sdaoden.eu> <CDA9C77F-A74A-4303-AE9E-3E71661AA490@isdg.net> <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>
Mail-Followup-To: Viktor Dukhovni <ietf-dane@dukhovni.org>, ietf-dkim@ietf.org, dcrup@ietf.org, Hector Santos <hsantos@isdg.net>, 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.
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 24LK43VDMPKAWTBGZ3OAS3QNU2X4E7G6
X-Message-ID-Hash: 24LK43VDMPKAWTBGZ3OAS3QNU2X4E7G6
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: ietf-dkim@ietf.org, dcrup@ietf.org, Hector Santos <hsantos@isdg.net>, Steffen Nurpmeso <steffen@sdaoden.eu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Dcrup] Re: [Ietf-dkim] [standards] [Editorial Errata Reported] RFC8463 (7930)
List-Id: DKIM Crypto Update <dcrup.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/qfgIQaYH74gv2In3csYknrmDOE8>
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
 <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>:
 |> On 16 May 2024, at 10:02 AM, Hector Santos <hsantos=40isdg.net@dmarc.i\
 |> etf.org> wrote:
 |> I don’t wish to oversimplify here,  but I wonder if the confusion \
 |> is with the idea that in order to support RFC8463, a complaint implement\
 |> ation would have to sign two DKIM signatures for backward compatibility. \
 |>   One DKIM signature using SHA256 and a second signature using Ed25519. 
 |
 |No, you're conflating completely different constructs, because SHA256 \
 |is NOT a signature, it is a message digest.

And i think he mentions an interesting point, given that people on
the dkim list said that they use the Ed keys since 2019, and
"without problems", which is i think the correct citation.
That is five years and still you need to DKIM-double-sign your
emails, because major email player with which you have to be
compatible to simply do not follow this spec.

Truy, i have heard that "just use the rsa-sha256 and be good"
quite some times in the past months where i was so deeply involved
in this topic.
It surely results in smaller messages and less resource
consumption, .. especially if there is no light on the horizon
that the situation will change for a better.

  ...
[resorting for effect]

 |Nevertheless, the specification is clear enough, and a slightly different \
 |code path for the new signature scheme is fine.

No.  That is not necessarily a necessary evil.
We have that problem with some other email standards, where each
and every one invents its own [un]"structured header" format, just
slightly different, but which needs to be addresses specifically.
You can see how serious the people treat the standards if you look
into the code, you see the blurred corners and the generalized
parsers.
This can be said about the plain DKIM RFC 6376, too, as it uses
VCHAR; i presumed it did so for simplicity as that means "no
comments", no quoted-pairs, no quoted-strings etc, and so it is.

On the other hand noone would be hurt if the entire IETF email
standards would focus on RFC 5322 and RFC 2045 with their near 50
years of defined content, and clear syntax elements like atext and
the mentioned, and rules like key=value or key="value" etc,
instead of inventing things which look easy but are entirely
different like key(FWS)=(FWS)value1(FWS that counts)value2, and
similar monsters.  (Again: artificially complicated.)
I do not know why this can be seen all over the place, but it is
there.  Sure, yes, you can, .. but i at least would not.

(In the meantime if have changed the post-release code of the
little thing i have written so it is generalized via "extern_md"
and "sign_md" booleans, but i would be eager to drop the former
again.)

  ...
 |Nothing of the sort, the computational costs are trivial, there is \

Well if you have to place two further ARC signatures then maybe.
The following Ed25519 computations are less than trivial for sure.
On the OpenPGP list i think it was where they had a deeper look at
"whether it should be SHA-256 or SHA-512" (for whatever purpose),
and it depends a lot on crypto extensions, and 32-bit or 64-bit
CPUs etc.

And i think the IETF email group should possibly step down from
usurping the small CPUs of the little servers of poor students,
there is also the TLS and HTTP community which longs for taking
its toll.

 |some additional code required for Ed25519 support, because
 |instead of using a single Digest+Sign primitive in, e.g., OpenSSL, \
 |the caller needs to first compute a message digest, and
 |then pass it to Ed25519 for signing.  This is OK.  One might argue \
 |that this should have been either pure Ed25519 over the raw
 |data (contrary to the text of the base DKIM RFC, but aligned with how \
 |it ultimately handles RSA), or, else Ed25519ph which is
 |explicitly design for hashed input (but APIs for which are not yet \
 |mature in OpenSSL).

Of course i give in because "ultimately" the RSA key signs the
digest of the headers, just like the digest of the headers is
passed into the Ed25519 algorithm.

But again i will point to the possible future in fall this year,
when i would try to write a draft that changes this, because i see
no reason why we must be totally fixated on it, *if* the sig-alg
contains (even extensive) digesting itself, we could very well
"simply pass the headers", like the developer of the four letter
MTA wrote, and the result will not be less secure or or lesser
quality, but possibly even better.

 --End of <DC85F374-B15C-442C-9F5E-15B4EEA3022D@dukhovni.org>

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