On Fri, Aug 4, 2023 at 2:11 PM Scott Kitterman <skl...@kitterman.com> wrote:
> > > On August 4, 2023 4:15:35 PM UTC, Wei Chuang <weihaw= > 40google....@dmarc.ietf.org> wrote: > >I noted at the DMARC session -117, that with the p=reject downgrade to > >quarantine language, this increases the risk of SPF upgrade attacks due to > >forwarding. The reply was to propose language for this and below is the > >suggested text for the proposed "11.9 Quarantined Forwarded Mail Security > >Risk" > > > >===== > > > >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 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". A malicious sender needs > >two properties to perform such a SPF upgrade 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 may be under > >control of the malicious sender perhaps via auto-forwarding or enterprise > >policy. Receivers SHOULD consider restricting forwarding when the message > >is SPF unauthenticated. SPF upgrade attack 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. > > I think I understand what you are saying here and I agree it's worth > documenting, but I have a few suggestions: > > 1. I would reword it not to have RFC 2119 keywords in it. As I > understand it, these keywords are supposed to be for technical protocol > elements, not things people do like "SHOULD consider". Agreed that this is a good idea. > > 2. I would rewrite it not to use the terms upgrade and downgrade. I > think the usage is confusing here. > Also doable to replace the upgrade and downgrade language. > > Finally, I don't think this is particularly unique to SPF. If you replace > "finds a SPF policy that covers the forwarding IPs" with something like > finds a third party willing to sign the message, I expect I could construct > a similar (if not quite as easy) DKIM based scenario. > Agreed this scenario has systemic risk, and that forwarders should mitigate. We could reframe this paragraph to note both scenarios. Also Liu et. al. paper notes this scenario in section 4.3.3. -Wei > > 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
