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

[Scott Kitterman <[e-mail]>]

I only want to get the documentation correct.  No campaign of any kind.

Since use of psd=n is under the control of the domain owner, I think it's as verified as anything else the domain owner might add.

Let's please focus on getting the security consideration to wording settled before rehashing only tangentially related points.

Unless Ale or someone else has an example where this is a problem for strict alignment, I think the text I proposed is close enough to complete to go ahead and add it to the next revision.

Scott K

On April 27, 2022 12:41:51 AM UTC, Douglas Foster <[e-mail]> wrote:
>Alessandro has figured me out.   I am trying to be very clear about the
>advantages of strict alignment and same-domain policies.    I would stop
>short of calling it a campaign, because I have no intent of trying to
>deprecate the other options.
>
>Security considerations are about ensuring that the evaluator understands
>risks.   These need to be in the document because this forum helps us think
>about things that may not be obvious to the reader without our help.
>Similarly, the mitigations are advice to the message senders:   if you want
>to minimize distrust by the evaluator of your message, here are things to
>do and things to avoid.
>
>We have four levels of trust related to organizational alignment, for
>lowest to highest trust:
>- Organization boundary unknown (no DMARC policy)
>- Organization boundary selected but not verified (the tree walk)
>- Organization boundary selected and verified (needs discussion)
>- Organization boundary not needed (strict alignment and exact match
>domains)
>
>A message sender who wants to maximize trust can do so by making
>organization ambiguity irrelevant to the approval decision.
>
>
>Organization boundary verification:
>
>We have established that the organization boundary should be verified when
>the domain path includes a private registration.  This is because the tree
>walk might select the registrar domain instead of the client
>domain, allowing a private registration client to impersonate the parent or
>the sibling domains.    Since we don't know which domain paths contain
>private registries, we need to verify all organizational domain selections.
>
>Note that it is not enough to handle this problem with psd=n, because the
>evaluator needs to know that the psd=n which he found is the correct one
>for his DNS path.   Although the RFC 7489 (PSL) method does not have a
>verification method, it could be used as a verification method for the tree
>walk.   However, this approach would not do enough to solve the existing
>PSL problems.  Instead, we need a DNS-based method of doing this.   My
>OrgBelow token proposal accomplishes that purpose, by providing explicit
>information about boundaries from the perspective of both the From domain
>and the selected Organizational domain.    When they agree, we have the
>desired evidence of common administrative control.   When they do not
>explicitly agree, we have ambiguity.   In most cases, the evaluator will
>choose to accept the ambiguity, but we should provide a mechanism for the
>message sender and evaluator to operate with minimal ambiguity and minimal
>fear.  So we need a token like OrgsBelow.
>
>Doug
>
>
>
>On Tue, Apr 26, 2022 at 12:57 PM 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.
>>
>>
>> Best
>> Ale
>> --
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>