What would be the benefit of all this extra complexity? What does a domain with an unhelpful PSD get over publishing psd=n based on the current draft?
I think there's some small chance of the problem I think you are describing occurring, but I believe we've addressed it already in a much simpler way. Scott K On Thursday, April 21, 2022 10:24:26 PM EDT Douglas Foster wrote: > Yes, there is a fundamental difference between a vulnerability that is > created because of a change in rules, as compared to a design that requires > convincing a third party to act contrary to that parties intended purpose. > > But to the problem that you want to solve: > > Assume that a savvy email manager is trying to decide whether to embrace > the new design or not. He is likely to run both algorithms and evaluate > the results. If the two algorithms produce the same result, he is happy. > If the DNS produces a lower organization domain, he is happy to accept the > more restrictive alignment scope. > > But if the DNS produces a higher organization domain, he is skeptical. We > need to provide assurance that the located organization domain is in the > same organization as the subdomain FROM address that started the process. > This is as simple as a policy token which says "no organizational > boundaries below". An integer seems to make the most sense: > > Given an organizational domain of "orgdomain.parentpath" > - OrgsBelow=0 - means the entire subtree is one organization, no > organizational boundaries exist below "orgdomain.parentpath" > - OrgsBelow=1 - this is a registrar domain and the next level down is > registered clients. "sub1.orgdomain.parentpath" is a separate organization > from "orgdomain.parentpath" > - OrgsBelow=2 - an organization boundary exists two levels down. > "sub1.orgdomain.parentpath" is part of "orgdomain.parentpath" but > "sub2.sub1.orgdomain.parentpath" is a separate organization. > And so forth. Based on our analysis, the highest expected value is 3, but > the design is insensitive to the value published. A very high value like > 99 is effectively equivalent to the value 0. > > (Optionally, we could specify that OrgsBelow<0 means that there are no > subdomains in the organization, so any appearance of a subdomain is > fraudulent. This is a stronger repudiation than SP=reject.) > > For the vast majority of domains that are not private registries, using > OrgsBelow=0 allows them to be completely free of the PSL. > > Organizations that fail to publish this flag will be vulnerable to trust > issues, since a cautious email manager will worry that they may contain a > private registry. If the evaluator responds to this risk by comparing > the DNS result to the PSL result, and the PSL result is lower, the savvy > evaluator may choose the lower entry. If this is not what the domain owner > wants, he should publish the OrgsBelow indicator. > > Doug Foster > > The malicious client of a private registry can no longer attack > unilaterally. If he manipulates his DMARC settings to direct evaluators to > the registrar's organizational domain, the attack is expected to fail, > either because (a) the registrar publishes OrgsBelow>0, or (b) the > evaluator checks the PSL, gets a lower-level result for the organization > domain, and uses the lower-risk longer domain, > > Doug > > > > On Wed, Apr 20, 2022 at 8:40 AM Scott Kitterman <[email protected]> > > wrote: > > No. We went through all this before and that's not correct. Tree walk is > > no worse than the PSL for private registries. For public registries it is > > in many cases much better. In many cases IANA has contractual control > > that > > is much stronger than any management controls in the PSL. > > > > There's nothing the IETF can do to prevent customer hostile registrars > > from doing hostile things. > > > > I think the fundamental error is to assume the PSL is static. It's not. > > > > In terms of the concerns you've expressed, is there any issue you see with > > the tree walk that isn't equally a problem if the putative hostile > > registrar asks for a change in the PSL? > > > > Scott K > > > > On April 20, 2022 10:56:01 AM UTC, Douglas Foster < > > > > [email protected]> wrote: > > >This is a fundamental flaw in the design, not a problem to be fixed on a > > >case-by-case basis. > > > > > >Under the tree walk, any private registry client can impersonate the > > > > parent > > > > >or a sibling, simply by publishing a non-org DMARC policy and then > > >letting > > >the tree walk proceed into the parent organization. Yes, the parent > > >organization can prevent this using its own DMARC policy, but it is > > > > foolish > > > > >to assume that all of them will. Wherever the opportunity exists, > > >malicious domain owners can be expected to use it. and the Michael Hammer > > >testimony is that they have already done so when the PSL had an > > >omissioin. > > > > > >Private registries are a significant complication to understanding the > > >effectiveness of DMARC evaluation, and yet the document still does not > > >discuss their existence or their potential security considerations. > > > > > >The case against the PSL has been heavy on generalities but weak on > > >specifics. The appropriate solution is to use DNS entries to provide a > > >check on PSL mistakes and omissions. When a DNS entry specifies a lower > > >alignment point (more restrictive relaxed alignment), the evaluator > > >should > > >use the DNS value. If the PSL specifies a lower alignment point, the > > >DNS > > >entry may be malicious. So the evaluatror would be wise to use the more > > >restrictive st the PSL entry for an initial message, and then make an > > >investigate to determine if he wants to establish a local policy to trust > > >the higher alignment point in DNS. When the DNS is being used to > > >validate > > >the PSL rather than replacing it, we have alternate algorithm options > > > > which > > > > >are more efficient than a full tree walk. > > > > > >In summary, there is no good reason to discard the PSL completely, and no > > >compelling reason to believe that DNS by itself can ever provide a > > >sufficient solution. > > > > > >.Doug > > > > > > > > > > > > > > > > > > > > >On Tue, Apr 19, 2022 at 11:12 PM Scott Kitterman <[email protected]> > > > > > >wrote: > > >> Thanks. > > >> > > >> I think this is pretty much the same list John published before. I > > > > think > > > > >> there is a little bit of outreach to do while we're working on > > >> DMARCbis, > > >> but > > >> it's not a major issue. Some of these are false positives. As an > > > > example: > > >> gov.scot > > >> service.gov.scot > > >> > > >> Are both on the PSL. It's true that under the new tree walk approach > > >> other > > >> parts of the government of Scotland could impersonate service.gov.scot, > > >> but I > > >> don't think it's a major risk. > > >> > > >> This is part of the reason I'd like to see the WG get an early > > > > assignment > > > > >> from > > >> IANA for the psd tag. Once that's done, we (and I will work on this) > > > > can > > > > >> start contacting both the PSL and above PSL entities with DMARC records > > >> about > > >> updating them to use it. The meantime, any lower level entity for > > >> these > > >> PSDs > > >> that has a problem would be able to publish psd=n and stop it. > > >> > > >> Scott K > > >> > > >> On Tuesday, April 19, 2022 8:18:53 PM EDT Douglas Foster wrote: > > >> > Scott asked for my list, so it is attached. I walked up the tree > > > > from > > > > >> the > > >> > > >> > private registries, then did a DNS lookup for a DMARC entry. > > >> > > > >> > Consequently, the list shows the domains with DMARC policies, at > > >> > > >> whatever > > >> > > >> > level, rather than the PSL entry itself. > > >> > > > >> > Doug > > >> > > > >> > > > >> > On Tue, Apr 19, 2022 at 12:00 AM Scott Kitterman < > > > > [email protected]> > > > > >> > wrote: > > >> > > On Monday, April 18, 2022 10:14:37 PM EDT Douglas Foster wrote: > > >> > > > Concern 1 > > >> > > > Of the several thousand private registry domains listed in the > > > > PSL, > > > > >> 45 > > >> > > >> > > have > > >> > > > > >> > > > DMARC policies at or above the registry point. 40 of these 45 > > >> > > >> specify > > >> > > >> > > > relaxed alignment for both DKIM and SPF. Upon activation of the > > > > tree > > > > >> > > walk, > > >> > > > > >> > > > these policies will be treated as organizational domains to any > > >> > > >> private > > >> > > >> > > > registry clients that have not published their own psd=y policy. > > >> > > > > >> > > Because > > >> > > > > >> > > > of relaxed alignment, these private registry clients will be able > > > > to > > > > >> > > > impersonate their siblings and parents and produce a DMARC result > > > > of > > > > >> > > PASS. > > >> > > > > >> > > Please provide your list of ones you think might be problematic. > > >> > > > > >> > > > Concern 2 > > >> > > > Since the longest current PSL entry has 5 segments, the longest > > >> > > > organizational domain is 6 segments. The "jump to 5" logic > > >> > > > needs > > >> > > >> to be > > >> > > >> > > > changed to "jump to 6". > > >> > > > > >> > > What PSL entries that are 5 long are you worried about? When we > > >> > > >> looked at > > >> > > >> > > this before, 5 seemed sufficient. Changing the number, now, isn't > > >> > > a > > >> > > >> big > > >> > > >> > > deal. > > >> > > > > >> > > > Concern 3 > > >> > > > The "psd=u" language is inconsistent. Which is true? > > >> > > > "This token indicates that this policy is not an organizational > > >> > > >> domain,, > > >> > > >> > > > the organizational domain is above this point" > > >> > > > or > > >> > > > "This token indicates no usable information, proceed with the > > >> > > >> heuristic > > >> > > >> > > to > > >> > > > > >> > > > determine if this policy is the organizational domain" > > >> > > > > >> > > It should be the latter. If we're inconsistent, please propose > > >> > > >> corrected > > >> > > >> > > text. > > >> > > > > >> > > Scott K > > >> > > > > >> > > > Doug Foster > > >> > > > > > >> > > > On Sun, Apr 17, 2022 at 4:54 PM Scott Kitterman < > > >> > > >> [email protected]> > > >> > > >> > > > wrote: > > >> > > > > I've finished going through this and also updated authheaders > > > > [1] > > > > >> to > > >> > > >> > > > > match. It > > >> > > > > now has a script called dmarc-policy-find which you can used to > > >> > > > > >> > > determine > > >> > > > > >> > > > > the > > >> > > > > DMARC policy to be applied for a domain. You can use RFC 7489, > > > > RFC > > > > >> > > 7489 + > > >> > > > > >> > > > > RFC > > >> > > > > 9091, and DMARCbis-07. > > >> > > > > > > >> > > > > It does currently cheat and assume psd=y is in the records for > > >> > > >> domains > > >> > > >> > > on > > >> > > > > >> > > > > the > > >> > > > > PSD DMARC registry list, since no one has actually published > > > > that > > > > >> yet. > > >> > > >> > > > > Scott K > > >> > > > > > > >> > > > > [1] https://github.com/ValiMail/authentication-headers (also on > > >> > > >> pypi) > > >> > > >> > > > > On Wednesday, April 6, 2022 12:27:04 PM EDT Scott Kitterman > > > > wrote: > > >> > > > > > I believe it does. > > >> > > > > > > > >> > > > > > Thanks, > > >> > > > > > > > >> > > > > > Scott K > > >> > > > > > > > >> > > > > > On April 6, 2022 2:53:59 PM UTC, Todd Herr > > >> > > > > > > >> > > > > <[email protected]> wrote: > > >> > > > > > >I believe this rev has the proposed text that was submitted > > > > in > > > > >> > > various > > >> > > > > >> > > > > > >messages in the thread titled "*5.5.4. Publish a DMARC > > >> > > > > > >Policy > > >> > > >> for > > >> > > >> > > the > > >> > > > > >> > > > > > >Author Domain - dmarcbis-06"* > > >> > > > > > > > > >> > > > > > >On Wed, Apr 6, 2022 at 10:51 AM <[email protected]> > > >> > > >> wrote: > > >> > > > > > >> A New Internet-Draft is available from the on-line > > >> > > > > > >> Internet-Drafts > > >> > > > > > >> directories. > > >> > > > > > >> This draft is a work item of the Domain-based Message > > >> > > > > >> > > Authentication, > > >> > > > > >> > > > > > >> Reporting & Conformance WG of the IETF. > > >> > > > > > >> > > >> > > > > > >> Title : Domain-based Message > > > > Authentication, > > > > >> > > > > Reporting, > > >> > > > > > > >> > > > > > >> and Conformance (DMARC) > > >> > > > > > >> > > >> > > > > > >> Authors : Todd M. Herr > > >> > > > > > >> > > >> > > > > > >> John Levine > > >> > > > > > >> > > >> > > > > > >> Filename : draft-ietf-dmarc-dmarcbis-07.txt > > >> > > > > > >> Pages : 62 > > >> > > > > > >> Date : 2022-04-06 > > >> > > > > > >> > > >> > > > > > >> Abstract: > > >> > > > > > >> This document describes the Domain-based Message > > >> > > > > >> > > Authentication, > > >> > > > > >> > > > > > >> Reporting, and Conformance (DMARC) protocol. > > >> > > > > > >> > > >> > > > > > >> DMARC permits the owner of an email author's domain > > > > name to > > > > >> > > enable > > >> > > > > >> > > > > > >> verification of the domain's use, to indicate the > > >> > > > > > >> Domain > > >> > > > > >> > > Owner's > > >> > > > > >> > > > > > >> or > > >> > > > > > >> Public Suffix Operator's message handling preference > > >> > > >> regarding > > >> > > >> > > > > failed > > >> > > > > > > >> > > > > > >> verification, and to request reports about use of the > > >> > > >> domain > > >> > > >> > > name. > > >> > > > > >> > > > > > >> Mail receiving organizations can use this information > > > > when > > > > >> > > > > evaluating > > >> > > > > > > >> > > > > > >> handling choices for incoming mail. > > >> > > > > > >> > > >> > > > > > >> This document obsoletes RFC 7489. > > >> > > > > > >> > > >> > > > > > >> The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > > > >> > > > > > >> There is also an HTML version available at: > > >> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-07.html > > >> > > >> > > > > > >> A diff from the previous version is available at: > > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-07 > > >> > > >> > > > > > >> Internet-Drafts are also available by rsync at > > > > rsync.ietf.org > > > > >> > > > > > >> :internet-drafts > > >> > > > > > >> > > >> > > > > > >> _______________________________________________ > > >> > > > > > >> dmarc mailing list > > >> > > > > > >> [email protected] > > >> > > > > > >> https://www.ietf.org/mailman/listinfo/dmarc > > >> > > > > > > > >> > > > > > _______________________________________________ > > >> > > > > > dmarc mailing list > > >> > > > > > [email protected] > > >> > > > > > https://www.ietf.org/mailman/listinfo/dmarc > > >> > > > > > > >> > > > > _______________________________________________ > > >> > > > > dmarc mailing list > > >> > > > > [email protected] > > >> > > > > https://www.ietf.org/mailman/listinfo/dmarc > > >> > > > > >> > > _______________________________________________ > > >> > > dmarc mailing list > > >> > > [email protected] > > >> > > https://www.ietf.org/mailman/listinfo/dmarc > > >> > > >> _______________________________________________ > > >> dmarc mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
