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

[Scott Kitterman <[e-mail]>]

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:
> > Colleagues,
> > 
> > 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'd suggest we discuss where to say it first.  I think the right place is
> security considerations, which starts:
> 
> 11.  Security Considerations
> 
>    This section discusses security issues and possible remediations
>    (where available) for DMARC.
> 
> I think there are two, related questions here:
> 
> One is the risk associated with which I'll call a false pass from one of the
> underlying authentication mechanisms.
> 
> The other is the risk associated with using DMARC results for positive
> associations (as BIMI does).  Even absent third party considerations, all it
> takes is one compromised user account and forged messages can get a DMARC
> pass.  DMARC was designed to identify "bad" mail, not certify any kind of
> goodness.
> 
> 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.

Scott K