On Fri, Aug 4, 2023 at 5: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. I would also suggest breaking up the paragraph to perhaps spell
these out more clearly:
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.
2. I would rewrite it not to use the terms upgrade and downgrade. I think
> the usage is confusing here.
>
I don't see upgrade and downgrade elsewhere in the -28 version, so I would
agree
> 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.
>
> 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
