Re: [dmarc-ietf] Mailing List message authentication

[Douglas Foster <[e-mail]>]

Yes Todd, this is the problem language:

"If the set produced by the DNS Tree Walk contains no DMARC policy record
(i.e., any indication that there is no such record as opposed to a
transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to
the message."

There are really two issues involved:  "What is DMARC?" and "What does MUST
NOT mean?"

My concept of DMARC has been that it includes everything which can be
elucidated by using SPF and DKIM to validate or repudiate the RFC5322.From
address.   I have probably been alone in that state, but when Barry first
said "That's not DMARC," I had no reference point with which to understand
his assertion.

[When I quibbled, I was told that DMARC without the policy is not a
protocol, and IETF only does protocols.   That answer did not settle the
issue because IETF did SPF, which is only a unidirectional information
flow, but is apparently a protocol.   This red herring hindered my ability
to grasp what you do want DMARC to be.]

If DMARC is simply one application of how SPF and DKIM are used to
authenticate RFC5322.From, then other strategies are excluded for
convenience of scope, not excluded on principle.   When it is understood in
those terms, I can go along with the limited scope definition that you
want.  Maybe I am the only one who needs the explicit scope definition that
I proposed, but in a world of 7 billion people, I am willing to guess that
I will not be the only one who needs this clarification.  In particular, I
don't want to come back with a proposal like this Mailing List
Authentication idea, and have it dismissed as a layer violation, because
"DMARC says that if you don't have a policy you cannot do RFC5322.From
authentication."   Maybe that is paranoid, but I would appreciate having
the possibility of other uses stated explicitly rather than presumed.

About MUST / MUST NOT
I have raised this issue before.   I expect MUST or MUST NOT to be used
where failure to comply will cause harm, most likely to the person
violating the directive.   For example, a mail sender MUST start an SMTP
session with HELO or EHLO.  If they do not, they will not send any email
via SMTP.  In this document, I find no place which meets that level of
importance.   On the contrary, evaluators can do whatever they want, with
whatever information that they have available, to reach a disposition
decision that seems to be in their self interest.    In this particular
paragraph, my point is that evaluators can sometimes use SPF and DKIM to
make an intelligent disposition decision, even when the policy is lacking.
 Our document should not be saying MUST NOT when it is likely to be in the
evaluator's best interest to do the exact opposite.

My remaining quibble
We have these situations where the verification result is unambiguous, with
or without a DMARC policy:
- A verified identifier that has the same domain as the RFC5322.From
address is always a PASS.
- A verified identifier that does not match at least the two right-most two
labels is always not aligned.  If there are no verified identifiers, or
there are no identifiers that align on at least two labels, then the result
is always FAIL.

I think it is a disservice to press the scope definition so severely that
we cannot find a couple of sentences to include these exceptions in the
document.   But as long as the reader understands that these cases are not
relevant because they do not fit the strict scope definition, then so be it.

Doug





On Wed, Aug 24, 2022 at 2:38 PM Todd Herr <todd.herr=
[e-mail]> wrote:

> On Wed, Aug 24, 2022 at 2:09 PM Douglas Foster <
> [e-mail]> wrote:
>
>> I understand the need to limit scope, if DMARC limits its claims to what
>> it covers.  This complaint was triggered largely with the "MUST NOT" claim
>> in the draft, which implied that DMARC is the all-inclusive tool for
>> validating the RFC5322.From address using SPF and DKIM.  If it is all
>> inclusive, it needs to be comprehensive.  If not, it should be clear that
>> other options are possible.  I would be satisfied with changing the "MUST
>> NOT" into a reference to local policy, and including this language in the
>> scope and goals section.
>>
>
> This is the text in question, yes?
>
> "If the set produced by the DNS Tree Walk contains no DMARC policy record
> (i.e., any indication that there is no such record as opposed to a
> transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to
> the message."
>
>
> That's from section 4.7 in DMARCbis, and updates RFC 7489 by changing
> "SHOULD NOT" to "MUST NOT".
>
> Please help me understand how you arrived at the conclusion that this
> statement declared DMARC "the all-inclusive tool for validating the
> RFC5322.From address using SPF and DKIM", because I don't take that
> meaning. Rather, it reads to me as "If there's a DMARC policy found, do
> DMARC validation. If there's no DMARC policy found, don't do DMARC
> validation."
>
> I don't see anything there declaring DMARC to be the only way to validate
> the RFC5322.From domain (DMARC doesn't validate the RFC5322.From address);
> I would expect your interpretation (i.e., DMARC is the one true way) to be
> supported by text that read as follows:
>
> "If the set produced by the DNS Tree Walk contains no DMARC policy record
> (i.e., any indication that there is no such record as opposed to a
> transient DNS error), Mail Receivers MUST apply the DMARC mechanism to the
> message anyway."
>
>
>
>> "The combination of SPF and DKIM provide a concept for validating the
>> RFC5322.From address.  DMARCbis defines a protocol for using this concept
>> with bi-directionaoll communication between the recipient and the domain
>> owner, using SPF, DKIM, a DMARC policy, and a reporting framework.
>>  Validation strategies which do not use a DMARC policy, use different
>> alignment strategies, or do not include reporting are considered out of
>> scope."
>>
>>
>> About Decisonmaking
>> Both DMARC FAIL and NO POLICY create concern that the message might be a
>> malicious impersonation.  FAIL probably adds greater weight than NO POLICY,
>> and .FAIL with "p=reject" adds even more weight.  A reasonable solution is
>> to proceed with content filtering.   Messages which die in that filter
>> provide confirmation that the message is unwanted.  For messages that
>> survive content filtering, the decision is how to disposition the message
>> given the DMARC result.
>>
>
> I will agree that DMARC FAIL probably adds further weight than NO POLICY,
> and I'll also say that the DMARC result should be independent of whether or
> not a message is subject to content filtering. Put another way, DMARC PASS
> says nothing about the content of the message and whether or not it might
> be wanted; it only says that the use of the domain in the RFC5322.From
> header was authorized by the domain owner based on the results of the SPF
> and/or DKIM checks.
>
>
>>  DMARC PASS means that the message is judged free of impersonation risk.
>>  This improves the probability of acceptance by any disposition system
>> based on risk weighting which is why I asserted that a PASS may increase
>> delivery rates for a sender.)
>>
>
> DMARC PASS does not mean that the content is wanted mail. It only means
> that the domain in the RFC5322.From header wasn't impersonated. Any domain
> can achieve a DMARC PASS.
>
>>
>> If a particular domain is trusted and configured for whitelisting,
>> eliminating impersonation risk becomes essential.  Since any domain may be
>> selected for whitelisting, the system administrator needs to be able to
>> validate any trusted message source.   Much of my desire to maximize DMARC
>> PASS results is to minimize the complexity of providing validation via
>> other strategies.
>>
>
>  DMARC PASS does not mean that the content is wanted mail. It only means
> that the domain in the RFC5322.From header wasn't impersonated. Any domain
> can achieve a DMARC PASS.
>
>
>> Finally, PASS simplifies risk management by reducing the volume of
>> messages that need to be evaluated for malicious impersonation risk.
>>
> I'm sorry, but I don't understand this statement. DMARC PASS is achieved
> through applying the DMARC mechanism to a message, which is evaluating the
> message for impersonation, is it not?
>
>>
>> In sum, PASS is more useful than FAIL because the result is more
>> certain.   Tthe value of DMARC PASS seems poorly understood by the vendor
>> community.
>>
>
> DMARC PASS means that the domain in the RFC5322.From header wasn't
> impersonated. Any domain can achieve a DMARC PASS.
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* [e-mail]
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>