On Sun, Nov 17, 2024 at 2:20 PM Bron Gondwana <brong= [email protected]> wrote:
> I don't believe it's that complex, and I do believe it's worth the effort > in exchange for being able to tell with certainty which entity (by > signature; which DNS domain) is responsible for creating each part of a > message. You can then attribute parts of the text to different entities - > the original author, or the mailing list signature. > > And if a message is bad then it's possible to derive where the badness was > introduced - something not possible with DKIM or ARC if a message has been > modified. I have a draft for a method at: > > https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/ > I'm very much in agreement with the need to attribute who contributed which content to the message. I think this is the key difference from the RFC6376 DKIM l= body length tag (section 3.5) that tried to tolerate mailing footer modification also, but left unknown who added a potentially malicious footer, which can be exploited today. Agreed there is DKIM RFC security section 8.2 that warns about using DKIM body length but unfortunately a very small but important part of the sending population uses it today despite those warnings and risk. My guess is that they have use cases that compel them to use DKIM body length despite its unsoundness. You can see the "algebra" draft provides tools to bind a change to a particular signer. If malicious content is found, it can be associated with the contributor and not someone else even though other parties may have forwarded the message and contributed other content to the message. There are some of the details of the content and header diff that could be tweaked but that's for later. > It can be used to describe all "add text" cases quite nicely, as well as > wrapped structures where an existing message gets moved into a > multipart/mixed with more content at the end. There's still some testing to > be done for the most complex cases - but this doesn't have to be a two-way > algorithm, is just has to allow describing how to convert a new email body > back to the original email body, and I believe this can be done reliably > and at a reasonable cost, though it could definitely use some more examples. > > I'm going to publish an update with another mechanism which reduces the > cost of the "remove an attachment" version to at least not fill the headers > with tons of junk. It doesn't reduce the message size though, because you > do need to be able to recreate the old message. > > And I do agree there needs to be a way to say "I made changes, and I'm not > telling you how to undo them" as well. > +1. My belief is that security gateways are a particularly complex case that needs this trust me bit. For example they may redact or encrypt content where it doesn't make sense to provide the original content for. When security gateways rewrite many URLs, it may become burdensome to encode and reverse, and downstream receivers are going to have to trust the gateway to make benign transformations. This can work because they already have a relationship with their security vendor. However a trust me bit in general introduces a security loophole hence receivers should use only in those limited well understood scenarios. -Wei
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
