I've tried to roll up the guidance in this thread in the results below. -Wei
===== 11.9 Quarantined Forwarded Mail Security Risk When receivers apply the "MUST NOT reject" in Section 8.6 to accept unauthenticated messages as quarantined messages, receivers ought to carefully review how they forward mail traffic to prevent additional security risk. The forwarded mail might be able to obtain SPF or DKIM authentication through the receiver, and thereby obtain a fraudulent DMARC aligned From despite having an associated strong DMARC policy of "p=reject". For SPF, a malicious sender needs two properties to perform such a SPF attack: 1) a receiver that will forward quarantined messages, and 2) the spammer finds a SPF policy that covers the forwarding IPs. Such a sender crafts a message with From header assuming the identity of the domain with the SPF policy and matching MAIL FROM. Consequently the receiver evaluates message authentication and finds that the MAIL FROM does not authenticate but does not reject the message and instead quarantines it. Vulnerable receivers then forward the message to some subsequent receiver with the message taking the authenticated identity of the From header. That forwarding might be under control of the malicious sender perhaps via auto-forwarding or enterprise policy. Receivers need to consider restricting forwarding when the message is SPF unauthenticated. For DKIM, a malicious sender finds a forwarder that re-signs messages with DKIM that lets some malicious email take the identity of the DKIM signer domain. Some forwarders appear to do this for all messages. Other forwarders might do this when the message is modified such as mailing-lists. As with the SPF attack, the malicious sender may be able to create a message with some From header corresponding to the spoofed re-signing domain to obtain DMARC alignment at the receiver. Forwarders that re-sign messages with DKIM ought to consider the reputational and identity risk that it imposes. With ARC [RFC8617], receivers sometimes override their local DMARC results with results found from the ARC-Authentication-Result header to prevent mail from being rejected or quarantined. Malicious senders may target these receivers if that override is done improperly. Hence receivers ought to carefully consider whether they can trust the results passed in the ARC-Authentication-Results as they are provided by the forwarder without any guarantee they are correct. SPF, DKIM and ARC forwarding attacks and other considerations are discussed further in Liu et. al. [1]. [1] Liu, Enze et al. "Forward Pass: On the Security Implications of Email Forwarding Mechanism and Policy", Proceedings of the 8th IEEE European Symposium on Security and Privacy, 2023. On Sun, Aug 6, 2023 at 1:46 PM Scott Kitterman <skl...@kitterman.com> wrote: > That reads to me as guidance for DMARC implementers on how to integrate > SPF and DKIM results for the purposes of DMARC. I think that's in scope > for DMARCbis. > > There's a multitude of ways people can screw these things up and we won't > be able to cover them all. The guidance needs to be somewhat high level. > > One of my favorites is a case I was asked to investigate where an ESP had > transmitted a clearly forged email for one of their customers and the > customer wanted to know why DMARC hadn't protected them, even though they > had a p=reject policy. > > What happened was that the ESP received a DMARC fail email from an > unrelated mail server that also had a valid ARC signature, so instead of > rejecting the message, they allowed the ARC result to override the DMARC > policy and accepted it. Then they relayed it to the final destination > (which in the same domain as the From domain - which was owned by their > customer). There's all kinds of things people can do to mess this up. I > don't think it's obscure that one should only believe ARC results from > trusted sources, but there we were. > > Scott K > > On August 6, 2023 8:07:31 PM UTC, Wei Chuang <weihaw= > 40google....@dmarc.ietf.org> wrote: > >I don't think having this language is saying you can't do SPF. Rather > this > >is about preventing new spoofing attacks on DMARC aligned identity. In > >particular where previously this attack was not possible on forwarders > that > >honored the p=reject policy, now that they will downgrade to quarantine, > it > >opens a new vector that should be reviewed to prevent this attack. I > >propose this because I've seen the forwarding attack with SPF on ups.com. > >The Liu et. al. paper notes that they were able to spoof the From header > >government e.g. state.gov, financial and legal companies with SPF. You > >noted that it's feasible with DKIM too. The RFC should ask forwarders to > >do this review when they p=reject downgrade otherwise it does add systemic > >risk to the DMARC protected From identity. > > > >-Wei > > > >On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman <skl...@kitterman.com> > >wrote: > > > >> On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote: > >> > > On Aug 5, 2023, at 5:37 PM, Scott Kitterman <skl...@kitterman.com> > >> wrote: > >> > > > >> > > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote: > >> > >> It appears that Scott Kitterman <skl...@kitterman.com> said: > >> > >>>> When receivers apply the "MUST NOT reject" in Section 8.6 to > accept > >> > >>>> unauthenticated messages as quarantined messages, receivers > SHOULD > >> > >>>> carefully review how they forward mail traffic to prevent > additional > >> > >>>> security risk. That is, this downgrade can enable spoofed > messages > >> > >>>> that > >> > >>>> are SPF DMARC authenticated with a fraudulent From identity > despite > >> > >>>> having > >> > >>>> an associated strong DMARC policy of "p=reject". ... > >> > >> > >> > >> We all realize that SPF has problems, but I really do not want to > fill > >> > >> up the DMARC document with text that says "you can authenticate > with > >> > >> SPF, hahaha no just kidding." > >> > >> > >> > >> The way to fix Microsoft's forwarding SPF problem is for Microsoft > to > >> put > >> > >> the forwarding user's bounce address on the message, not for us to > >> tell > >> > >> the entire world to use kludgy workarounds. > >> > > > >> > > I agree. We need to be careful to solve protocol problems in the > >> protocol > >> > > and leave fixing implementation problems to implementers. We aren't > >> > > going to protocol our way out of bad implementation decisions. > >> > > >> > Taken within the good-intention, protocol-compliant implementations, > >> which > >> > one do we add as “Implementations Notes?” Which or rather What are > >> > “Current Practice”behavior can we note? > >> > >> I think best current practice goes in a different document. Maybe we do > >> that > >> after DMARCbis is buttoned up? > >> > >> Scott K > >> > >> > >> _______________________________________________ > >> 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
