[Ietf-dkim] Re: Malicious Modification was: My concerns

["Larry M. Smith" <[e-mail]>]

On 4/16/2025, Richard Clayton wrote:
> In message <[e-mail]>, Larry M.
> Smith <[e-mail]> writes
> 
>> I appears to me that most of what has been discussed with regards to DKIM replay
>> is an attempt to abuse systems that use DKIM for positive reputation.  However,
>> such replay does require that the messages pass DKIM signing.
> 
>> Hypothetically, if I were evil[1], I would sign up for a target domain's
>> newsletter and mutate messages with this DKIM2, and resend them.
> 
> yes, although if you don't generate multiple copies this is not "DKIM
> replay"
> 

OK, I'll call it malicious modification.

>> While forensic
>> investigation would reveal the subterfuge, what gets displayed via the user's
>> MUA is verifiable via DKIM2 and presumably trusted.  I expect overuse of
>> m=nomodify and this Could make the motivation for DKIM2 somewhat moot.
> 
> Note that honouring "nomodify" is a matter of local policy... but if you
> then send the email onwards (out of your local policy space) having
> modified it then the system you send it to SHOULD (again they may have
> local policy) reject it.
> 
>> An example;
> 
>> 1) I sign up for email from [e-mail].
>> 2) When I receive new email message I mutate them hijacking the donation links,
>> maybe modify the message is subtle ways, DKIM2 sign the emails appropriately,
>> and resend them to my list of victims.
>> 3) Receiving systems validate the DKIM2 and accept the messages.
> 
> Yes, this is understood ... an intermediary can change an email to make
> it evil, and then DKIM2 sign it -- having recorded all the modifications
> they have made.
> 
> However, their signature acknowledges that they made the changes and so
> it is possible to identify which intermediary (of which there may be
> several) made the change -- and an appropriate reputation can be
> assigned to that intermediary .... and not to the original sender.
> 
> There's no way of determining that a change is or is not evil within the
> DKIM2 protocol, nor can there be. However, you do know where the
> evilness came from.


Experience has shown that threat actors are willing to go to great 
lengths to have access to a large pool of resources to abuse and then 
rapidly discard.[1]  Knowing what object to apply poor reputation to for 
the last event often doesn't help for future ones.  Additionally, I do 
not expect that end users to be able to identify the problems 
themselves, not trust that they would be able to identify it before harm 
has been done.

One of the goals of DMARC was "Anti-Phishing", but if DKIM2 allows for 
hijacking of messages in flight, and a reuse of authenticated emails, 
then I would suggest that there exists significant motivation for 
miscreants to abuse this feature.


[1] Statement is for the record. I am aware that we understand this.

-- 
SgtChains