Five years ago, Dave Crocker launched a powerful challenge against DMARC. I will paraphrase his concepts in this way:
"RFC7489, as typically implemented, causes more harm than good." Five years ago, I doubted the premise. Today, I substantially agree with it. Five years ago, much of this group was embracing that premise. Today, this group is ready to ship a document that does precious little to change the harm-good relationship. This is a mistake. Dave wanted to fix the problem by deprecating RFC 7489 and its concept of “From” authentication. I never agreed with that solution, and do not agree today. The problem is not with the concept of “From” authentication, the problem that we need to fix is the “typical implementation.” I define the “typical implementation” as having these characteristics: · DMARC Fail with p=reject is honored, and the message is rejected. · Other results are mostly ignored. · DMARC Fail does not update the evaluators reputation database, because an impersonated identifier is not useful for that purpose. Let’s review the benefit-harm balance: · The good part of DMARC comes when it correctly blocks a malicious impersonation message, preventing it from harming the recipient. In the absence of DMARC, a malicious message might still be rendered harmless because of defense-in-depth: content filters might block the message, skeptical users might distrust the message, busy users might ignore the message, web filters might block payload deployment by blocking a malicious link, and anti-virus software might block payload deployment by detecting a malicious attachment. DMARC is likely to correctly detect some malicious messages that would escape all of those other defenses, and that marginal benefit is very good. Nonetheless, the incremental benefit from DMARC occurs on much less than 100% of the messages that it blocks correctly. · Conversely, a message which is rejected incorrectly cannot be un-rejected. The harm cannot be un-done by resending the message, because the second message will be rejected for the same reason as the first one. Sometimes, a rejected message will lead to cancellation of an entire mail stream subscription, so the harm is much more than one blocked message. A different way to examine benefit-harm ratio is to evaluate DMARC coverage: · The typical implementation only protects against a small subset of all malicious impersonation attacks, those which attack domains with enforcement policies. If that covers 10% of the evaluator’s incoming mail stream, then 90% of all malicious impersonations are slipping past the typical implementation. · The typical implementation only protects against malicious impersonation attacks, and learns nothing about the actual attack source when an attack is detected and blocked. Therefore, it only defends against a subset of the attacks expected from the typical attacker. Collectively, these two limitations mean that DMARC evaluation is a lot of work for a disappointingly small benefit, even when it produces correct results. Knowing that it also causes harm makes the problem even worse. A third way to consider this problem is based on relative importance: If an omniscient source informed us that DMARC Fail-with-reject identifies malicious messages with 90% accuracy, would that be a sufficient reason to block 100% of all Fail-with-reject messages? Some might say, “Yes,” but I say, “No!” Some of that 10% is important stuff, and the only correct action is to figure out how to distinguish between the 90% and 10%, which means that the DMARC answer should never be considered conclusive. Fixing the Typical Implementation We need to explicitly reject the typical implementation. Early in the document, we observe that DMARC PASS does not mean the message is safe or wanted. The inverse is also true and should be said at the same time: DMARC FAIL does not mean that the message is malicious and unwanted. DMARC provides useful probabilities, but it does not provide any certainty. The current draft attempts to state the inverse, but the warning is buried deep in the document and is watered down compared to the early statement. DMARC does not detect the responsible identifier DMARC detects that the “From” domain may not be the entity who is responsible for the message, and an inspection of the message may confirm that the message is malicious. When a message is known to be malicious, that knowledge should feed into the evaluator’s reputation database, but that cannot be done until the responsible actor is identified. The source identifiers in a message have three functions: server identity, SMTP domain identity, and Author (From) identity. They also have three levels of accountability: · Impersonated domains are victims, and have no responsibility for malicious messages. · Infrastructure domains provide services to a multitude of clients, their best clients will send safe and wanted messages, while their worst clients will send unwanted or malicious messages. Infrastructure organizations are expected to implement controls to minimize the opportunities for bad actors to use their services, but those controls are not expected to be fully effective. An infrastructure identifier is not useful for message filtering, unless their clients are always good or always bad. (Infrastructure identifiers can occur at any function level.) · Responsible identifiers are those identifiers which are neither impersonated or infrastructure. When DMARC detects a suspicious message, the evaluator needs to review the message to identify the responsible identifiers, so that the malicious entity can be blocked. Conversely, if inspection determines that the message is wanted, then a custom allow rule is needed to ensure that similar messages, from that responsible identifier, are allowed in the future. Distinguishing the responsible identifier requires a review process, which can be implemented in two ways: · Quarantine then review, and release only when safe. Messages which never get reviewed age out of the quarantine list and are discarded. This approach minimizes risk from truly malicious messages. It should be used when the probability of malice is high, which certainly includes fail with p=reject. · Allow, then review. This minimizes the risk of delay or discard for legitimate and wanted messages that are flagged as possibly suspicious. It may be used when the probability of malice is perceived as low, which may include p=none. What all of this means is that evaluators should never use p=reject to reject the message. Instead, DMARC feeds the reputation database, and the database of known-bad identifiers is used to reject messages from known-bad senders. When DMARC is used to feed the reputation system of both acceptable and unacceptable identifiers, harm is minimal. Single messages may be delayed by quarantine, but no legitimate message stream suffers ongoing disruption. Additionally, the limitations of the typical implementation are fixed in both directions. A DMARC result can be computed on all messages, so that impersonation risk can be investigated, and so that high priority messages can be safely whitelisted. Once a malicious attacker is confirmed and blocked with a reputation database update, the other threat direction is addressed because non-impersonation messages from that attacker are also blocked. P=Reject is a useful clue that appropriately influences an evaluator’s estimate of risk probability. But the only way to produce a correct result is to convert probability to certainty by obtaining additional information which resolves the ambiguity, and then documenting that result in the reputation database.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
