Re: [dmarc-ietf] Additions to draft - Security Considerations

[Scott Kitterman <[e-mail]>]

On Friday, April 29, 2022 4:11:21 AM EDT Alessandro Vesely wrote:
> On Tue 26/Apr/2022 19:23:06 +0200 Scott Kitterman wrote:
> > On April 26, 2022 4:50:08 PM UTC, Alessandro Vesely <[e-mail]> 
wrote:
> >>On Tue 26/Apr/2022 14:53:27 +0200 Scott Kitterman wrote:
> >>> On April 26, 2022 8:06:50 AM UTC, Alessandro Vesely <[e-mail]> 
wrote:
> >>>> On Mon 25/Apr/2022 05:56:46 +0200 Scott Kitterman wrote:
> >>>>> How about something like this:
> >>>>> 
> >>>>> 9.7 Determination of the Organizational Domain For Relaxed Alignment
> >>>>> 
> >>>>> DMARC evaluation for relaxed alignment is highly sensitive to errors
> >>>>> in the
> >>>>> determination of the organizational domain if the RFC5322.From domain
> >>>>> does not have a published policy.  If an incorrectly selected
> >>>>> organizational domain is a parent of the correct organizational
> >>>>> domain, then relaxed alignment could potentially allow a malicious
> >>>>> sender to obtain DMARC PASS.  This potential exists for both the
> >>>>> legacy [RFC 7489] and current [Section 4.8] methods for determining
> >>>>> the organizational domain.
> >>>> 
> >>>> I object that this text undermines the robustness of the protocol and
> >>>> may sound like a campaign for strict alignment.  Relaxed alignment is
> >>>> safer from a flexibility POV, as it accounts for occasional
> >>>> @hostname.example.com.  It has played a relevant role in DMARC
> >>>> success, and it's not by chance the default.>>>> 
> >>>> Here's an alternative text:
> >>>>    DMARC evaluation for relaxed alignment is sensitive to errors in the
> >>>>    determination of the organizational domain due to erroneous DNS
> >>>>    settings by
> >>>>    either the organizational domain or its PSD parent.  If the PSD
> >>>>    parent is
> >>>>    incorrectly selected as organizational domain, then relaxed
> >>>>    alignment can
> >>>>    potentially allow a malicious sender to obtain DMARC PASS while
> >>>>    impersonating the relevant organization.  This potential exists for
> >>>>    both
> >>>>    the legacy [RFC 7489] and current [Section 4.8] methods for
> >>>>    determining the
> >>>>    organizational domain.
> >>>>> 
> >>>>> This issue is completely avoided by use of strict alignment and
> >>>>> publishing
> >>>>> DMARC records for all domains/sub-domains used as RFC5322.From domain
> >>>>> in an
> >>>>> organization's email.
> >>>>   or by publishing psd=n.
> >>>>> 
> >>>>> For cases where strict alignment is not appropriate, this issue can be
> >>>>> mitigated by periodically checking the DMARC records, if any, of PSDs
> >>>>> above
> >>>>> the organization's domains in the DNS tree and (for legacy [RFC 7489]
> >>>>> checking that appropriate PSL entries remain present).  If a PSD
> >>>>> domain publishes a DMARC record without the appropriate psd=y tag,
> >>>>> organizational domain owners can add psd=n to their organizational
> >>>>> domain's DMARC record so that the PSD record will not be incorrectly
> >>>>> evaluated to be the organizational domain.>>>> 
> >>>> The latter alternative is obviously easier than monitoring the DNS
> >>>> settings of the PSD parent, and has to be carried out anyway in 
case.>>> 
> >>> What specifically do you object to?
> >>
> >>A quick skim through your text seems to be summarizable as "DMARC has a
> >>defect but you can overcome it by using strict alignment".  I know that's
> >>not what you meant, but it sounds quite like that.>>
> >>> Do you think it's inaccurate that this concern is limited to relaxed
> >>> alignment?>>
> >>No, I think it's wrong to blame relaxed alignment.
> >>
> >>> The specific suggestion you added (or by publishing psd=n) is already in
> >>> the text later on, so I'm not understanding what you think the problem
> >>> is or what you want to do about it?>>
> >>The alternative text above differs slightly from the first paragraph of
> >>the text you proposed, in an attempt at watering down that meaning.>>
> > Okay.  Explain how the issue occurs when alignment is strict?
> 
> It is obviously easier to verify alignment when it is strict.  You don't
> even need to determine the org domain exactly; retrieving a DMARC record
> suffices. That's not the point.
> 
> The point is that it is not right to (apparently) suggest to turn to strict
> alignment because of problems in determining the org domain.  The solution
> is to set psd= correctly.  I hope Todd will word it out clearly.

What is not right about it?  You say yourself it avoids the problem.

I may be misunderstanding you here, but it seems like you agree the statement 
is technically accurate, but there's some moral dimension to it.  Is that 
right?

I really don't understand your objection.

I would suggest Todd goes ahead and puts my proposed text in, so we have 
something to cover the issue and we can work to refine it once we clear this 
up.

Scott K