Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

[Scott Kitterman <[e-mail]>]

On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote:
> Colleagues,
> 
> After reviewing the "Another point SPF advice" thread and Murray's separate
> post re: SHOULD vs. MUST, I have opened issue 132 on the topic:
> 
> The current text of section 5.5.1, Publish and SPF Policy for an Aligned
> Domain, reads:
> 
> ==================================================
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376]], in order to
> take full advantage of DMARC, a Domain Owner SHOULD first ensure that SPF
> and DKIM authentication are properly configured. As a first step, the
> Domain Owner SHOULD choose a domain to use as the RFC5321.MailFrom domain
> (i.e., the Return-Path domain) for its mail, one that aligns with the
> Author Domain, and then publish an SPF policy in DNS for that domain. The
> SPF record SHOULD be constructed at a minimum to ensure an SPF pass verdict
> for all known sources of mail for the RFC5321.MailFrom domain`
> ==================================================
> 
> In the ticket, I propose the following replacement text:
> 
> ==================================================
> Because DMARC relies on SPF [[RFC7208]] and DKIM [[RFC6376], in order to
> take full advantage of DMARC, a Domain Owner MUST first ensure that either
> SPF or DKIM authentication are properly configured, and SHOULD ensure that
> both are.
> 
> To configure SPF for DMARC, the Domain Owner MUST choose a domain to use as
> the RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail
> that aligns with the Author Domain, and then publish an SPF policy in DNS
> for that domain. The SPF record MUST be constructed at a minimum to ensure
> an SPF pass verdict for all known sources of mail for the RFC5321.MailFrom
> domain.
> ==================================================
> 
> In addition, the last paragraph in section 5.5.2, Configure Sending System
> for DKIM Signing Using an Aligned Domain, reads:
> 
> ==================================================
> The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain
> in the DKIM-Signature header) that aligns with the Author Domain.
> ==================================================
> 
> In the ticket, I propose the following new text:
> 
> ==================================================
> To configure DKIM for DMARC, the Domain Owner MUST choose a DKIM-Signing
> domain (i.e., the d= domain in the DKIM-Signature header) that aligns with
> the Author Domain.
> ==================================================
> 
> Further notes on the threads that gave rise to this ticket:
> 
>    - I do not believe that recommending the use of the ? modifier in an SPF
>    record configured for DMARC is appropriate, since as I understand the ?
>    modifier, the result produced is not "pass", but rather "neutral", which
> is the same as "none". Therefore, an SPF record using ? would not produce
> an aligned pass to be used with DMARC. I am willing to be convinced that
> I'm wrong here.
>    - That said, I think there is room for discussion of too-permissive SPF
>    records and the  cross-user forgery discussed in RFC 7208 Section 11.4,
> and I will open a separate issue for that to expand on section 8.1

I think MUST do SPF or DKIM, SHOULD do SPF, to do SPF MUST do xxx, SHOULD do 
DKIM, to do DKIM MUST do yyy is reasonable (that's how I parsed your proposed 
changes, is that right?).  I think it's an improvement and assuming I am 
reading it correctly, I support the change.

Relative to the further notes section:

I think we need to do something about this.  For SPF, there's a trade off 
available when including third parties in your SPF record that allows you to 
have them not fail SPF, but not be aligned for DMARC purposes (the ? 
qualifier).  It's a trade off and that trade off should be described.

Third parties are always a risk.  If you set up DKIM signing for a third party 
and they sign mail from your domain that you didn't send, you'll get the exact 
same issue.  It's fundamentally the same problem.  Just because we aren't 
seeing scads of this at the moment, doesn't mean we should ignore it.

I'll leave this just as a thought for now, since we should discuss it in the 
other issue, but I think this discussion probably belongs in security 
considerations.

Scott K