Murray S. Kucherawy wrote in
<cal0qlwyjf2wyz4jbdtfptkoghpaf7gpykkcnnvhoqekv_sv...@mail.gmail.com>:
|On Wed, Aug 9, 2023 at 9:07 AM Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
...
|There aren't per-user DKIM keys. I mean, there could be, but that's not
|how it's designed or maintained.
|
|So the best you could do is per-recipient-domain signatures, but I don't
|think that solves much: If I launch a replay attack from gmail.com at
|yahoo.com, or even simply back at gmail.com, I can still hit a large number
|of recipients without needing an array of signatures or revealing that
|replay is occurring.
Ok. Assumed the normal per-message DKIM signature gets a new flag
that signals that an additional per-recipient-domain DKIM
signature is present (and has already been seen once the normal
DKIM signature is when parsing the message).
A recipient('s MTA DKIM verifier) can link via _domainkey that
both, the email still validates, and that it (as "domain MTA") was
really meant as a recipient (and of this "absolutely very message"
if the per-recipient-domain signature "somehow verifiable"
includes the normal message's DKIM signature, maybe as
a cryptographically secure checksum, or the like).
This is new.
Then the attack could only be that the message sender's domain
continues to send the same message to more and more recipients on
"the recipient( bundle)s" domain.
As the originating MTA is it who creates the message's DKIM
signature as such, there is nothing which can prevent this.
Except when Bcc: headers become visible message parts, so that any
"extended" recipient "sees himself in the Bcc:" header, and can
ask the Sender:/From: whether that was really intented.
(SMTP logs should be usable to reveal criminal intents as of today
i would say --- no?)
Or if S/MIME or OpenPGP become standard, and the sender as such
creates a verifieable message structure, which will reveal that
his/her (DKIM signature creating) MTA forks the message to create
attacks. (If Bcc: becomes vivid visual message members. Or if
OpenPGP and or S/MIME add the possibility to include an encrypted
such header, so that, if the police comes, the original message
sender can decrypt that header and reveal _all_ recipients he or
she had in mind when actually sending the message. .. Unless some
evil MUA programmer silently forks even that!! But i think now
that leads too far.)
|Isn't this discussion about Bcc: off-topic and solely RFC 5322?
|> I have never seen a MUA implementation which does anything else
|> but "throwing recipients into" To:/Cc:/Bcc:. And then there is
|> "undisclosed-recipients", where anything is consciously not part
|> of IMF/5322, but only in SMTP/5321, but still per-recipient DKIM
|> should work out, then.
|
|"Bcc" came up in the context of supporting DARA as a solution to the replay
|problem, I believe.
|
|> It seems to me that adding a per-recipient DKIM "sub-signature"
|> can be accomplished very cheaply, and "scales to
|> super-parallelism".
|
|If by that you mean a distinct signing key per user, I don't think this
|scales. That's not because DKIM can't handle it, but because I don't think
|large operators like Gmail or Yahoo want to maintain millions of public
|keys in their DNS.
|
|-MSK, participating
--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
https://www.ietf.org/mailman/listinfo/ietf-dkim
