For your possible interest.
--- Forwarded from Steffen Nurpmeso <stef...@sdaoden.eu> ---
...
|> v0.6.1, 2024-05-12:
|> - Adds the algorithm big_ed-sha256 which effectively is RFC 8463
|> (aka ed25519-sha256), but performs three digest operations where
|> only two are needed.
|> We keep our two-digest ed25519-sha256 "as-is".
|> (If the big players do not start to support RFC 8463 by fall 2024,
|> i will propose a draft xed25519-sha256 which changes the algorithm
|> accordingly.)
|>
|> Ie, the ed25519 keys etc can remain the same and everything, but
...
|This is not a productive direction. Please implement only algorithms
|that are specified in a published standards track RFC. Nobody benefits
|from ad-hoc non-interperable DKIM signature schemes that just create
|confusion.
Hm, from my very short look it seemed rspamd has a lot of such
things, if i recall correctly. At least code-wise.
|Your "big_ed-sha256" is just a correct implementation of "ed25519-sha256",
|and should be the only choice offered.
In my humble opinion though RFC 8463 is a mess. Just like most of
the IETF email additions since 2010. "Throw it all into the
trashbin".
Maybe you can even get Argon2id-sha256 from the rspamd author if
you ask for it, shall it not already be there. (You have to live
with ascii_isspace() still.) No. You do not need three digests.
If you have a modern algorithm that digests itself, why would you
digest in addition? I mean you can, of course, but why would you
want to. The DKIM RFC speaks upon digesting the message, the
algorithm does it. Where is the problem?
No, the problem is what i quoted on the IETF list, you can see
/* For GCrypt, and for EC, we pass the hash-of-headers to the signing
routine. For anything else we just pass the headers. */
in one MTA, or
static int sephash = 0;
...
#ifdef HAVE_ED25519
} else if (strncmp(optarg, "ed25519-", 8) == 0) {
hashalg = optarg + 8;
cryptalg = "ed25519";
keyid = EVP_PKEY_ED25519;
sephash = 1;
#endif
...[and you do not want to see the rest]
in another filter, and more, and all that. RFC 8463 introduces
spaghetti, all over the place. That is plain fact. For
absolutely no reason even. It gives a shit about code quality.
It is a brain fucker. It does exactly what the OpenPGP WG turmoil
is all about, and what caused RePGP -- like many other IETF email
additions of the last decade. And have a go, look at the code of
some of the speaking participants of the IETF email lists. At the
very least, you will find those preprocessor djungles that the
real good ones from Bell Labs etc tried to get rid off. No!
Ie on the dash shell list hosted by the linux kernel people you
get three authentication-results headers for each of whatever
(SPF, DKIM, 'forgotten the rest). No, fold it into your DKIM
flags, where is the difference in between for example d/D (DKIM
fail/pass), s/S (SPF), ..etc.. and that. Maybe introduce
a DKIM-Store: that should not be sent over "egress" / always be
removed on "ingress" for the purpose of handing info from the
ingress verifiers to the egress signers, with totally free content
(but "should be crypto-verifiable"), etc. To give it a name, to
be able to filter it, whatever. For automated processing, that is
more than sufficient. For example. No ARC header at all.
I have one!
Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key)
header.d=******** header.i=********* header.b="********"
X-Original-To:..
Received:..
Authentication-Results: smtp.subspace.kernel.org; arc=none
smtp.client-ip=***********
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none
dis=none) header.from=********
Authentication-Results: smtp.subspace.kernel.org; spf=pass
smtp.mailfrom=********
Oh my god. I will fight that mess to the second last breath.
I am not keen about log- or statistical masturbation orgies. But
you could still get it nonetheless i think, if you just believe
the Received: lines before the DKIM signature, .. no?
On the other hand one of this list's members showed me something
juristic on email forwarders, it seems in Germany the situation
for universities and these kind of corpus regarding offering
stable email addresses that forward to other emails is
juristically determined to be illegal. That was from 2015. It
does not take into account the original email hop-to-hop
infrastructure, it does not take into account that SMTP is by
itself not encrypted (due to bad IETF decisions, again, and again,
in my opinion), it does not simply say, "hey, simply S/MIME
encapsulate before the forward by some easily produced per-user
self-signed-certificate (showing OpenSSL command, hihihi), and
ignore all the remaining ten thousand pages".
Anyhow. How wonderful it is, for Germany it does not matter that
SPF breaks the entire email alias-forwarding infrastructure,
because that alias-forwarding is almost-illegal by itself, anyway!
No!
--End of <zkbm5qgk-_iv4...@chardros.imrryr.org>
-- End forward <20240513184918.1yBocAlB@steffen%sdaoden.eu>
--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)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
