Subject: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

From: "John R. Levine" <[email-masked]>
Date: 24 Jan 2021 21:29:35 -0500

I realized why the arguments about whether to require authentication on 
reports are pointless.

If you actually look at reports, for the most part the address sending the
report is not the recipient domain or anything like it.

For example, recent failure reports I got from solarwinds.com (yes, them) 
are about mail to cisp.co.za which was forwarded to spamexperts.com. 
Reports from seznam.cz are about mail to email.cz.  Reports from 
manthorp.com are about mail to streamingco.net.

Aggregate reports don't even include the recipient domains, and tell me 
about sending IPs some of which are mine but most of which are not as mail 
bounces around through mailing lists and forwarders, or spammers just send 
spam with my domain on the From line.

As we all know, bad guys are at least as good at authentication as good 
guys, probably better.  So if someone for some reason wanted to send me 
fake reports of either kind, they could send them with perfect DMARC 
alignment and they'd still be fake.  If they report spam with one of my 
domains on the From line, there's no way at all to tell whether those 
reports are real.  I can use heuristics to recognize mail my system 
actually sent that went through mailing lists I know about, but DKIM 
signing the reports wouldn't help.

So I suggest that we close tickets 98 and 99.  They don't identify a real 
problem, and if they did. they wouldn't fix it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Thomas <[email-masked]>
Date: Sun, 24 Jan 2021 18:53:24 -0800

On 1/24/21 6:29 PM, John R. Levine wrote:
> I realized why the arguments about whether to require authentication 
> on reports are pointless.
>
A blatant assertion. The onus of proof is with people who say we should 
accept information from unknown sources. Extraordinary claims require 
extraordinary evidence. I have been doing security related stuff for 
long enough to know that being humble in the face of adversaries is the 
most prudent course. State actors can get involved when they figure they 
can game things to their advantage. To be dismissive is complete hubris.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 24 Jan 2021 18:57:45 -0800

On 1/24/21 6:29 PM, John R. Levine wrote:
>
> As we all know, bad guys are at least as good at authentication as 
> good guys, probably better.

PS: if this were true, DKIM would be useless too.

Mike

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 08:25:23 -0500

> can game things to their advantage. To be dismissive is complete hubris.
I've spent several days thinking about these tickets, and for the life of
me I can't see what the payoff might be for someone to forge a DMARC report.

I suppose nominally there's a denial of service risk, where a bad actor
could flood a rua or ruf mailbox with forged reports or just email in
general, but that's going to exist whether or not the "reports" are
DKIM-signed.

My first question for aggregate reports would focus on the DKIM signing
domain - Should it align with the RFC5322.From domain that sent the report,
or with the org_name or email fields in the report_metadata bits in the XML
itself? John has demonstrated that there's no alignment now in many cases
between the domain generating reports and the domain(s) about which the
reports are generated. You almost have to require that the signing domain
align with the RFC5322.From domain, because DKIM validation is likely to be
done by different infrastructure than does the report processing (see
below) and the DKIM validation layer isn't likely to be able to read the
reports, while the report processing layer may be a simple tool that
doesn't care to do DKIM validation.

About that, aggregate reports are meant to be machine-parsed, and in my own
experience that's accomplished by running a cron job a couple times a day
to process the rua mailbox. (Personally, I favored Mark Overmeer's perl
stuff; open the mailbox, cycle through each message, strip off the
attachment, unzip it, and pass it to the tools that John wrote to read the
XML and store the results in a database, but I was working at a relatively
small site.) If the message isn't crafted specifically to match the format
mandated in the DMARC spec, it's not going to get processed; if the bad
actor takes the time to properly format an aggregate report and forge it to
appear to be from a given entity, what does the bad actor gain? If the
report contains data showing illegitimate mail that's not authenticating,
the target yawns. Best case for the bad guy, his report appears to contain
legit data showing that the target is sending email that isn't passing
authentication checks, and it causes someone at the target to try to chase
down a mailflow that isn't really there. And then what? The bad actor could
keep being a nuisance, but I suspect eventually he'd get bored, because
he's not going to have any visibility into the results of his actions.

As for forging failure reports, again what's in it for the actor doing the
forging? If the faked failure report is crafted to appear to contain
actionable data (something that's rare these days), the most likely
responses to that are one of the following:

   - In the case of the failure report appearing to show a message that
   forges domain A's identity and originated from a network run by B, maybe it
   fosters ill will between A and B's abuse desk, with A providing evidence of
   forged mail being emitted by B and asking B to take action, and B saying
   "not our problem"
   - In the case of the failure report appearing to show an unauthenticated
   message sent by A, again it's another case of someone at A trying to chase
   down and fix a phantom mail flow.

Unless our bad guy is playing a long game that I can't conceive of (and my
imagination can be limited) then I don't see that there's any money in it
for the bad guy, so I don't see why he'd bother to forge reports.

