Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

[Scott Kitterman <[e-mail]>]

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=[e-mail]> 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 <[e-mail]>
>wrote:
>
>> On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote:
>> > > On Aug 5, 2023, at 5:37 PM, Scott Kitterman <[e-mail]>
>> wrote:
>> > >
>> > > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
>> > >> It appears that Scott Kitterman  <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>