Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Scott Kitterman]

On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote:
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman 
> 
> wrote:
> > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > > We had an opportunity to further review the DMARCbis changes more
> > > broadly
> > > within Gmail.  While we don't see any blockers in the language in
> > 
> > DMARCbis
> > 
> > > version 28
> > >  and
> > > can live with what is there, we wanted to briefly raise some concerns
> > > around some of the changes.  Two points.
> > > 
> > > Regarding the languages in section 8.6 "It is therefore critical that
> > > domains that host users who might post messages to mailing lists SHOULD
> > 
> > NOT
> > 
> > > publish p=reject.  Domains that choose to publish p=reject SHOULD
> > 
> > implement
> > 
> > > policies that their users not post to Internet mailing lists", we wanted
> > 
> > to
> > 
> > > point out that this is impossible to implement.  Many enterprises
> > > already
> > > have "p=reject" policies.  Presumably those domains were subject to some
> > > sort of spoofing which is why they went to such a strict policy.  It
> > 
> > would
> > 
> > > be unreasonable to tell them to stop posting to mailing lists as many
> > > likely already use mailing list services and will want to continue to
> > > use
> > > them.  The one thing that makes this tractable is the SHOULD language as
> > 
> > we
> > 
> > > may choose not to not follow this aspect of the specification.  Our
> > > suggestion is that there is not a lot of value in including this
> > > language
> > > in the bis document if the likely outcome is that it will be ignored,
> > > and
> > > rather more effort should be placed with a technical solution for
> > > interop
> > > with mailing lists.
> > 
> > It might be helpful if you could describe this technical solution from
> > your
> > perspective.
> > 
> > If there were a reasonable technical solution available, I think this
> > would be
> > a much easier change to support (in my opinion, and a believe a
> > substantial
> > number of others, rewriting From is not a reasonable technical solution).
> > 
> > Scott K
> 
> Apologies for the delay in getting back to this.
> 
> So yes I believe there are two possible technical approaches broadly
> speaking 1) Support rewriting From and being able to reverse it along with
> message modifications to recover the original DKIM message hash to validate
> the original DKIM signature.  2) Create a new message authentication method
> that is tolerant of message modifications and message forwarding, and
> supported by DMARC.  From header rewriting would not be necessary in this
> scenario.  Beyond the complexity of supporting either method, another
> tricky thing in both cases is supporting an ecosystem with diverse adoption
> of said technique.  More concrete proposals for 1) and 2) are 1)
> draft-chuang-mailing-list-modifications
> 
> and 2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out
> there particularly for the first approach.
> 
> -Wei

Thanks.  That's helpful.

I interpret that as confirming my view that there is not currently a reasonable 
technical solution available.  While these may be promising for the future, 
it's not like any of those solutions are things that are currently available 
to email list administrators.

I don't think any of those things are going to mature quickly, so I would find 
it concerning to delay publication of DMARCbis until they are ready.  If we 
aren't going to put DMARCbis on ice for a few years (please, let's not), then 
I think we're left with something like the language that's there now or some 
variation of NOT RECOMMENDED unless [unobtainium] which amounts to the same 
thing, but is in my view less clear.

I think in a couple of years we could do some kind of an update that relaxes 
the current language based on one of these techniques if they become 
deployable, but I don't think we can do it now.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Wei Chuang]

On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman 
wrote:

> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > We had an opportunity to further review the DMARCbis changes more broadly
> > within Gmail.  While we don't see any blockers in the language in
> DMARCbis
> > version 28
> >  and
> > can live with what is there, we wanted to briefly raise some concerns
> > around some of the changes.  Two points.
> >
> > Regarding the languages in section 8.6 "It is therefore critical that
> > domains that host users who might post messages to mailing lists SHOULD
> NOT
> > publish p=reject.  Domains that choose to publish p=reject SHOULD
> implement
> > policies that their users not post to Internet mailing lists", we wanted
> to
> > point out that this is impossible to implement.  Many enterprises already
> > have "p=reject" policies.  Presumably those domains were subject to some
> > sort of spoofing which is why they went to such a strict policy.  It
> would
> > be unreasonable to tell them to stop posting to mailing lists as many
> > likely already use mailing list services and will want to continue to use
> > them.  The one thing that makes this tractable is the SHOULD language as
> we
> > may choose not to not follow this aspect of the specification.  Our
> > suggestion is that there is not a lot of value in including this language
> > in the bis document if the likely outcome is that it will be ignored, and
> > rather more effort should be placed with a technical solution for interop
> > with mailing lists.
>
> It might be helpful if you could describe this technical solution from
> your
> perspective.
>
> If there were a reasonable technical solution available, I think this
> would be
> a much easier change to support (in my opinion, and a believe a
> substantial
> number of others, rewriting From is not a reasonable technical solution).
>
> Scott K
>

Apologies for the delay in getting back to this.

So yes I believe there are two possible technical approaches broadly
speaking 1) Support rewriting From and being able to reverse it along with
message modifications to recover the original DKIM message hash to validate
the original DKIM signature.  2) Create a new message authentication method
that is tolerant of message modifications and message forwarding, and
supported by DMARC.  From header rewriting would not be necessary in this
scenario.  Beyond the complexity of supporting either method, another
tricky thing in both cases is supporting an ecosystem with diverse adoption
of said technique.  More concrete proposals for 1) and 2) are 1)
draft-chuang-mailing-list-modifications
 and
2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out there
particularly for the first approach.

-Wei
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

> On Sep 14, 2023, at 10:39 AM, Murray S. Kucherawy  wrote:
> 
> On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster 
>  > wrote:
>> 
>> The coverage problem is aggravated if we assume rational attackers.   With a 
>> plethora of domains available for impersonation, attackers are least likely 
>> to use domains that are protected with p=reject.  Therefore the reference 
>> model implementation protects an evaluator where attacks are least likely, 
>> and fails to protect an evaluator where attacks are most likely.
> 
> So you're saying DMARC fails to protect domains that don't set "p=reject"?  
> That claim has the appearance of a tautology.
> 


Firs, I agree with your thoughts here.

I always considered these new DNS-based Apps that offered policies, their 
highest payoff is the most restrictive policy, the partials policies like SPF 
soft fail or unknown policies or DMARD p=none policies is technically overhead 
and redundancy if every query is always a “well I don’t know” do what you wish. 
 DNS and processing overhead.

The highest payoff for SPF is -ALL and then highest payoff for DMARC is 
p=reject despite its faulty authorization or restrictive algorithm,

All the best,
Hector Santos

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Hector Santos]

> On Sep 14, 2023, at 7:36 AM, Dotzero  wrote:
> 
> On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  > wrote:
>> 
>>> On Sep 13, 2023, at 8:51 PM, Dotzero >> > wrote:
>>> 
>>> DMARC does one thing and one thing only. It mitigates against direct domain 
>>> abuse in a deterministic manner, nothing else. It doesn't stop spam and it 
>>> doesn't depend on or involve reputation. It is but one tool among a number 
>>> of tools that various parties can choose from. A message passing DMARC 
>>> validation does not mean the message is "good". There is no question of 
>>> fault. Perhaps you should recommend changes to incorporate a blame game if 
>>> your goal is to determine fault. 
>> 
>> Deterministic means there is no question -  you follow the protocol. Your 
>> (speaking in general) opinions don’t matter. 
> 
> It means that the output of the algorithm is deterministic. It does not mean 
> that the receiver blindly act on that output. As has been stated many times 
> by many people, a policy assertion is a request by the sending domain 
> administrator/owner, not a mandate. That is why local policy on the part of 
> the receiver overrides a sender policy assertion.
> 


Over the years, as a supporter of SPF and DKIM Policy, and being the DSAP's 
author, I've witnessed how deterministic protocols like SSP, DSAP, ADSP, and 
DMARC pave the way for policy-driven rejections. They operate without 
subjectivity. But the inclusion of local policies can lead to diverse behaviors 
among platforms. While Site A might conform strictly to a policy, Site B might 
diverge.

The introduction of RFC 5016, Section 5.3, Item 10 underlines the primacy of 
local policies. This was especially pertinent for Mailing List systems, which 
often tampered with the original DKIM author's signature integrity. These 
systems then re-signed the altered message for list distribution as a 3rd 
party. At that time, a gap existed as we lacked a deterministic policy catering 
to these 3rd parties, which could work alongside SSP,  ADSP and now DMARC's 1st 
party only signer algorithm.

DMARC has amplified the significance of local policies, given the high 
likelihood of false positives. The introduction of local policies has somewhat 
diluted the effectiveness of deterministic protocols. We're still navigating 
these nuances, even after 15+ years.

All the best,
Hector Santos



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Murray S. Kucherawy]

On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC 7489.   In particular, this means that:
> - when p=none, unauthenticated messages are never obstructed, for fear of
> hindering a wanted message
> - when p=reject, unauthenticated messages are never allowed, in the blind
> faith that such messages are always unwanted
> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
>
> This raises a coverage problem.   A huge volume of traffic will not be
> protected by Sender Authentication, so the evaluator becomes entierly
> dependent upon content filtering to protect himself from attacks that
> impersonate unprotected domains.  In the unlikely case that a content
> filtering implementation is sufficient for non-DMARC domains, it is likely
> to be sufficient for DMARC domains also, making DMARC unnecessary.
>

I don't follow the logic here.  Both the DMARC verdict about a message and
the result of content filtering are, as I understand it, typically weighted
inputs to a final disposition decision, even when that DMARC result is
effectively a shrug.

If the underlying theme here is a need for ultimate determinism, I think by
now we've learned that's a fool's errand.  The decision machine is far too
complex, and making it comprehensive requires enormous investment that not
many operators can afford to make.

The coverage problem is aggravated if we assume rational attackers.   With
> a plethora of domains available for impersonation, attackers are least
> likely to use domains that are protected with p=reject.  Therefore the
> reference model implementation protects an evaluator where attacks are
> least likely, and fails to protect an evaluator where attacks are most
> likely.
>

So you're saying DMARC fails to protect domains that don't set "p=reject"?
That claim has the appearance of a tautology.

The problem is the reference model.  DMARC is not amenable or appropriate
> using a fully-automated implementation.
>

I don't believe it has ever been claimed to be such, nor do I believe there
is an illusion that this is even possible.

If the issue is that the document under development claims otherwise,
that's something that deserves attention.


> Domain owner policies of "p=none" or "no policy" SHOULD NOT cause the
> evaluator to ignore Sender Authentication considerations.
>

Does any document, published or under development, assert otherwise?


> Since any unauthenticated message carries risk of an impersonation attack,
> regardless of DMARC policy, every unauthenticated message should be
> assessed for impersonation risk.
>

Certainly, but haven't we already established this?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Wed, Sep 13, 2023 at 9:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC 7489.   In particular, this means that:
> - when p=none, unauthenticated messages are never obstructed, for fear of
> hindering a wanted message
>

I do not see the word "fear" anywhere in the specification.  When p=none,
the sending domain is not asking the receiving domain to do anything but
report the observed results of validation, assuming that a report receiving
address(s) is provided.

- when p=reject, unauthenticated messages are never allowed, in the blind
> faith that such messages are always unwanted
> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
>
> This raises a coverage problem.
>

Not really.


> A huge volume of traffic will not be protected by Sender Authentication,
> so the evaluator becomes entierly dependent upon content filtering to
> protect himself from attacks that impersonate unprotected domains.
>

By your logic, all sending domains should be forced to implement DMARC
p=reject. Nothing is further from the truth. A domain may choose to only
publish only an SPF record. A domain may choose to only use DKIM. A domain
may choose to implement DMARC. A domain may choose to implement none of
these. A domain may choose to only emit PGP signed messages. A domain may
choose to use S/MIME signing. Note that NONE OF THESE approaches offers
universal or even majority coverage of the global messaging corpus.

In the unlikely case that a content filtering implementation is sufficient
> for non-DMARC domains, it is likely to be sufficient for DMARC domains
> also, making DMARC unnecessary.
>

One need only look at spam folders to see that content filtering to see
that it does not provide a comprehensive solution. By your logic above,
perhaps we should jettison content filtering as a tool.

>
> The coverage problem is aggravated if we assume rational attackers.   With
> a plethora of domains available for impersonation, attackers are least
> likely to use domains that are protected with p=reject.  Therefore the
> reference model implementation protects an evaluator where attacks are
> least likely, and fails to protect an evaluator where attacks are most
> likely.
>

Again, you are asserting a "coverage problem" when none exists. If a
sending domain chooses not to participate in DMARC, that is a choice on
their part, not a problem. If a receiving domain chooses not to validate,
that is a choice, not a problem. Again, applying your logic as expressed
above, should we discard SMTP based messaging because organizations choose
to use other forms of messaging for their communications?


>
> Now consider the mailing list problem.
>
> The mailing list owner should assume that all evaluators will enforce
> DMARC according to the reference model, regardless of the receiving
> domain's published DMARC policy.   This means that every subscribing domain
> SHOULD create a DMARC exception for traffic coming from the list's MAILFROM
> address.
>

This does NOT mean that every subscribing domain should create an exception
for traffic coming from the list's MAILFROM address.


> However, we assume that this does not happen for one of these reasons:
> (a) the list owner does not ask for the exception,
> (b) the subscriber fails to forward the exception request,
> (c) the email system administrator refuses the request, or
> (d) the email filtering system provides no mechanism to implement the
> request.
>
> Then subscribers join from one or more domains with p=reject policy, and
> the problems start.   When a subscriber gets disenrolled because his domain
> enforces DMARC without exceptions, he screams at the mailing list operator,
> who then points his finger at the p=reject domain.  Alternatively, the
> domain gets munged and the subscribers fuss for that reason instead.  Faced
> with this peer pressure, the p=reject subscriber complains loudly to his
> mail system administrator.   In the hoped-for-case, the domain owner caves
> under this internal pressure and changes his DMARC policy to p=none.  One
> of the odd things about this result is that the characteristics of the
> incoming messages remain unchanged.  Instead, it is the risk tolerance that
> has been increased.
>

