Hector, my life is short, and this group already takes up more of it than my wife wants. If you are a subject matter expert on all of those RFCs, we need you to summarize the relevant pieces for those of us who are not.
But you imply that if I read all of those RFCs, I would see that your third-party authentication proposal is the solution. I don't see that happening, and I am looking for you to adapt your pitch in the light of the pushback that has been given already. To recapitulate one aspect: Today, mailing lists ask this: "Subscriber evaluators need to trust any From address for messages that are verifiably from the List Server's MailFrom address." Third-party authentication with DNS entries asks this: - The subscriber asks his admin to publish trust for the list server domain to impersonate the subscriber domain, without limit. - The domain admin publishes the trust indicator - The evaluators (which are usually the same domain admins) also choose to accept the trust indicators from other domains. The first step requires communication flows that may not happen. The second and third steps require grants of trust that are not easily obtained. If the process breaks down for any one subscriber, the necessary exception mechanism for every evaluator is: "Subscriber evaluators need to trust any From address for messages that are verifiably from the List Server's MailFrom address." Of the proposals on the table, Murray's has the advantage because hashing solves the scaling problem. But even Murray has lost hope of it being accepted. As for ARC, please take a look at the forwarding section of my Best Practices draft. I lay out the reasons why evaluators need to know whether a message was forwarded or not, and suggest a half dozen or so clues for detecting a forward. It is pretty obvious that ARC is the most useful entry in the list. By providing data that helps support the mailing list trust request, it moves the needle forward in a way that third-party authentication does not. ARC also provides value for forwarding situations other than mailing lists. Doug Foster On Mon, May 15, 2023 at 10:32 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote: > Wei, > > Have you studied the past R&D and functional specifications, architectural > surrounding SPF and DKIM leading up to DMARC? > > RFC5598 Internet Mail Architecture > RFC5322 Internet Message Format > RFC5321 Simple Mail Transfer Protocol > RFC4405 SUBMITTER SMTP Service Extension > RFC4406 Sender ID: Authenticating E-Mail > RFC4407 Purported Responsible Address (PRA) > RFC4408 Sender Policy Framework (SPF) > RFC4686 Analysis of Threats Motivating DKIM > RFC4870 DomainKeys > RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT) > RFC5016 Requirements for a DKIM Signing Practices Protocol > RFC5451 Message Header Field for Indicating Message Authentication > Status > RFC5518 Vouch By Reference > RFC5585 DKIM Service Overview > RFC5617 DKIM Author Domain Signing Practices (ADSP) > RFC5863 DKIM Development, Deployment, and Operations > RFC5965 An Extensible Format for Email Feedback Reports > RFC6376 DomainKeys Identified Mail (DKIM) Signatures > RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists > RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party > Signatures > > I find it technically unfeasible and non-logical to support a high > overhead, complex ARC concept that has no promise of any solution for a > DKIM Policy model we have been seeking since 2005. > > What are we solving in the first place with ARC? The ability to revert to > original integrity due to unknown middle wares changes? What ever happen > to passthru mail transports? > > In my technical view, it has been the PORT 25 unsolicited 3rd party > signature unauthorized by the author domain due to the dearth of scaled > AUTHOR::SIGNER Authorization methods. ARC is not resolving this problem. > The overhead is horrendous. > > We have been seeking deterministic protocols to filter out failures with > zero to low false positive. Diffusion by Osmosis! > We don't have it today. It has been made more complex than it really > is. I recommend to study the past work. > > Thank you. > > -- > Hector Santos, CEO/CTO > Santronics Software, Inc. > > > > > On 5/15/2023 5:02 AM, Wei Chuang wrote: > > 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 > > > DARA This 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. >> > > > _______________________________________________ > dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc > > > > -- > Hector Santos,https://santronics.comhttps://winserver.com > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc