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
