On Wed 16/Apr/2025 21:04:27 +0200 Richard Clayton wrote:
In message <bb288a78-c7b4-4455-b9d5-fbc2e73d8...@fahq2.com>, Larry M. Smith
<ietf....@fahq2.com> writes
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.
Indeed so, but reputation systems (because once again to state the
obvious, protocols cannot prevent bad email, but they can provide tools
for handling it efficiently) may take the view that a brand-new identity
that has acted as an intermediary to alter some email is not especially
trustworthy...
This position leads to ARC-style authentication, where one must trust that the
changes are benign.
DKIM2 has change tracking. Can't we tell whether a change is evil or not?
... mailing lists, alumni-forwarders and the like tend to handle lots of
email destined for your mailboxes, so they have a reputation that allows
you to view their mail more favourably than mail from an entity you know
nothing of. Viz: there is considerable scope for building reputation on
top of DKIM2, and one of our documents should explain this.
This strategy has proved ineffective. In fact, this mailing list, which is
trustworthy, has to bypass DMARC by munging From:. The reason why DKIM2
permits to skip From: munging should be made clear.
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.
DKIM2 does not "allow for hijacking" any more or less than is the case
for existing mail flows.
I'd hope for *less hijacking*.
The difference is that some legitimate mail flows (mailing lists for
example) are currently unable to document what changes they have made and
you have to take what they give you on trust. DKIM2 also requires trust,
but you get to verify as well.
The modification algebra can be designed so that it is straightforward for a
verifier to a) verify that changes can be undone, thus validating the original
signature, and b) that the changes are *not evil*.
Not evil could be summarized in a few rules, such as:
* Can modify the Subject: by adding a tag. It must be in square brackets and
shorter than 20 chars.
* Can add a footer. It must be text/plain and shorter than five lines of 80
chars. It must be separated from the body by a line of dashes.
It is still possible to be malicious under these conditions, but they are safe
enough to ensure that the message is not distorted from the intentions of the
author, identified by the original From: field. Most mailing lists operate
within these conditions.
To the opposite, a forwarder that changes, say, all the URLs —perhaps to
redirect through a security filter— needs to be absolutely trusted by the
receiver. Its changes don't satisfy the above rules.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
