Barry, it is a truism that a WG publication request implies consensus of the workgroup. But I expect the Last Call to consider the question of whether the workgroup addressed an important public good and solved it. Your document says that you have not.
Within the WG, the public good which had the greatest interest was a solution to the mailing list problem. Since evaluators are blocking the affected mailing list traffic, the solution requires a change in evaluator behavior. The WG had no idea how to change evaluator behavior directly, so the document attempts to achieve this result indirectly, by advising domain owners to limit use of DMARC enforcement.
There is a GOOD alternative to the FAST-CHEAP mess. We need to help evaluators investigate and respond to the root causes of authentication failure. The response to a false positive needs to be free of impersonation risk. When the focus is placed on tracing the real problem from authentication failure to root cause, and safe responses are possible, most mailing lists will be judged acceptable and be granted an exception.
The despair in this document is unnecessary. The mailing list problem can be solved while increasing protection from malicious impersonation that causes ransomware. I know because I have done it, and done so while the WG was moving from hope to despair.
Within the WG, the public good which had the greatest interest was a solution to the mailing list problem. Since evaluators are blocking the affected mailing list traffic, the solution requires a change in evaluator behavior. The WG had no idea how to change evaluator behavior directly, so the document attempts to achieve this result indirectly, by advising domain owners to limit use of DMARC enforcement.
When the issue is framed as a choice between fewer ransomware infections and less mailing list traffic, or more ransomware infections and more mailing list traffic, the mailing list traffic will always lose (or at least it should). We need to break that tradeoff.
The document concedes defeat by noting that mailing lists have adopted workarounds, however unpleasant, and therefore the problem does not need to be solved. Five years ago, when I joined the group, I was pretty happy with "problem does not need to be solved," and some members of the group took great offense at me as a result. It is ironic that the group has finally reached that conclusion, while I have moved away from it. I want to fix the mailing list problem because I believe it indicates evaluators are acting against their own interest. A better understanding of the filtering problem will both increase security and decrease mailing list damage.
RFC 7489 offered evaluators a cheap, easily implemented solution to a tiny subset of the email filtering problem. Evaluators have been so desperate for answers to malicious email that they jumped on it. But the quick solution comes at a cost, which is best illustrated by an engineering design axiom that I heard many years ago: "Good, Fast, Cheap: pick at most two!". RFC 7489 is fast and cheap at the expense of Good. FAST-CHEAP pretends that an equivalence exists between authentication failure and malice, something that is simply not true. The consequence of a Fast-Cheap DMARC is (a) the mailing list problem, and (b) inadequate defenses against the vast majority of impersonation attacks which occur every day but are not tagged for DMARC enforcement.
RFC 7489 offered evaluators a cheap, easily implemented solution to a tiny subset of the email filtering problem. Evaluators have been so desperate for answers to malicious email that they jumped on it. But the quick solution comes at a cost, which is best illustrated by an engineering design axiom that I heard many years ago: "Good, Fast, Cheap: pick at most two!". RFC 7489 is fast and cheap at the expense of Good. FAST-CHEAP pretends that an equivalence exists between authentication failure and malice, something that is simply not true. The consequence of a Fast-Cheap DMARC is (a) the mailing list problem, and (b) inadequate defenses against the vast majority of impersonation attacks which occur every day but are not tagged for DMARC enforcement.
There is a GOOD alternative to the FAST-CHEAP mess. We need to help evaluators investigate and respond to the root causes of authentication failure. The response to a false positive needs to be free of impersonation risk. When the focus is placed on tracing the real problem from authentication failure to root cause, and safe responses are possible, most mailing lists will be judged acceptable and be granted an exception.
The despair in this document is unnecessary. The mailing list problem can be solved while increasing protection from malicious impersonation that causes ransomware. I know because I have done it, and done so while the WG was moving from hope to despair.
Doug
On Fri, Nov 29, 2024 at 10:59 AM Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote:
Doug, you have repeated this argument many times in the working
group's development of the document. You're repeating it again during
last call. You want DMARC to do more than it's designed for. There
is very strong consensus in the working group *not* to expand its
scope -- that DMARC is one part of the overall picture, and is not
intended to solve all the issues you want to solve.
Your view is valid, but strong working group consensus is in the other
direction. You are simply "in the rough" here.
Barry, DMARC working group chair
On Fri, Nov 29, 2024 at 8:55 AM Douglas Foster
<dougfoster.emailstandards@xxxxxxxxx> wrote:
>
> What is the public good that DMARC seeks to address?
>
> If the goal is to ensure that devastating ransomware attacks are not attributable to messages that impersonate a bank, then the goal has been acheived.
>
> If the goal is to ensure that devastating ransomware attacks are not attributable to messages that impersonate any sender, then the goal has not been attempted.
>
> Doug Foster
>
>
> On Fri, Nov 22, 2024 at 12:17 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
>>
>>
>> The IESG has received a request from the Domain-based Message Authentication,
>> Reporting & Conformance WG (dmarc) to consider the following document: -
>> 'Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC) Aggregate Reporting'
>> <draft-ietf-dmarc-aggregate-reporting-23.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> last-call@xxxxxxxx mailing lists by 2024-12-06. Exceptionally, comments may
>> be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
>> of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>> Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC) allows for Domain Owners to request aggregate reports from
>> receivers. This report is an XML document, and contains extensible
>> elements that allow for other types of data to be specified later.
>> The aggregate reports can be submitted to the Domain Owner's
>> specified destination as supported by the receiver.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
>>
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>> rfc6713: The 'application/zlib' and 'application/gzip' Media Types (Informational - Internet Engineering Task Force (IETF) stream)
>> rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission stream)
>>
>>
>>
>>
>> _______________________________________________
>> dmarc mailing list -- dmarc@xxxxxxxx
>> To unsubscribe send an email to dmarc-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
