At this point in document maturity, an accusation of bad design should be easily refuted by available evidence. But this cannot be done because we already have an entire RFC that documents the flaws.
The DMARC design flaws, which DMARCbis preserves, are: - Fail with Reject equals malicious - Blocking individual messages is a sufficient response to "Fail with Reject" - Fail with None is unimportant To illustrate these problems, assume that an omniscient observer knows that 100 messages arriving to an evaluator from Example.Com will have these characteristics: - 94 authenticated and wanted - 3 unauthenticated and wanted - 3 unauthenticated and malicious DMARC and DMARCbis provides two outcomes: - If the sender policy is "reject" and the evaluator follows that policy, 6 messages are blocked, 3 of which are wanted, but all 3 attacks are blocked. - If the sender policy is "none" or the evaluator ignores that policy, all 100 messages are allowed, included the 3 attacks So the immediate questions are: - Why are these the only two options? - Why should the evaluator delegate this decision to the owner of the From domain? Further assume that for whichever reason, the relaxed approach is taken and all 100 messages proceed to content filtering. The evaluator gets lucky because all 3 attacks are blocked, and he has a perfect outcome for his users -- at first. But it leaves a ticking time bomb. Now assume that some of the authenticated messages get blocked by content filtering because they contain "franchise" and "wire transfer", words that keep showing up in spam. To solve this problem, the evaluator chooses to whitelist messages from Example.Com. This whitelists the wanted messages as well as the malicious attacks, triggering the time bomb, and the evaluator's network is successfully penetrated. What should have happened: - Both authentication failures and content filtering blocks should be investigated to the responsible party, and those responsible identifiers blocked. - Sender policy has little importance because all authentication failures need to be investigated and resolved. - Whitelisting rules should only be applied to authenticated messages. Fix these problems, and I will be happy to stop objecting to this document. Enforcing sender authentication has been a huge win to my network security. DMARC has the right idea, but it takes shortcuts that make it unsuitable as a general tool. The solution is not to minimize reject policies, as DMARCbis suggests. The solution is to put effort into evaluating DMARC results. Doug Foster On Mon, Oct 14, 2024 at 7:06 AM Douglas Foster < [email protected]> wrote: > It is not about fixing the text, it is about fixing the design. > > Authentication has only 2 states: > > - Authenticated, therefore judged free of impersonation risk > - Unauthenticated, therefore possibly an impersonation and possibly a > malicious impersonation. > > The Unauthenticated result can occur for many reasons other than > malicious impersonation, and many unauthenticated messages are actually > acceptable. Therefore, an unauthenticated result is always an ambiguous > result. Ambiguity always requires collection of additional information. > > Authentication state is an attribute of a mail stream. When information > gathering resolves an ambiguity, that new information must be codified into > local policy, so that the ambiguity is eliminated for all future messages > with the same characteristics. For unwanted mailstreams, the local policy > is implemented as a block rule. For wanted mailstreams, the local policy > is implemented as an alternate authentication rule. An alternate > authentication rule is always possible once the responsible identifier is > determined. > > Some mail flows cause authentication to be lost in transit, while other > mail flows cause authentication to be gained in transit. Consequently, > the true Authentication state cannot always be determined using the final > state of the message. Authentication analysis will be a process of > continuous improvement to ensure that indirect mail flows are handled > optimally. > > - - - > Since the group has spent years working from inferior design assumptions, > can we fix the problem with a Best Practices document? > > Doug Foster > > >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
