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