That's a good point around ARC as that's what it was meant to do. And that got me thinking that it might be helpful to systematically compare the different proposed approaches and their pros and cons. The next approach would be to consider the general approach of the reversible transform idea that several folks have proposed, and how that would look. And that got me rethinking the "DARA" work that we're already prototyping for DKIM replay mitigation, if it can relate to mailing-list and forwarder modifications and I now think DARA can help here too. The three different approaches have distinct pros and cons.
The following is a summary of the comparison. Attached is a more detailed comparison as PDF that tries to work through what the algorithms would likely do. ARC Use ARC to override the SPF and DKIM results at Receiver by those found at the Forwarder. Pros: - Uses existing SPF, DKIM and ARC standards. - Tolerates header and body modifications Cons: - Receiver must trust the ARC headers generated by the forwarder. - Receiver must trust the modifications the forwarder made. - Receiver must trust that no ARC replay occurred Transform Proposed in draft-kucherawy-dkim-transform <https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/02/> where the forwarder can specify a "tf=" tag that specifies addition of Subject header prefix, text footer to a mime-part, mimify plaintext, and adding a mime-part representing a footer to an existing mime-tree to the DKIM-Signature. These all may be reversed to recover the original signature. DKIM-Signature: d=...; tf=subject,mime-wrap, The ideas in draft-vesely-dmarc-mlm-transform-07 <https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform-07> are conceptually similar though add support for ARC. Pros: - Tolerates header and body modifications - Identifies the modifications - Does not require particular trust of the forwarder to be non-malicious Cons: - Receiver must trust that no DKIM replay occurred - Might not compose across multiple modifying forwarders - Might not support all possible modifications by forwarder - Reversing all possible draft transformations is potentially complicated DARAThis clarifies the DARA ideas in draft-chuang-replay-resistant-arc <https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/> which calls for authenticating a path from the Originator through the Forwarder to the Receiver that's tolerant of modifications. Some ideas of a validated path are explored in draft-levine-dkim-conditional <https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04>. Pros: - Tolerates header and body modifications - Does not require particular trust of the forwarder to be non-malicious - Supports arbitrary many forwarders that may modify the message - Supports protocol unaware participants Cons: - Requires DNS policy lookup on outbound delivery - Requires additional messages DKIM signing to support Bcc/Mailing-list recipients (each get their own signed copy) - Builds upon ARC which is considered complicated -Wei On Sat, May 6, 2023 at 7:42 AM John R Levine <jo...@taugh.com> wrote: > > It is not a commitment at this time. That said, we are interested in > > solving this problem and welcome collaboratively figuring out the right > way > > to do this. > > It seems to me that ARC provides the useful parts of third party > signatures and, while rather complicated, has the benefit of actually > existing. The chain of authority runs from the relay host back to the > original rather than the other way around, but that's a lot easier to do > mechanically. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. >
Mailing-List Authentication Comparison (ietf-dkim).pdf
Description: Adobe PDF document
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
