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

[Douglas Foster <[e-mail]>]

Not strongly opinionated about location.

For the first insertion:  Since the definition of psd=n  occurs in the
policy record, and after the tree walk, this seems to fit in with the psd=n
definition.

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.


For the second insertion:  Also append it to the definition of psd=y.  If
the tree walk description was more algorithmic, I would place the second
paragraph with the description of how the initial exact-match policy is
handled, but that is not an option.

"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 5:16 PM Scott Kitterman <[e-mail]>
wrote:

> 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
> >>>
> >>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>