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

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, t

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

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 extraordinar

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

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 ___ dmarc mailing list dmarc@ietf.org https://www.ie

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

On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas wrote: > > 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 informa

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

On 1/25/21 5:25 AM, Todd Herr wrote: On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas > wrote: 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 as

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

On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas wrote: > > On 1/25/21 5:25 AM, Todd Herr wrote: > > On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas wrote: > >> >> On 1/24/21 6:29 PM, John R. Levine wrote: >> > I realized why the arguments about whether to require authentication >> > on reports ar

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

On 1/25/21 8:44 AM, Todd Herr wrote: On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas > 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 thei

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

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 thre

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

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 < dougfoster.emailstanda...@gmail.com> wrote: > Since the status quo is unauthenticated, I wonder

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

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 operat

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

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

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

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 wrote: > Taking in information from unauthenticated sources and ac

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

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 unauthent

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

On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas 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 piec

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

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

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

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 wrote: > On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas wrote: > >> Why is this controversial? Seriously. What is

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

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 individu

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

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 rock

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

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

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

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 pro

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

On Mon, Jan 25, 2021 at 12:53 PM Michael Thomas wrote: > 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 m

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

On 1/25/21 10:02 AM, Seth Blank wrote: 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 unau

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

>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. I think the use case is my proposed https reporting. If you think it would be

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

On 1/25/21 10:23 AM, John Levine wrote: 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. I think the use case is my proposed h

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

In article you write: >> 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 fa

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

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 wr

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

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.

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

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. On Mon, Jan 25, 2021, 2:02 PM Michael Thomas wrote: > > On 1

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

In article you write: >-=-=-=-=-=- > >DMARC alignment on the report seems of limited value unless it is aligned >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 domai

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

On 1/25/21 11:52 AM, John Levine wrote: In article you write: -=-=-=-=-=- DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. ... I'm getting the impression that some of us have not looked at any DMARC reports. Aggregate reports contain

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

On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas wrote: > > On 1/25/21 11:52 AM, John Levine wrote: > > In article < > cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq+...@mail.gmail.com> you > write: > >> -=-=-=-=-=- > >> > >> DMARC alignment on the report seems of limited value unless it is > alig

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

On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: On 1/25/21 11:52 AM, John Levine wrote: > In article mailto:cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq%2b...@mail.gmail.com>> you write: >> -=-=-=-=-=-

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

On Mon 25/Jan/2021 14:25:23 +0100 Todd Herr wrote: 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 mailbo

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

On Mon 25/Jan/2021 19:02:13 +0100 Seth Blank wrote: 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. I'd leave the MUST in 7.2.1.1. If moved to 7.1 it should bec

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

On Mon 25/Jan/2021 20:52:31 +0100 John Levine wrote: In article you write: DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. ... [...] For at least the third time, there is no "domain being reported". When I get reports from Google or a

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

On Mon, 25 Jan 2021, Alessandro Vesely wrote: 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 li

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

On Mon, Jan 25, 2021 at 3:18 PM Michael Thomas wrote: > > On 1/25/21 12:08 PM, Todd Herr wrote: > > On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas wrote: > >> >> On 1/25/21 11:52 AM, John Levine wrote: >> > In article < >> cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq+...@mail.gmail.com> you >

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

On 1/25/21 12:18 PM, Michael Thomas wrote: On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: 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.

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

On 1/25/21 1:26 PM, Steven M Jones wrote: On 1/25/21 12:18 PM, Michael Thomas wrote: On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: Sounds like a bug to me and an issue should be opened. Just because it's a 10

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

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 thre