Yes, Neil, that is what I thought was communicated by my initial language. Security Considerations are topics that implementers and administrators should give consideration when making risk-based decisions, and this is one that seemed worthy of mention. Since others concluded that I was asserting many other things, perhaps someone else can propose language that is more acceptable to the group.
Doug Foster On Thu, Nov 24, 2022 at 3:29 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote: > > > On Nov 15, 2022, at 7:11 PM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > > General: > For a reporting specification, the Security Considerations are by > definition any risks of unwanted information disclosures. So that is > where attention needs to be given. > > Operational experience: > I don't have specific knowledge of the information gathering strategies of > malicious actors. > > When evaluating my reports, I noted that some sources were reporting > significantly fewer messages than were sent out. I have specific knowledge > about one of those vendors. They offer different filtering products to > different clients, and they allow clients to choose whether DMARC is > evaluated or not. > > So this is what I concluded from that knowledge: > > If a server farm hosts DomainA and DomainB, and I only get DMARC aggregate > reports when I send to DomainA, then I can conclude that DomainB is not > evaluating DMARC and is therefore more vulnerable to impersonation attacks > than DomainA. > > I think that knowledge is valuable to bad guys, so I think it is worth a > warning in our spec. > > The problem with this warning is that if people act on it, the volume of > reporting might decrease noticeably. > > > How about framing the warning in the direction of a best practice of > implementing for domain B which is inherently a good idea and denies > utility of these sort of DMARC probes trolling cyberspace for > vulnerabilities of this sort. The clear recommendation should be implement > DMARC for all of your domains. Don’t leave holes for probes to find. Dmarc, > especially starting with a monitoring only policy isn’t a big ask. > > > > > > > > On Tue, Nov 15, 2022 at 7:51 PM Seth Blank <s...@valimail.com> wrote: > >> On Tue, Nov 15, 2022 at 4:13 AM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> You failed to read and understand what I wrote. >>> >> >> Hatless, I also cannot parse your proposed text or what you're trying to >> communicate in this email. >> >> As Chair, our charter around the bis project is clear, and is to >> prioritize "issues based on operational experience and/or data aggregated >> from multiple sources." Along with any clearer proposed text, can you >> please share the operational experience and data aggregated from multiple >> sources which informs this security consideration so that we can prioritize >> this accordingly? >> >> Thanks, >> >> Seth >> >> -- >> >> *Seth Blank * | Chief Technology Officer >> *e:* s...@valimail.com >> *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 > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