What threats do you have in mind, Michael?

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 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.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 07:17:56 -0800

On 1/25/21 5:25 AM, Todd Herr wrote:
> On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
> I've spent several days thinking about these tickets, and for the life 
> of me I can't see what the payoff might be for someone to forge a 
> DMARC report.
>
> I suppose nominally there's a denial of service risk, where a bad 
> actor could flood a rua or ruf mailbox with forged reports or just 
> email in general, but that's going to exist whether or not the 
> "reports" are DKIM-signed.

The main thing I've learned over the years of dealing with security is 
to not underestimate what a motivated attacker can do. Your imagination 
is not the same as their imagination. Closing #98 in particular is 
absolutely ridiculous: the report should already have a DKIM signature 
or SPF so it's just a matter of making sure its valid. Why would you 
*not* want to insure that? The amount of justification for *not* having 
the receiver authenticate it is a mountain. The amount of effort to 
authenticate it is trivial for mail. Levine's dismissal of security 
concerns because he has anecdotal "evidence" from a backwater domain 
carries no weight at all.

Mike

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 11:44:04 -0500

On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas <[email-masked]> wrote:

> The main thing I've learned over the years of dealing with security is to
> not underestimate what a motivated attacker can do. Your imagination is not
> the same as their imagination. Closing #98 in particular is absolutely
> ridiculous: the report should already have a DKIM signature or SPF so it's
> just a matter of making sure its valid. Why would you *not* want to insure
> that? The amount of justification for *not* having the receiver
> authenticate it is a mountain. The amount of effort to authenticate it is
> trivial for mail. Levine's dismissal of security concerns because he has
> anecdotal "evidence" from a backwater domain carries no weight at all.
>

That's all well and good, but you haven't answered the question I asked.

What threats do you have in mind? Put another way, how do you envision an
attacker exploiting the lack of authentication in a DMARC report to his or
her gain?

I recognize that my imagination, or yours, may not match what a motivated
attacker can do. I have presented some possible scenarios that might result
from a forged DMARC report, and in them I don't see a gain for the
attacker, unless his or her goal is to be an annoyance to the target.

Can you please describe a scenario where an attacker might use a forged
DMARC report to gain something of value from the target of his/her forgery?

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 08:51:39 -0800

On 1/25/21 8:44 AM, Todd Herr wrote:
> On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas <[email-masked] 
>     The main thing I've learned over the years of dealing with
>     security is to not underestimate what a motivated attacker can do.
>     Your imagination is not the same as their imagination. Closing #98
>     in particular is absolutely ridiculous: the report should already
>     have a DKIM signature or SPF so it's just a matter of making sure
>     its valid. Why would you *not* want to insure that? The amount of
>     justification for *not* having the receiver authenticate it is a
>     mountain. The amount of effort to authenticate it is trivial for
>     mail. Levine's dismissal of security concerns because he has
> What threats do you have in mind? Put another way, how do you envision 
> an attacker exploiting the lack of authentication in a DMARC report to 
> his or her gain?
>
No, sorry, the onus is on the people who don't think it can be gamed. A 
bald assertion that it can't be gamed is very unconvincing. You need to 
lay out a miles long case for why it cannot be gamed. And to what end? 
#98 has a simple piece of text that should be added to DMARC to 
eliminate the possibility of forgery. You'd need a 10 page threat I-D to 
explain why it's not necessary. What is the point of that? For email, 
it's trivial to prevent forgeries. Why would anybody argue against that?

Mike

---

From: Douglas Foster <[email-masked]>
Date: Mon, 25 Jan 2021 12:10:30 -0500

Since the status quo is unauthenticated, I wonder if adding a signing
requirement will help.
Will recipients discad unsigned messages, or accept whatever is available
to maximize their information capture?  I suspect they will conrinye to
accept everything.

I think we would need an identified threat before recipients would be
motivated to discard.

But what about John's problems with receiving reports that should not have
gone to him?   I did not understand the root cause, but I would hope there
is something that can be done.  Would signing help receiving sites, those
with less sophistication than he has, be able to sort out noise more
effectively?

On Mon, Jan 25, 2021, 11:51 AM Michael Thomas <[email-masked]> wrote:

> bald assertion that it can't be gamed is very unconvincing. You need to lay
> out a miles long case for why it cannot be gamed. And to what end? #98 has
> a simple piece of text that should be added to DMARC to eliminate the
> possibility of forgery. You'd need a 10 page threat I-D to explain why it's
> not necessary. What is the point of that? For email, it's trivial to
> prevent forgeries. Why would anybody argue against that?
>
> Mike
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 09:19:09 -0800

What operational problem are we solving here? Absent evidence of a problem
and strong consensus on the solution, let's close these tickets and move on.

