On Fri, Apr 18, 2025, 2:10 p.m. Alessandro Vesely <ves...@tana.it> wrote:
> 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. Footers produced by some mailing lists contain links, such as to unsubscribe or to view the thread on a web interface. Classifying these as malicious feels incorrect to me. I could support the idea that types of modifications should be limited to logical prepending and appending with no support for deletions. Doing either operation on a multipart message and/or involving base64 encoding ends up being complicated though, and that's one reason for why the algebra has support for content deletion. I generally don't see evaluation of the content as a problem DKIM2 needs to solve. The modification algebra allows for attribution of content to a signing domain. Local policy could always decide that certain classes of changes aren't deemed acceptable, and having an identity to attach to the content/changes could be useful for making those policy decisions. Best > Ale > -- > > > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
