Thank you for the reply Oliver. Your objection to "Fail with Reject equals malice" is valid only in a technical sense. Yes, the document gives the evaluator permission to do what he wants. The problem is that seemingly everyone who reads RFC7489 draws the conclusion I describe. It is the big selling point: "implement DMARC and block malicious impersonation." Non-malicious impersonation seems impossible, until it is actually observed in a mail stream. Those who take the DMARC marketing hype are doubly harmed: They don't look for impersonation when policy is not "reject", and they don't accept messages when the failure is non-malicious and wanted.
Without that marketing hype, DMARCs purpose becomes fuzzy: "DMARC splits messages into authenticated and unauthenticated buckets, but what do I do with that information?" If the advice is not "Block on Fail with Reject", then the advice is "We have no idea. (Not my job!)" At times we excuse silence on the basis that evaluators are smart and will figure this out for themselves. Then we complain because evaluators don't figure it out on their own and instead implement an instance of the "mailing list problem." Sender authentication is incredibly useful when it is pursued from a strategy of maximizing PASS instead of hunting for "really bad Fail", but I have yet to find anyone else using it with this philosophy, and my attempts to explain it to this group have met continued failure. I know it is the right path forward because I have spent the last five years building a solution based on From maximization. Some of the differences between the document and a successful implementation based on maximizing Pass: - I apply the DMARC test to every message, not just those with DMARC policies. - I never block based on a verification failure. Failures go to quarantine and are investigated. So I don't have "the mailing list problem". - When a wanted message does not arrive with Pass, I construct alternate authentication. DMARC and DMARCbis provide no guidance about handling false positives, and have nothing to say about alternate authentication techniques. My survey of the commercial market suggests that the concept of alternate authentication is not understood by the filtering industry. - Having created alternate authentication for direct flows, the solution for indirect mail flows has fallen into place: I need to apply the DMARC test to every organization boundary in the Received header flow. This is conceptually necessary to avoid both false positives and false credential upgrades, but it is technically very difficult, so it is my current area of research and I am optimistic. ARC is a very important tool for this effort. ARC is the WG's first venture into alternate authentication. DMARCbis is not sure what to do with ARC because it does not have a prior history of using alternate authentication methods. Bottom line: ARC is valuable because it is an available tool for an environment where multiple authentication tools are needed. The WG wants to fix the mailing list problem. Maximizing Pass has been my solution, and it works. Warning domain owners that they may not be appropriate candidates for p=Reject, as our current document does, has not worked in the past and is unlikely to work well in the future. Instead of asking sending domains to embrace weak security, why not advise receiving domains on how to embrace optimal security? Since indirect mail flows will benefit from applying the DMARC test (and local policy overrides) to an earlier message state, the aggregate reporting will benefit from revisions to document those early evaluatons. Other than that problem, I think these issues could be discussed effectively in a Best Practices document published prior to, our jointly with DMARCbis. Doug Foster On Wed, Oct 16, 2024, 7:28 PM OLIVIER HUREAU < [email protected]> wrote: > Douglas, > > With all due respect, I think that your demonstration is biased since your > first assertion : > > "Fail with Reject equals malicious, Fail with None is unimportant" > > RFC 7489 describes the handling policies as the policy a domain owner > "wishes" to be applied when emails fail the DMARC check mechanism. > It does not say that the email receiver MUST follow the handling policy. > > To prove my point : > > "These receivers can use these results to determine how the mail should be > handled." > RFC 7489, Introduction > https://datatracker.ietf.org/doc/html/rfc7489#section-1 > > "Recipient transport service either delivers the message to the recipient > inbox or takes other local policy action based on the DMARC result (not > shown)" > RFC 7489, Flow Diagram > https://datatracker.ietf.org/doc/html/rfc7489#section-4.3 > > "p: Requested Mail Receiver policy (plain-text; REQUIRED for policy > records). Indicates the policy to be enacted by the Receiver at the > request of the Domain Owner." > RFC 7489, General Record Format > https://datatracker.ietf.org/doc/html/rfc7489#section-6.3 > > Thus, your assertion, "Fail with Reject equals malicious, Fail with None > is unimportant," is, in my opinion, wrong. > I would reformulate it as follows: > - Fail with p=reject means that the owner of the domain name wishes that > the email recipient reject the message. > - Fail with None means that the owner does not see any objections to > delivering the message if the DMARC check mechanism fails. > > I agree with you that the behaviors of the evaluators who whitelisted the > email from example.com are inappropriate. > They should have behaved differently, as I have seen when working in a > previous company: > - Blocking the message > - Do not silently discard it so that the sender, having a bounce back, > will enforce the authentication of the email. > > To answer your immediate questions : > > > Why are these the only two options? > > Multiple arguments have already been provided in this mailing list. One of > them is that we should need a version bump. > The consensus of this WG was against the version bump. > > > Why should the evaluator delegate this decision to the owner of the From > domain? > > It does not. Please refer to the first part of this message. > > > Fix these problems, and I will be happy to stop objecting to this > document. > > I may be wrong, but those problems are not part of the Working Group > charter ? > C.F Murray's email: > https://mailarchive.ietf.org/arch/msg/dmarc/DDE1ciDa5FEavVtV_SIrKT4bzHQ/ > > However, an RFC with Informational status about email delivery wouldn't be > more helpful than trying to fit everything into dmarcbis? > > Best, > > Olivier Hureau > ------------------------------ > *De: *"Douglas Foster" <[email protected]> > *À: *"IETF DMARC WG" <[email protected]> > *Envoyé: *Mercredi 16 Octobre 2024 12:27:32 > *Objet: *[dmarc-ietf] Re: AD Evaluation for draft-ietf-dmarc-dmarcbis-33 > > 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] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
