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]>]

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.
>