On Mon, Jan 25, 2021 at 9:10 AM Douglas Foster <
[email-masked]> wrote:

>>> to not underestimate what a motivated attacker can do. Your imagination is
>>> not the same as their imagination. Closing #98 in particular is absolutely

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 09:21:59 -0800

Mike, this comment is unproductive and false.

It is well known that bad actors are the first and heartiest adopters of
authentication. This has been discussed with ample evidence for years. We
are not litigating this fact on this list.

Please stick to the merits of the discussion and bring operational evidence
to support your concern, or let's move on to another ticket.

Seth, as Chair

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 09:22:27 -0800

Taking in information from unauthenticated sources and acting on it is 
an operational problem per se. Have we learned nothing in the last 30 years?

Mike

On 1/25/21 9:19 AM, Seth Blank wrote:
> What operational problem are we solving here? Absent evidence of a 
> problem and strong consensus on the solution, let's close these 
> tickets and move on.
>
> On Mon, Jan 25, 2021 at 9:10 AM Douglas Foster 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Since the status quo is unauthenticated, I wonder if adding a
>     signing requirement will help.
>     Will recipients discad unsigned messages, or accept whatever is
>     available to maximize their information capture?  I suspect they
>     will conrinye to accept everything.
>
>     I think we would need an identified threat before recipients would
>     be motivated to discard.
>
>     But what about John's problems with receiving reports that should
>     not have gone to him?   I did not understand the root cause, but I
>     would hope there is something that can be done.  Would signing
>     help receiving sites, those with less sophistication than he has,
>     be able to sort out noise more effectively?
>
>
>     On Mon, Jan 25, 2021, 11:51 AM Michael Thomas <[email-masked]
>>         On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>             The main thing I've learned over the years of dealing
>>             with security is to not underestimate what a motivated
>>             attacker can do. Your imagination is not the same as
>>             their imagination. Closing #98 in particular is
>>             absolutely ridiculous: the report should already have a
>>             DKIM signature or SPF so it's just a matter of making
>>             sure its valid. Why would you *not* want to insure that?
>>             The amount of justification for *not* having the receiver
>>             authenticate it is a mountain. The amount of effort to
>>             authenticate it is trivial for mail. Levine's dismissal
>>             of security concerns because he has anecdotal "evidence"
>>             from a backwater domain carries no weight at all.
>>
>>
>>         What threats do you have in mind? Put another way, how do you
>>         envision an attacker exploiting the lack of authentication in
>>         a DMARC report to his or her gain?
>>
>         No, sorry, the onus is on the people who don't think it can be
>         gamed. A bald assertion that it can't be gamed is very
>         unconvincing. You need to lay out a miles long case for why it
>         cannot be gamed. And to what end? #98 has a simple piece of
>         text that should be added to DMARC to eliminate the
>         possibility of forgery. You'd need a 10 page threat I-D to
>         explain why it's not necessary. What is the point of that? For
>         email, it's trivial to prevent forgeries. Why would anybody
>         argue against that?
>
>         Mike
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/dmarc>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:[email-masked] <mailto:[email-masked]>
> *p:*415.273.8818
>
>
> 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.
>

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 09:25:14 -0800

Mike, how do you believe DMARC reports are consumed and utilized? I think
you have a misunderstanding here which is why you're going down this path
and everyone else is pushing back.

On Mon, Jan 25, 2021 at 9:22 AM Michael Thomas <[email-masked]> wrote:

> Taking in information from unauthenticated sources and acting on it is an
> operational problem per se. Have we learned nothing in the last 30 years?
>
> Mike
>> But what about John's problems with receiving reports that should not
>> have gone to him?   I did not understand the root cause, but I would hope
>> there is something that can be done.  Would signing help receiving sites,
>> those with less sophistication than he has, be able to sort out noise more
>> effectively?
>>
>>
>>> an attacker exploiting the lack of authentication in a DMARC report to his
>>> or her gain?
>>>

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 09:32:01 -0800

Why is this controversial? Seriously. What is controversial about saying 
that the a report should authenticate? The onus is on the people who say 
it does not to lay out the case for why it's not a problem, not me. #98 
has a simple piece of text to remedy this. it's 2021. You don't use 
unauthenticated data if you can possibly help it.

Mike

