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 <barryle...@computer.org> 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 < > dougfoster.emailstanda...@gmail.com> 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 <barryle...@computer.org> >> 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 <s...@sethblank.com> wrote: >>> > >>> > Doug, Barry's email sent as Chair was clear and specific: >>> > >>> > On Fri, Aug 26, 2022 at 8:33 AM Barry Leiba <barryle...@computer.org> >>> 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 < >>> dougfoster.emailstanda...@gmail.com> 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 >>> >> dmarc@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/dmarc >>> > >>> > _______________________________________________ >>> > dmarc mailing list >>> > dmarc@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dmarc >>> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
