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

[Michael Thomas <[e-mail]>]

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 
> <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" (seeSection 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 <[e-mail] 
> <mailto:[e-mail]>> 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.
>
>     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 <[e-mail]
>>     <mailto:[e-mail]>> 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
>>
>>         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
>>>         <[e-mail]
>>>         <mailto:[e-mail]>> 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
>>>             <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>
>>>                 On 1/25/21 8:44 AM, Todd Herr wrote:
>>>>                 On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas
>>>>                 <[e-mail] <mailto:[e-mail]>> 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?
>>>>
>>>                 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
>>>
>>>                 _______________________________________________
>>>                 dmarc mailing list
>>>                 [e-mail] <mailto:[e-mail]>
>>>                 https://www.ietf.org/mailman/listinfo/dmarc
>>>                 <https://www.ietf.org/mailman/listinfo/dmarc>
>>>
>>>             _______________________________________________
>>>             dmarc mailing list
>>>             [e-mail] <mailto:[e-mail]>
>>>             https://www.ietf.org/mailman/listinfo/dmarc
>>>             <https://www.ietf.org/mailman/listinfo/dmarc>
>>>
>>>
>>>
>>>         -- 
>>>         *Seth Blank*| VP, Standards and New Technologies
>>>         *e:*[e-mail] <mailto:[e-mail]>
>>>         *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.
>>>
>>
>>
>>     -- 
>>     *Seth Blank*| VP, Standards and New Technologies
>>     *e:*[e-mail] <mailto:[e-mail]>
>>     *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.
>>
>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:*[e-mail] <mailto:[e-mail]>
> *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.
>