On 1/25/21 9:25 AM, Seth Blank wrote:
> Mike, how do you believe DMARC reports are consumed and utilized? I 
> think you have a misunderstanding here which is why you're going down 
> this path and everyone else is pushing back.
>
> On Mon, Jan 25, 2021 at 9:22 AM Michael Thomas <[email-masked] 
>     Taking in information from unauthenticated sources and acting on
>     it is an operational problem per se. Have we learned nothing in
>     the last 30 years?
>
>     Mike
>
>>     What operational problem are we solving here? Absent evidence of
>>     a problem and strong consensus on the solution, let's close these
>>     tickets and move on.
>>
>>         Will recipients discad unsigned messages, or accept whatever
>>         is available to maximize their information capture?  I
>>         suspect they will conrinye to accept everything.
>>
>>         I think we would need an identified threat before recipients
>>         would be motivated to discard.
>>
>>         But what about John's problems with receiving reports that
>>         should not have gone to him?   I did not understand the root
>>         cause, but I would hope there is something that can be done.
>>         Would signing help receiving sites, those with less
>>         sophistication than he has, be able to sort out noise more
>>         effectively?
>>
>>
>>>                 The main thing I've learned over the years of
>>>                 dealing with security is to not underestimate what a
>>>                 motivated attacker can do. Your imagination is not
>>>                 the same as their imagination. Closing #98 in
>>>                 particular is absolutely ridiculous: the report
>>>                 should already have a DKIM signature or SPF so it's
>>>                 just a matter of making sure its valid. Why would
>>>                 you *not* want to insure that? The amount of
>>>                 justification for *not* having the receiver
>>>                 authenticate it is a mountain. The amount of effort
>>>                 to authenticate it is trivial for mail. Levine's
>>>                 dismissal of security concerns because he has
>>>             What threats do you have in mind? Put another way, how
>>>             do you envision an attacker exploiting the lack of
>>>             authentication in a DMARC report to his or her gain?
>>>
>>             No, sorry, the onus is on the people who don't think it
>>             can be gamed. A bald assertion that it can't be gamed is
>>             very unconvincing. You need to lay out a miles long case
>>             for why it cannot be gamed. And to what end? #98 has a
>>             simple piece of text that should be added to DMARC to
>>             eliminate the possibility of forgery. You'd need a 10
>>             page threat I-D to explain why it's not necessary. What
>>             is the point of that? For email, it's trivial to prevent
>>             forgeries. Why would anybody argue against that?
>>
>>             Mike
>>
>>     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.
>>
>
>
> --

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Jan 2021 09:38:45 -0800

On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <[email-masked]> wrote:

> that the a report should authenticate? The onus is on the people who say it
> does not to lay out the case for why it's not a problem, not me. #98 has a
> simple piece of text to remedy this. it's 2021. You don't use
I'm not taking a position at this point on the issue, but I think you
should expect that this will come up in external reviews.  If consensus is
to maintain the status quo, we might want to say so explicitly (and why)
rather than saying nothing, as the latter might be interpreted as it having
gotten no consideration at all.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 09:40:22 -0800

Michael, as an individual, I don't disagree. What's not clear about the
current text?

