Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

[Douglas Foster <[e-mail]>]

But if we have no advice on how to detect a false Pass, how is this
useful?   Are we helping evaluators or just giving ourselves cover that
"your disaster is not our fault because we warned you"?

On Sun, Mar 17, 2024, 10:59 AM Scott Kitterman <[e-mail]> wrote:

>
>
> On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely <[e-mail]>
> wrote:
> >On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote:
> >> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote:
> >>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote:
> >>>>
> >>>> Issue 135 is open for the subject topic. Please add your thoughts to
> this thread and/or to the issue in Github.
> >>>>
> >>>> Thank you.
> >>>
> >>> [...]
> >>>
> >>> I think both of these should be addressed as part of this issue in
> Security
> >>> Considerations.
> >>
> >> It seems to me that, to the extent we are going to address this issue,
> there
> >> is agreement that Security Considerations is appropriate.  Here's
> proposed
> >> text:
> >>
> >> 11.X  External Mail Sender Cross-Domain Forgery
> >>
> >> Both of the email authentication methods which underlie DMARC
> fundamentally
> >> provide some degree of assurance that an email was transmitted by an
> MTA which
> >> is authorized to do so.  SPF policies just map domain names to sets of
> >> authorized MTAs [ref to RFC 7208, section 11.4].  Verified DKIM
> signatures
> >> indicate that an email was transmitted by an MTA with access to a
> private key
> >> that matches the published DKIM key record.
> >>
> >> When Domain Owners authorize mail to be sent by sources outside their
> >> Administrative Management Domain there is a risk that an overly
> permissive
> >> source may send mail which will, as a result, receive a DMARC pass
> result that
> >> was not, in fact, authorized by the Domain Owner.  These false
> positives may
> >> lead to issues with systems that make use of DMARC pass results to
> indicate a
> >> message is in some way authentic.  They also allow such unauthorized
> senders
> >> to evade the Domain Owner's requested message handling for
> authentication
> >> failures.
> >>
> >> The only method to avoid this risk is to ensure that no overly
> permissive
> >> sources can successfully DKIM sign the domain's mail or transmit mail
> which
> >> will evaluate as SPF pass.  If there are non-DMARC reasons for a domain
> owner
> >> to include a permissive source in a domain's SPF record, the source can
> be
> >> excluded from DMARC consideration by using the '?' qualifier on the SPF
> record
> >> mechanism associated with that source.
> >
> >
> >That text is too long and lacks an example.
> >
> >The first paragraph can be omitted without losing context.  BTW, Section
> 11.4 of RFC 7208 is about /cross-user/ forgery, not cross-domain.
> >
> >The second paragraph doesn't mention SPF.  Couldn't it be more direct?
> For example:
> >
> >    Domain Owners who set up SPF records which include sources outside
> their
> >    Administrative Management Domain run the risk that an overly
> permissive
> >    source may allow its users to send scam mail which will receive a
> DMARC
> >    pass results that were not intended by the Domain Owner.  These false
> >    positives [...]
> >
> >The third paragraph is also longer than needed.  There's no need to
> mention DKIM if we're talking SPF forgery.  I'd also point out that the
> neutral qualifier prevents quick rejection of the message, and is probably
> useless for those who have ~all.  (Are there MTAs who distinguish between
> neutral and softfail?  Are we prompting them to do so?)  Perhaps mention
> that this is a compromise between striking the SPF record tout-court and
> allowing false positives.
> >
> >Most important, write "?include:example.com".  An example is worth a
> thousand words.
>
> I disagree.
>
> Security considerations should be a complete description of the
> consideration.  While the data that's been discussed about current issues
> has been SPF related, there's no reason a third-party couldn't equally
> screw up and sign DKIM in a similar manner.  We should include both (we
> discussed this pretty extensively already, let's not do it again).
>
> I think we need to be explicit that there are two risks:
>
> 1.  Bad mail gets DMARC pass and so DMARC policy is not applied (avoid
> consequences of DMARC fail).
>
> 2.  Bad mail gets DMARC pass and something else (e.g. BIMI) does a wrong
> thing (gets benefits of DMARC pass).
>
> It's not typical to put examples in security considerations.
> Additionally, I think doing so would over emphasize that aspect of the
> consideration.  We're a technical group and so we like technical solutions,
> but for this one, I think the boring and difficult policy question of not
> authorizing third parties that do bad things is more important.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>