Re: [dmarc-ietf] Issue opened: Use a four-valued token for the four roles of a DMARC policy

[Scott Kitterman <[e-mail]>]

Where in the document are you proposing this text be added?

Scott K

On August 28, 2022 9:04:18 PM UTC, Douglas Foster <[e-mail]> wrote:
>I have stewed on the issues more while mowing the lawn.   The language
>below will address my concerns without changing the PSD=value token.
>
>
>
>Certainty
>
>Certainty can be achieved by adding constraints to the “psd=n” token:
>
>“Some organizations have subtrees within their DNS structure that represent
>client sub-organizations, which are unaffiliated for purposes of relaxed
>authentication.   Before putting a PSD=N tag on an organizational domain
>policy, the domain owner MUST ensure that all sub-organization boundaries
>are properly identifiable.   Identification can be accomplished by placing
>a PSD=Y tag on the domain which is the parent of the sub-organizations, by
>placing a PSD=Y tag on the organizational domain of every client
>sub-organization, or both.”
>
>
>
>PSD=Y+N vs. PSD=Y only
>
>More than 90% of all PSL entries are both PSD=N (organization top) and
>PSD=Y (registration point).   I am looking to ensure that both types of
>registrars have a way to publish DMARC policies that do not depend on the
>configuration of parent domains.   I think this will suffice:
>
>“Most registrar domains are self-contained, meaning that the parent domain
>is a PSD and child domains are PSDs or unaffiliated organizations or PSDs.
>When this is the case, the domain owner should publish PSD=Y as well as
>askim=s and aspf=s.   This ensures that the Tree Walk will terminate and
>use the current domain policy as the default policy.”
>
>When a registrar and its parent are in the same organization, and the
>organization sends mail, DMARC policies using relaxed alignment may be
>desired.   When “psd=y” is encountered on the initial exact-match domain,
>and relaxed alignment is specified, the “psd=y” term is ignored and the
>Tree Walk is used to find the parent record which is the organizational
>domain.”
>
>
>
>DF
>
>On Sun, Aug 28, 2022 at 4:10 PM Barry Leiba <[e-mail]> wrote:
>
>> Thanks for that, Doug.
>>
>> The part that’s missing is in relation to this: “keeping in mind that
>> we’ve already established that the current PSD= tag is needed in only a
>> very small number of domains”.
>>
>> If things were truly open-ended, there might be more agreement with you.
>> But the fact that, using the PSL as a guide, we can easily count the number
>> of domains that will have to add a PSD tag, it’s hard to see an actual
>> (rather than theoretical) benefit from this change.  Your proposal is also
>> subject to errors when domains that need to use it fail to.  But the bottom
>> line is that in either case, *very* few domains are affected.
>>
>> If the text in the document now is unclear and likely to cause errors of
>> confusion, we should address that, clearly.  But I have to agree with
>> Scott, John, and Mike in that I don’t see a real-world benefit either.
>>
>> Barry
>>
>> On Sun, Aug 28, 2022 at 3:03 PM Douglas Foster <
>> [e-mail]> wrote:
>>
>>> The PSL has two problems:
>>> - It removes control of relaxed authentication boundaries from the domain
>>> owners.
>>> - It is subject to errors which can cause both false PASS and false FAIL
>>> - The possibility of errors means that evaluators cannot be certain
>>> whether PASS and FAIL can be trusted.   This is irrespective of the
>>> decision whether a PASS should or FAIL result should be actionable.
>>>
>>> The PSD=token has similar problems:
>>> - It depends primarily on registrars to define organizational boundaries
>>> - It is subject to false PASS errors when registrar boundaries are not
>>> tagged.
>>> - It has ambiguity PSD=Y ONLY and PSD=Y+N domains, and I see that
>>> ambiguity as likely to cause errors in policy tagging, software, or both.
>>> - The possibility of errors means that evaluators cannot be certain
>>> whether PASS and FAIL can be trusted.   This is irrespective of the
>>> decision whether a PASS should or FAIL result should be actionable.
>>>
>>> The Boundary=Token proposal is a reworking of the role=(tokens) proposal
>>> that Ale introduced a long time ago.  It does not change the logic to be
>>> used when tokens are missing, so it is not more or less incompatible than
>>> the current document.   But it does provide domain owners with the ability
>>> to fully document their configuration, which gives them the control which
>>> is fundamental to the general DMARC concept.   When the policy roles are
>>> explicit, the evaluator has confidence that the result is error-free,
>>> because the domain owner has explicitly asserted the information needed to
>>> make that conclusion.
>>>
>>> As a fundamental design issue, I have a problem with using a two-state
>>> semaphore to represent a four-state reality.
>>>
>>> This document provides heuristics for working around missing data.   The
>>> heuristic is plausible, and the proponents of PSD=token consider this a
>>> final state.   I consider it a transitional state.  I believe our final
>>> state should be one where organizational boundaries are based on explicit
>>> domain owner information, not on guesswork.   I don't see how a standards
>>> track document would not define error-free results as the intended final
>>> state.
>>>
>>> Allowing domain owners to voluntarily add token to their DMARC policy, in
>>> exchange for gaining full control of relaxed alignment, seems both
>>> acceptable ask and appropriate.
>>>
>>> Doug Foster
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Aug 27, 2022 at 6:22 PM Barry Leiba <[e-mail]>
>>> wrote:
>>>
>>>> Seth is right here: Doug, your message doesn't comply with what I've
>>>> asked people to do, in two ways: it's asking for a change to something
>>>> we already have consensus on and it's not proposing specific text
>>>> changes.
>>>>
>>>> That said, there are two mitigating factors.  For the latter, the
>>>> request is specific enough that I think there's enough detail to
>>>> discuss it.
>>>>
>>>> For the former, the PSD= feature is new enough, and our participation
>>>> level has gotten low enough that it's difficult to say how strong the
>>>> consensus is on that point, and I think it's reasonable to have
>>>> another look.  I've discussed this with Seth since his message below,
>>>> and I'm allowing this issue to be opened for discussion, BUT...
>>>>
>>>> ...BUT let's keep the discussion focused and productive: I will cut it
>>>> off at some point, so it's important that everyone in the discussion
>>>> make their points clear and concise.
>>>>
>>>> John has replied that this is incompatible.  Yes, but PSD= is also, at
>>>> some level, incompatible... though far less so.  So here's one thing
>>>> I'd like to see discussed:
>>>>
>>>> - Doug, please clearly and concisely explain what benefit this has
>>>> over the current PSD= tag that makes the incompatibility with existing
>>>> implementations worth it.
>>>>
>>>> - If you disagree with Doug's proposal, please clearly and concisely
>>>> explain why the benefit he is proposing is not useful enough to
>>>> introduce the incompatibility.
>>>>
>>>> Barry
>>>>
>>>> On Sat, Aug 27, 2022 at 3:01 PM Seth Blank <[e-mail]> wrote:
>>>> >
>>>> > Doug, Barry's email sent as Chair was clear and specific:
>>>> >
>>>> > On Fri, Aug 26, 2022 at 8:33 AM Barry Leiba <[e-mail]>
>>>> wrote:
>>>> >>
>>>> >> We have come to a point in our discussions of
>>>> >> draft-ietf-dmarc-dmarcbis that the basic content and features of DMARC
>>>> >> are stable and have rough consensus.  Coupling that with the
>>>> >> expectation, as in the working group's charter, that changes to the
>>>> >> protocol that break interoperability with installed base need detailed
>>>> >> justification, I think we need to be clear on how to go forward as we
>>>> >> finish up.
>>>> >>
>>>> >> At this point, again, we consider the content and features to be
>>>> >> stable, and changes to that are no longer in scope.
>>>> >
>>>> >
>>>> > What you raise as alternative token design goes counter to this clean
>>>> line.
>>>> >
>>>> > Further, we're at the point of the bis project, as Barry also points
>>>> out, where we expect comments to be accompanied by text suggestions,
>>>> preferably in an OLD/NEW format.
>>>> >
>>>> > Doug, if you believe there is an issue here within scope of the text I
>>>> quoted from Barry, please cite the section and text in the document and
>>>> propose updated language.
>>>> >
>>>> > Otherwise, the time for topics like these has come and gone.
>>>> >
>>>> > Seth, as Chair
>>>> >
>>>> > On Fri, Aug 26, 2022 at 8:08 PM Douglas Foster <
>>>> [e-mail]> wrote:
>>>> >>
>>>> >> Alternative token design.
>>>> >>
>>>> >>
>>>> >> Boundary=A (Above only)
>>>> >>
>>>> >> Literal: The domain owner asserts that an
>>>> organizational/administrative boundary exists between the current domain
>>>> and its parent, meaning the domain and its parents are not aligned for
>>>> relaxed authentication. No boundary exists immediately below this domain,
>>>> so its child domains are aligned with it for relaxed authentication.
>>>> >> Role: An Organizational Domain
>>>> >> PSL Equivalent representation: The domain does not exist in the PSL,
>>>> or is listed with negation. The parent domain is listed in the PSL, and
>>>> without negation.
>>>> >> Tree walk significance: The tree walk always stops on Boundary=A, as
>>>> this domain is the organizational domain and provides the default policy.
>>>> >> PSD=token equivalent: “psd=n”
>>>> >>
>>>> >>
>>>> >> Boundary=N (None, Neither)
>>>> >>
>>>> >> Literal: That domain owner asserts that the domain does not have any
>>>> adjacent organizational/administrative boundaries.
>>>> >> Role: An organizational subdomain.
>>>> >> PSL Equivalent representation: : The domain does not exist in the
>>>> PSL. The parent domain is also not listed, or listed with negation.
>>>> >> Tree walk significance: The domain owner has indicated awareness of
>>>> DMARCbis. The tree walk will end on domain with a DMARC policy and a
>>>> “Boundary=A” term. If an explicitly tagged organizational domain policy is
>>>> not found, the result is PERMERROR and the evaluator is recommended to fall
>>>> back to strict alignment.
>>>> >> PSD=token equivalent: None
>>>> >>
>>>> >>
>>>> >> Boundary=2 (Both above and below)
>>>> >>
>>>> >> Literal: The domain owner asserts that an
>>>> organizational/administrative boundary exists both immediately above and
>>>> immediately below this domain. Consequently, an exact match is required for
>>>> alignment.
>>>> >> Role: All Public Suffix Domains and many Private Registry domains.
>>>> >> PSL Equivalent: Both the current domain and its parent are listed in
>>>> the PSL, both without negation.
>>>> >> Tree walk significance: The tree walks stops. If this is the
>>>> exact-match domain, the organizational domain and default policy are from
>>>> this record. If this domain is encountered subsequently during the tree
>>>> walk, the walk stops, the current domain policy is the default policy but
>>>> the immediately lower child domain is the organizational domain for relaxed
>>>> alignment.
>>>> >> PSD=token equivalent: Nothing provides a complete equivalence, but
>>>> PSL=Y is used as an approximation.
>>>> >>
>>>> >>
>>>> >> Boundary=B (Below only)
>>>> >>
>>>> >> Literal: The domain owner asserts that an
>>>> organizational/administrative boundary exist between this domain and its
>>>> child domains, so its child domains are not aligned for relaxed
>>>> authentication. No organizational/administrative boundary exists above this
>>>> domain, so this domain can participate in relaxed alignment with its
>>>> immediate parent.
>>>> >> Role: A private registry whose parent domain is in the same
>>>> organization.
>>>> >> PSL Equivalent: The current domain is listed in the “Private
>>>> Registry” section of the PSL, without negation. The parent domain is not
>>>> listed at all.
>>>> >> Tree walk significance: If encountered on the exact-match domain, the
>>>> domain is treated the same as “Boundary=N”, and the tree walk proceeds
>>>> upward. If encountered subsequently during the tree walk, the domain is
>>>> treated the same as “Boundary=2”: the Tree Walk stops, the current domain
>>>> policy becomes the default policy but the immediately lower child domain is
>>>> the organizational domain for relaxed alignment.
>>>> >> PSD=token equivalent: : Nothing provides a complete equivalence, but
>>>> PSL=Y is used as an approximation.
>>>> >>
>>>> >>
>>>> >> DMARC policy with no Boundary=token term
>>>> >>
>>>> >> Literal: The domain owner has not added new information in support of
>>>> DMARCbis to his policy. The presence or absence of
>>>> organizational/administrative boundaries must be inferred.
>>>> >> Role: Not stated and therefore not known with certainty.
>>>> >> PSL Equivalent: None. The PSL lookup always returns a result.
>>>> >> Tree Walk significance: Information about this policy is stored, the
>>>> Tree Walk continues upward, and an inference is made when the Tree Walk is
>>>> complete.
>>>> >> PSD=token equivalent: “psd=u”
>>>> >>
>>>> >>
>>>> >> Domain with no DMARC policy
>>>> >>
>>>> >> Literal: The domain owner has not attached a DMARC policy to the
>>>> current domain.
>>>> >> Role: Not stated and therefore not known with certainty.
>>>> >> PSL Equivalent: None. The PSL lookup always returns a result.
>>>> >> Tree Walk significance: Information about this policy is stored, the
>>>> Tree Walk continues upward, and an inference is made when the Tree Walk is
>>>> complete.
>>>> >> PSD=token equivalent: Not applicable. Since no policy is present, no
>>>> tokens are present in that policy.
>>>> >>
>>>> >> _______________________________________________
>>>> >> dmarc mailing list
>>>> >> [e-mail]
>>>> >> https://www.ietf.org/mailman/listinfo/dmarc
>>>> >
>>>> > _______________________________________________
>>>> > dmarc mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/dmarc
>>>>
>>> _______________________________________________
>>> dmarc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>