https://tools.ietf.org/html/rfc7489#section-7.2.1.1

   Email streams carrying DMARC feedback data MUST conform to the DMARC
   mechanism, thereby resulting in an aligned "pass" (see Section 3.1
<https://tools.ietf.org/html/rfc7489#section-3.1>).
   This practice minimizes the risk of report consumers processing
   fraudulent reports.

On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <[email-masked]> wrote:

>> problem and strong consensus on the solution, let's close these tickets and
>> move on.
>>
>>> available to maximize their information capture?  I suspect they will
>>> conrinye to accept everything.
>>>

--

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 09:41:11 -0800

Realized I think we're going in circles. Just posted text that is status
quo that I believe already addresses Michael's concern.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 09:48:37 -0800

That text is not very clear to say the least. It's written in a very 
passive voice. What is wrong with the text I provided? It should be made 
very explicit like I did with what the responsibility of the sender and 
receiver is.

Mike

On 1/25/21 9:40 AM, Seth Blank wrote:
> Michael, as an individual, I don't disagree. What's not clear about 
> the current text?
>
> <https://tools.ietf.org/html/rfc7489#section-7.2.1.1>
>
>     mechanism, thereby resulting in an aligned "pass" (seeSection 3.1  <https://tools.ietf.org/html/rfc7489#section-3.1>).
> On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <[email-masked] 
>     Why is this controversial? Seriously. What is controversial about
>     saying that the a report should authenticate? The onus is on the
>     people who say it does not to lay out the case for why it's not a
>     problem, not me. #98 has a simple piece of text to remedy this.
>     it's 2021. You don't use unauthenticated data if you can possibly
>     help it.
>
>     Mike
>
>>     Mike, how do you believe DMARC reports are consumed and utilized?
>>     I think you have a misunderstanding here which is why you're
>>     going down this path and everyone else is pushing back.
>>
>>         Taking in information from unauthenticated sources and acting
>>         on it is an operational problem per se. Have we learned
>>         nothing in the last 30 years?
>>
>>         Mike
>>
>>>         What operational problem are we solving here? Absent
>>>         evidence of a problem and strong consensus on the solution,
>>>         let's close these tickets and move on.
>>>
>>>             Since the status quo is unauthenticated, I wonder if
>>>             adding a signing requirement will help.
>>>             Will recipients discad unsigned messages, or accept
>>>             whatever is available to maximize their information
>>>             capture?  I suspect they will conrinye to accept everything.
>>>
>>>             I think we would need an identified threat before
>>>             recipients would be motivated to discard.
>>>
>>>             But what about John's problems with receiving reports
>>>             that should not have gone to him?   I did not understand
>>>             the root cause, but I would hope there is something that
>>>             can be done. Would signing help receiving sites, those
>>>             with less sophistication than he has, be able to sort
>>>             out noise more effectively?
>>>
>>>
>>>             On Mon, Jan 25, 2021, 11:51 AM Michael Thomas
>>>>                     dealing with security is to not underestimate
>>>>                     what a motivated attacker can do. Your
>>>>                     imagination is not the same as their
>>>>                     imagination. Closing #98 in particular is
>>>>                     absolutely ridiculous: the report should
>>>>                     already have a DKIM signature or SPF so it's
>>>>                     just a matter of making sure its valid. Why
>>>>                     would you *not* want to insure that? The amount
>>>>                     of justification for *not* having the receiver
>>>>                     authenticate it is a mountain. The amount of
>>>>                     effort to authenticate it is trivial for mail.
>>>>                     Levine's dismissal of security concerns because
>>>>                     he has anecdotal "evidence" from a backwater
>>>>                     domain carries no weight at all.
>>>>
>>>>
>>>>                 What threats do you have in mind? Put another way,
>>>>                 how do you envision an attacker exploiting the lack
>>>>                 of authentication in a DMARC report to his or her gain?
>>>>
>>>                 No, sorry, the onus is on the people who don't think
>>>                 it can be gamed. A bald assertion that it can't be
>>>                 gamed is very unconvincing. You need to lay out a
>>>                 miles long case for why it cannot be gamed. And to
>>>                 what end? #98 has a simple piece of text that should
>>>                 be added to DMARC to eliminate the possibility of
>>>                 forgery. You'd need a 10 page threat I-D to explain
>>>                 why it's not necessary. What is the point of that?
>>>                 For email, it's trivial to prevent forgeries. Why
>>>                 would anybody argue against that?
>>>
>>>                 Mike
>>>
>>>         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.
>>>
>>
>>
>>     --

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 09:53:33 -0800

But just as an example, suppose I'm trying to get to a position to use 
p=reject, but some bad actor doesn't want me to do that so they can keep 
phishing me. All they have to do is keep sending forged message reports 
from gmail which makes me think I've got a problem. Seriously, this is 
not rocket science.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 10:00:46 -0800

Issue #99 would need to be resolved if you want to use https as well. 
That's really why I brought up the entire issue. It's an easy fix for 
email, and not obvious how you fix it for https.

Mike

On 1/25/21 9:41 AM, Seth Blank wrote:
> Realized I think we're going in circles. Just posted text that is 
> status quo that I believe already addresses Michael's concern.
>
> On Mon, Jan 25, 2021 at 9:38 AM Murray S. Kucherawy 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Why is this controversial? Seriously. What is controversial
>         about saying that the a report should authenticate? The onus
>         is on the people who say it does not to lay out the case for
>         why it's not a problem, not me. #98 has a simple piece of text
>         to remedy this. it's 2021. You don't use unauthenticated data
>         if you can possibly help it.
>
>     I'm not taking a position at this point on the issue, but I think
>     you should expect that this will come up in external reviews.  If
>     consensus is to maintain the status quo, we might want to say so
>     explicitly (and why) rather than saying nothing, as the latter
>     might be interpreted as it having gotten no consideration at all.
>
>     -MSK
>
>
>
> --

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 10:02:13 -0800

Michael, are you aware of anyone not following the guidance in the
document? This thread feels like we're discussing a non-issue. Aggregate
reports are already required to be authenticated and I'm unaware of anyone
sending failure reports, let along unauthenticated ones. Is the language
causing problems? Such problems have not been brought to the list, and
would be a good place to start if you want to build consensus.

The list seems to be digging in because no one has raised a use case that
shows a need to revisit the text. This was made worse by asserting that
reports must be authenticated, when the text already makes that clear.

It is likely in scope to discuss if the current text needs to be moved from
7.2.1.1 to 7.1, but let's please be careful to focus on operational
feedback and not personal opinions.

To be exceedingly clear: if this thread doesn't focus and come to
consensus quickly, then ticket #98 should be closed, unless a use case is
raised and supported by operational parties, that there is an issue here
requiring further clarification.

Ticket 99 is still in play, if and only if we decide on adding an HTTPS
transport for DMARC reports, of which historical consensus shows this is
unlikely. Let's press pause on that until the other discussion is
concluded, please.

Seth, as chair

--

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 13:05:24 -0500

On Mon, Jan 25, 2021 at 12:53 PM Michael Thomas <[email-masked]> wrote:

> from gmail which makes me think I've got a problem. Seriously, this is not
> rocket science.
>
>
>
Thank you for answering my question.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 10:10:38 -0800

On 1/25/21 10:02 AM, Seth Blank wrote:
> document? This thread feels like we're discussing a non-issue. 
> Aggregate reports are already required to be authenticated and I'm 
> unaware of anyone sending failure reports, let along unauthenticated 
> ones. Is the language causing problems? Such problems have not been 
> brought to the list, and would be a good place to start if you want to 
> build consensus.
>
> The list seems to be digging in because no one has raised a use case 
> that shows a need to revisit the text. This was made worse by 
> asserting that reports must be authenticated, when the text already 
> makes that clear.

Obviously it isn't that clear. I looked for it and didn't find it. 
Several people just asserted that it wasn't a problem instead of 
pointing at the relevant text requiring it. Murray didn't seem to know 
about it either. That tells me that the current text is not specific enough.

> Ticket 99 is still in play, if and only if we decide on adding an 
> HTTPS transport for DMARC reports, of which historical consensus shows 
> this is unlikely. Let's press pause on that until the other discussion 
> is concluded, please.
>
This entire thread was by way of John Levine's proposing text for http 
and me responding about how to authenticate it. If you have a problem 
with that, take it up with him.

Mike

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 13:23:49 -0500

>reports must be authenticated, when the text already makes that clear.

I think the use case is my proposed https reporting. If you think it
would be useful to allow domain authentication, it's easy enough to
say that the client SHOULD send a client certificate. Nobody will, but
every https server and client library I know supports client certs so
it's not hard to implement.

I continue to believe that authenticating the domain sending reports
is of no value, since there is no way to tell what if any connection
that domain has to the IPs in an aggregate report or the IPs or
domains in a failure report. If I wanted to send fake gmail failure
reports, I would register gmail-reports.com and send 100% perfectly
aligned fake reports from that domain.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 10:28:55 -0800

> it's not hard to implement.

Which means that is done completely in bad faith. No thanks.

> aligned fake reports from that domain.
I send mail to gmail. I send no mail to gmail-reports. If anything you 
are demonstrating even further that this is at best underspecified.

Mike

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 13:47:55 -0500

>are demonstrating even further that this is at best underspecified.

Hi, Mike. When Google sends aggregate reports, what address do you
think they send them from? It should be easy enough to look at some of
the reports you've gotten and check.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Mon, 25 Jan 2021 13:55:12 -0500

DMARC alignment on the report seems of limited value unless it is aligned
to the domain being reported.  But that change would require every unique
domain to generate a unique report.   Gsuite and Office365 would probably
consider that unacceptable.

On Mon, Jan 25, 2021, 1:29 PM Michael Thomas <[email-masked]> wrote:

> that

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 11:02:03 -0800

On 1/25/21 10:55 AM, Douglas Foster wrote:
> DMARC alignment on the report seems of limited value unless it is 
> aligned to the domain being reported.  But that change would require 
> every unique domain to generate a unique report.   Gsuite and 
> Office365 would probably consider that unacceptable.
>
Google already has my signing keys. This is an implementation detail on 
their part. If they want to host a domain, they should host a domain. 
Laziness is not an excuse for spoofing.

Mike

---

From: Douglas Foster <[email-masked]>
Date: Mon, 25 Jan 2021 14:41:43 -0500

So if a newsletter goes to 10,000 Gsuite domains, Google sends 10,000
reports instead of just one?   I don't think either Google or the
newsletter domain would consider that an improvement.   But perhaps they
will speak for themselves.

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 14:52:31 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-
>to the domain being reported. ...

I'm getting the impression that some of us have not looked at any DMARC reports.

Aggregate reports contain the domain of the reporter, and the domain
of the sender to whom they are sending the report. They do NOT have
the domains to which the messages were sent or where they were
received, which are often different for forwarded or mailing list mail.

For at least the third time, there is no "domain being reported". When
I get reports from Google or any other multi-tenant mail provider,
they do not say to which of their gazillion hosted domains the mail
was sent. That is not a bug, and it's been like that for a decade. 

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 11:55:35 -0800

> was sent. That is not a bug, and it's been like that for a decade.
Sounds like a bug to me and an issue should be opened. Just because it's 
a 10 year old bug doesn't mean it's not a bug.

Mike

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 15:08:21 -0500

On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas <[email-masked]> wrote:

> > In article <
> [email-masked]> you
> write:
> >> -=-=-=-=-=-
> >>
> aligned
I disagree.

Authentication results should not differ at a given provider based solely
on the destination domain, so there is no reason to report results
separately for each destination domain. Further, there's no value to the
report generators, especially at large sites like Google, to expend the
resources necessary to generate and send X reports when one will do.

--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 12:18:11 -0800

On 1/25/21 12:08 PM, Todd Herr wrote:
> On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas <[email-masked] 
>     > In article
>     <[email-masked]
>     <mailto:[email-masked]>>
>     you write:
>     >> -=-=-=-=-=-
>     >>
> Authentication results should not differ at a given provider based 
> solely on the destination domain, so there is no reason to report 
> results separately for each destination domain. Further, there's no 
> value to the report generators, especially at large sites like Google, 
> to expend the resources necessary to generate and send X reports when 
> one will do.
>
So you're saying I should be free to spoof any domain I want because 
Google might be inconvenienced?

Mike

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 21:24:10 +0100

On Mon 25/Jan/2021 14:25:23 +0100 Todd Herr wrote:
> experience that's accomplished by running a cron job a couple times a day to 
> process the rua mailbox. (Personally, I favored Mark Overmeer's perl stuff; 
> open the mailbox, cycle through each message, strip off the attachment, unzip 
> it, and pass it to the tools that John wrote to read the XML and store the 
> results in a database, but I was working at a relatively small site.)

For a counter example, I read aggregate reports one by one, if at all.  They 
get an automated HTML rendering that makes it easy to see success at a glance, 
and the mail site is small enough that I can afford doing so.  Authentication 
status is visible at a glance too, so I can judge the report's merit.

IMHO, reports SHOULD be authenticated.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 21:27:38 +0100

On Mon 25/Jan/2021 19:02:13 +0100 Seth Blank wrote:
> 7.2.1.1 to 7.1, but let's please be careful to focus on operational feedback 
> and not personal opinions.

I'd leave the MUST in 7.2.1.1.  If moved to 7.1 it should become a SHOULD.

Indeed, it can become a SHOULD anyway.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 21:39:05 +0100

On Mon 25/Jan/2021 20:52:31 +0100 John Levine wrote:
> [...]

Yet, an unauthenticated report from Google would prick up your ears.

DMARC authentication is a good thing.

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 12:41:35 -0800

> brought to the list, and would be a good place to start if you want to 

 From the looks of it, it doesn't seem like the security requirements of 
reporting was ever undertaken. There seems to be a wide range of 
disagreement even if there was given the thread from which this came. 
 From there is actually text, to don't know if it's an issue, to there 
hasn't been a problem before (as if that were some sort of barometer), 
to authentication might inconvenience google, to contradicting your 
assertion that authentication in the way you mentioned can be done. 
Since this is going to proposed standard from informational, that is not 
a very good state of affairs, IMO.

Mike

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 12:47:24 -0800

Entire sections of the document are devoted to preventing reporting abuse.
Of course reviewing the security recommendations are part of the process of
going standards track which we’ll be undertaking.

If there are seeing specific operational issues that you believe require
clarification in the document, please speak up.

Back to open tickets, please.

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2021 15:47:52 -0500

> Yet, an unauthenticated report from Google would prick up your ears.

How about an authenticated report from google-reports.com ?

R's,
John

PS: this is getting awfully repetitive

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 13:06:14 -0800

On 1/25/21 12:47 PM, Seth Blank wrote:
> Entire sections of the document are devoted to preventing reporting 
> abuse. Of course reviewing the security recommendations are part of 
> the process of going standards track which we’ll be undertaking.

As I said, it doesn't appear that there is a whole lot of agreement of 
what the requirements are. Getting a DISCUSS from a security AD is not 
usually the best time to deal with security issues.

Mike

>
> If there are seeing specific operational issues that you believe 
> require clarification in the document, please speak up.
>
> On Mon, Jan 25, 2021 at 12:41 Michael Thomas <[email-masked]

---

From: Todd Herr <[email-masked]>
Date: Mon, 25 Jan 2021 16:25:14 -0500

On Mon, Jan 25, 2021 at 3:18 PM Michael Thomas <[email-masked]> wrote:

> I'm not at all following your point here. Let me explain what I'm trying
to say, then perhaps you can explain what you're trying to say in a way
that might make a dent in my seemingly-addled brain, and then we can move
forward.

As a domain owner who publishes a DMARC policy record, a DMARC aggregate
report tells me the results of authentication checks done by a given
reporter for mail claiming to be from my domain during a specified period
of time. These aggregate reports group the information by source IP,
telling me how many messages were seen from a given IP by that reporter,
what the policy evaluation results were, what the header from was, and what
the results of the "pure" authentication checks were.

If I were an owner of a domain of any reasonable size generating
non-trivial amounts of traffic on a daily basis, I would expect that some
of the traffic in a given aggregate report was stuff I'd sent, and some
would be stuff others had sent.

When it comes to a hosting provider, such as Google or any provider hosting
more than one domain, I do not expect that the authentication results
reported by the hosting provider about my domain will differ based on the
domain hosted by that provider to which the traffic was sent. If Google
reported mail from foo.com (my domain), I would expect that all mail I sent
from a given IP would show the same authentication results regardless of
whether it was sent to bar.org, baz.net, someotherdomain.com, whatever
domains Google might be hosting. I would further expect that any mail that
I didn't send would show in the report as failing authentication checks
(assuming I've got my authentication stuff set up correctly) regardless of
what domain it was sent to at Google.

The reasons for these expectations are several:

   1. SPF checks are based on the domain in the RFC5321.MailFrom header, or
   sometimes on the domain in the RFC5321.HELO; the destination domain has
   nothing to do with the success or failure of SPF
   2. DKIM checks are based on the DKIM-Signature header(s) in the message;
   the destination domain for the message has no role in the DKIM validation
   effort, as the public key is published by the signer
   3. DMARC checks are based on the From domain (which publishes the DMARC
   policy) and the results of the SPF and DKIM checks (did either pass, and
   does the domain that passed align with the From domain?). Again,
   destination domain doesn't play a role in the DMARC check

So, based on my understanding of how DMARC works and the information that
an aggregate report contains, I do not see how the lack of the destination
domain in an aggregate report gives one freedom to spoof any domain.

Can you please explain your position that the lack of destination domains
in aggregate reports gives one freedom to spoof any domain, and further can
you please specify which domain(s) in this scenario might be free to be
spoofed?

--

---

From: Steven M Jones <[email-masked]>
Date: Mon, 25 Jan 2021 13:26:37 -0800

On 1/25/21 12:18 PM, Michael Thomas wrote:
>> value to the report generators, especially at large sites like 
>> Google, to expend the resources necessary to generate and send X 
>> reports when one will do.
>>

If the language in 7.2.1.1 that Seth cited is "working," then report 
generators are sending reports that pass DMARC and the report receivers 
are validating that before ingesting the attached reports. However this 
only provides some degree of attribution for the report itself...

We can certainly check with report receivers to confirm that they are 
doing that validation, and perhaps get some measure of how often they 
see reports that don't pass. What does that leave us with?

Assuming 7.2.1.1 "works," reports that don't pass DMARC won't be 
processed, and won't cause the confusion and/or delayed implementation 
you cited as the potential harm.

That leaves reports that pass DMARC, sent from domains that haven't 
actually handled the sending domain's email. This sounds to me like 
reports that contain false data. Reports containing false data are 
identified as a security consideration in RFC7489 Section 12.2, without 
a reference to 7.2.1.1 as the suggested mitigation.

I don't see where additional authentication of the report itself can 
address this concern, given the availability of disposable domains. That 
leaves report receivers with the need to track report senders' 
reputation, which might warrant a mention in the revised spec.

What did I miss?

--S.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Jan 2021 13:51:55 -0800

On 1/25/21 1:26 PM, Steven M Jones wrote:
> generators are sending reports that pass DMARC and the report 
> receivers are validating that before ingesting the attached reports. 
> However this only provides some degree of attribution for the report 
> itself...
>
Yes, if that were enforced that would solve the problem. Given the 
confusion my guess that it is not. That paragraph could be a lot more 
specific about the mechanisms and motivations which I suggested in #98. 
It probably requires even more than my suggestion after seeing all of 
the list traffic going by. If gsuite is aggregating reports from all of 
their domains they host into one report, there is clearly a problem both 
with the text and with implementations.

And of course, any proposed http method would have to provide equivalent 
protection.

Mike

---

From: Seth Blank <[email-masked]>
Date: Mon, 25 Jan 2021 13:59:11 -0800

This thread is now counterproductive and needs to come to a close.

Michael, your continued assertion has been that unauthenticated reports are
an issue. But so far no evidence has been presented that reports are sent
without authentication, or that the text of the document is the cause.

This thread is going in circles. It's now official CLOSED, unless someone
returns with evidence of an actual problem here.

Move on to other tickets.

Seth, as Chair

On Mon, Jan 25, 2021 at 1:55 PM Michael Thomas <[email-masked]> wrote:

> generators are sending reports that pass DMARC and the report receivers are
> validating that before ingesting the attached reports. However this only
> provides some degree of attribution for the report itself...
>
> specific about the mechanisms and motivations which I suggested in #98. It
> probably requires even more than my suggestion after seeing all of the list
> traffic going by. If gsuite is aggregating reports from all of their
> domains they host into one report, there is clearly a problem both with the
> text and with implementations.
>

--