A list owner may choose not to accept subscriptions/messages from a domain
participating in DMARC and publishing p=reject.

>
> In the simpler solution, subscribers would accept impersonation from one
> account in one domain, so that both subscriber and non-subscriber domains
> are protected from impersonation attacks using the p=reject domain from any
> other source.   In the hoped-for solution, all Internet participants become
> vulnerable to impersonation attacks using the no-longer-reject 

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-09.txt

[Alessandro Vesely]

On Thu 14/Sep/2023 13:10:16 +0200 internet-drafts wrote:

Internet-Draft draft-ietf-dmarc-failure-reporting-09.txt is now available. It
is a work item of the Domain-based Message Authentication, Reporting &
Conformance (DMARC) WG of the IETF.

[...]

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-failure-reporting-09


Eh, when I look at that I see I'm not the only one having these problems...


Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Dotzero]

On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  wrote:

>
> All the best,
> Hector Santos
>
>
>
> On Sep 13, 2023, at 8:51 PM, Dotzero  wrote:
>
>
>
> On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  wrote:
>
>> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
>> Douglas Foster
>>
>> Absolutely incorrect. DMARC is a deterministic pass|fail approach based
>> on validation through DKIM or SPF pass (or if both pass). It says nothing
>> about the acceptability/goodness/badness of a source.
>>
>>
>> So why are we here?
>>
>
> Because you care?
>
>
> I do.
>
>
>> Correct or incorrect, a published p=reject has to mean something to the
>> verifier who is doing the domain a favor by a) implementing the protocol
>> and b) the goal of eliminating junk.   If there are false negatives, whose
>> fault is that?  The Domain, The Verifier or the Protocol?
>>
>
> DMARC does one thing and one thing only. It mitigates against direct
> domain abuse in a deterministic manner, nothing else. It doesn't stop spam
> and it doesn't depend on or involve reputation. It is but one tool among a
> number of tools that various parties can choose from. A message passing
> DMARC validation does not mean the message is "good". There is no question
> of fault. Perhaps you should recommend changes to incorporate a blame game
> if your goal is to determine fault.
>
>
> Deterministic means there is no question -  you follow the protocol. Your
> (speaking in general) opinions don’t matter.
>

It means that the output of the algorithm is deterministic. It does not
mean that the receiver blindly act on that output. As has been stated many
times by many people, a policy assertion is a request by the sending domain
administrator/owner, not a mandate. That is why local policy on the part of
the receiver overrides a sender policy assertion.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

[Alessandro Vesely]

On Sat 09/Sep/2023 20:16:04 +0200 Douglas Foster wrote:
Thus, if I get N messages from example.com , and the "pct" 
value is X, then the DMARC test is applied only to X% of that N; the simplest 
way to do this per-message would be to pick a random number between 0 and 1 and 
if it's greater than X%, the message simply bypasses DMARC altogether.



Drop "simplest":  /the way/ to do this is to pick up a random number between 0 
and 100 and if it's greater than X%, the message simply bypasses DMARC altogether.


My implementation:
if (vh.dmarc.pct != 100 && random() % 100 >= vh.dmarc.pct)
{
dispo = dispo_deliver;
if (parm->dyn.stats)
parm->dyn.stats->dmarc_reason = dmarc_reason_sampled_out;
...

See also:
https://en.wikipedia.org/wiki/Bernoulli_sampling

Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-09.txt

[internet-drafts]

Internet-Draft draft-ietf-dmarc-failure-reporting-09.txt is now available. It
is a work item of the Domain-based Message Authentication, Reporting &
Conformance (DMARC) WG of the IETF.

   Title:   Domain-based Message Authentication, Reporting, and Conformance 
(DMARC) Failure Reporting
   Authors: Steven M Jones
Alessandro Vesely
   Name:draft-ietf-dmarc-failure-reporting-09.txt
   Pages:   15
   Dates:   2023-09-14

Abstract:

   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) is a scalable mechanism by which a domain owner can request
   feedback about email messages using their domain in the From: address
   field.  This document describes "failure reports," or "failed message
   reports", which provide details about individual messages that failed
   to authenticate according to the DMARC mechanism.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-failure-reporting/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-failure-reporting-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc