Index | Thread | Search

From:
Kirill A. Korinsky <kirill@korins.ky>
Subject:
Re: patch dkimproxy: use rsa-sha256 in sample signing config
To:
Matthieu Herrb <matthieu@openbsd.org>, ports@openbsd.org
Date:
Sat, 11 May 2024 22:34:09 +0100

Download raw body.

Thread
Hello Steffen,

On Sat, 11 May 2024 21:27:09 +0100,
Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> 
> Kirill A. Korinsky wrote in
>  <2fdd33f2325e6817@mx2.catap.net>:
> 
>  |>|I imply that using ed25519 usually leads to malformed signature, and some
>  |>|big hosting providers treat double signature as bad signature if some of
>  |>|them are not RSA-SHA256. A notable example is icloud.com, which delivers \
>  |>|\
>  |>|all
>  |>|emails with double signatures to the junk folder. At least that's \
>  |>|what they
>  |>|did the last time I checked in December'23.
>  |> 
>  |> Then these are not standard compliant.  The DKIM standard 6376
>  |> *explicitly* supports multiple signatures.
>  |
>  |Yes, RFC may imply that but OpenDKMI was released quite a while ago and the
>  |last stable release seems that doesn't handle well this case.
> 
> OpenDKIM cannot.  I looked at its code in about January and there
> is no notion of it.  zdkimfilter as of courier bases upon it, and
> supports it.  (Very preprocessor sprinkled crypto code in between
> several libraries that uses, though, and the OpenSSL 3.0 thing
> even fiddles with openssl parameters which i have *not*
> understood from my short glance..)
>

And here the issue and my point: until OpenDKIM is supporting anything else
than RSA may lead to delivery emails into Junk.

>  |>|So I suggest to put in README and config exmaple that using anything \
>  |>|other
>  |>|than RSA-SHA256 may lead to delivery email to thte junk. Unfortunately, \
>  |>|this
>  |>|includes duble signatures as well.
>  |> 
>  |> On the IETF DKIM list there are people which told me they use such
>  |> a configuration since 2019 without any issues, and i myself use it
>  |> for two months, too, and did not have problems; that cloud thing
>  |> i never saw, though.
>  |
>  |Here I've sent to some tool which is used to check email configuration a
>  |test email with 2 singatures [1] and with 1 [2], the same behaviour \
>  |I saw in
>  |icloud.com.
>  |
>  |I've tracked that issue last Decemner and it had status that second
>  |signature or non RSA-SHA256 leads to not valid signature and delivery email
>  |into junk folder. Probably.
>  |
>  |Footnotes:
>  |[1]  https://mxtoolbox.com/deliverability/8d9efa25-f421-4582-a0fb-652f01\
>  |46dfce
>  |
>  |[2]  https://mxtoolbox.com/deliverability/42b985b2-c8a1-44b2-a9ed-4bf86a\
>  |604e54
> 
> It does not matter that the Ed25519 code is not understood, the
> RFC 6376 is a very, very thought through standard and has all that
> foreseen indeed.  From a short look at the first it seems your
> real problem why this fails is that *all* signatures are rejected,
> and the RSA is because it uses SHA-1, however, SHA-1 was
> explicitly forbidden by RFC 8301 as of January 2018:
> 
>    Due to the recognized weakness of the SHA-1 hash algorithm (see
>    [RFC6194]) and the wide availability of the SHA-256 hash algorithm
>    (it has been a required part of DKIM [RFC6376] since it was
>    originally standardized in 2007), the SHA-1 hash algorithm MUST NOT
>    be used.  This is being done now to allow the operational community
>    time to fully shift to SHA-256 in advance of any SHA-1-related
>    crisis.
> 
> I could very much imagine that if you change to RSA-SHA256 then
> your problem will vanish.
>

Nope, it doesn't

See mxtoolbox [1] for the case of RSA-SHA256 and icloud says, let me quote:

  Authentication-Results: dkim-verifier.icloud.com; dkim=permerror (0-bit key) header.d=korins.ky header.i=@korins.ky header.b=VNwI9oir
  Authentication-Results: dkim-verifier.icloud.com; dkim=pass (2048-bit key) header.d=korins.ky header.i=@korins.ky header.b=qwDQ6QCD

The issue that one of signatures is invalid, and icloud moves mail to the
Junk folder.

As soon as I use only RSA signatures, emails are delivered to inbox.

Footnotes:
[1]  https://mxtoolbox.com/deliverability/86e2b0ff-ba95-47f3-b71e-4ead73653a73

-- 
wbr, Kirill