No, Scott. We do not get angry at white-hat researchers. We try to learn from them before the black-hat researchers learn to do the same and begin deployment.
Ale's message was a very impressive fake, and it obviously did not take nation-state resources to produce it. This is alarming. Among the problems: 1) I thought IETF had best practices for secure list management. On my original account, I would get a challenge-response sequence. After every post, I would get a "did you send this message". I never knew for sure what made it go away, but it did. Was it DMARC-related? Was it participation-related? Or was it because my old account used a MailFrom address with the Barracuda version of BATV? Whatever the reason, it becomes clear that IETF does not protect us from impersonated posts. 2) As Wei Chang reminded us recently, SPF is vulnerable to a shared-tenancy attack. With huge hosting service like Outlook.com and Gsuite, SPF is a very weak form of authentication unless the hosting service can prevent tenants from impersonating each other. Of course, if the hosting service allows forwarding without MailFrom rewrite, they may not be able to protect against the shared-tenancy attack disguised as a forward. 3) The Authentication-Results header mislead when used outside of the organization that creates it, so those headers are supposed to be discarded upon entry to a new organization. This clearly was not done. IETF did not strip the Microsoft results, and Google did not strip the IETF results. 4) The Microsoft ARC set indicates that the message produced SPF PASS, but it does not tell us the IP address which was tested. When I check SPF on the combination of "comcast.com" and the previous Recevied address of (2603:10b6:208:193::31), I get SPF FAIL, not SPF PASS. The only other earlier received entry was fe80::5acd:7431:27b0:8d40, which I think is also a IPV6 private IP. So Ale's deception appears to be aggravated by Microsoft's deception. 5) IETF does not document the From and MailFrom addresses that it saw before it performed rewrite on both, so I don't know what identifiers IETF saw, which means that I don't understand how the attack was accomplished or why IETF was duped. 6) Apparently the headers prior to "tana.it" were fraudulent, having been inserted from an actual message received previously. They effectively confuse the question of where did the message originate. Did IETF trust information in those fake headers, or are they merely there to confuse human readers like me? 7) Is this attack unique to mailing lists, or is it symptomatic of a bunch of other vulnerabilities that can occur with header manipulation. In short, I want to know how to defend this attack because defending against attacks is my job. Pretending that it will not happen in the real world does not work for me. Doug Foster On Thu, Apr 6, 2023 at 12:54 PM Brotman, Alex <Alex_Brotman= 40comcast....@dmarc.ietf.org> wrote: > I hope Alex won't get offended by this innocent DMARC test. > > Are we sure that it is all right for mailing lists to allow spoofs and > impersonation? I don't think Comcast has p=reject to safeguard Alex's > contribution to this list, but what if he can't stand being impersonated? > What > else is he supposed to do besides setting p=reject? > > THIS LIST TAKES ALL OF THE BAD OF DMARC, NONE OF THE GOOD. > > Best > Ale > > > > _______________________________________________ > 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
