Re: [dmarc-ietf] what to document about the tree walk
On Fri 15/Jul/2022 21:28:09 +0200 Scott Kitterman wrote: On July 15, 2022 6:26:39 PM UTC, "John R. Levine" wrote: On Fri, 15 Jul 2022, Alessandro Vesely wrote: +1 from me too. Note, though, that the (current) DNS is accidentally correct most of the time, as far as our Tree Walk is concerned. No, it's not an accident. We designed the tree walk based on our knowledge of the way people publish DMARC records. +1. I was going to write something along these lines, but John got to it first. PSL is the accidentally correct approach. The DMARCbis design is aligned to how DMARC works. I don't understand this unwearying opposition irrespective of the argument. If you do a tree walk NOW (which is why I said currently) you have exactly 0 probability to determine an abnormal PSD, since the tag hasn't been assigned yet. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On July 15, 2022 6:26:39 PM UTC, "John R. Levine" wrote: >On Fri, 15 Jul 2022, Alessandro Vesely wrote: >> +1 from me too. Note, though, that the (current) DNS is accidentally >> correct most of the time, as far as our Tree Walk is concerned. > >No, it's not an accident. We designed the tree walk based on our knowledge of >the way people publish DMARC records. +1. I was going to write something along these lines, but John got to it first. PSL is the accidentally correct approach. The DMARCbis design is aligned to how DMARC works. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Fri, 15 Jul 2022, Alessandro Vesely wrote: +1 from me too. Note, though, that the (current) DNS is accidentally correct most of the time, as far as our Tree Walk is concerned. No, it's not an accident. We designed the tree walk based on our knowledge of the way people publish DMARC records. Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Thu 14/Jul/2022 17:12:19 +0200 Murray S. Kucherawy wrote: On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman wrote: I think a choice within DMARCbis is a bad idea. Effectively the choice exists. Evaluators will have the choice to stay with an RFC 7489 design or to upgrade to DMARCbis. The incentive to upgrade is not clear. DMARC filters can run based on an obsolete version of the PSL with no inconvenience, for a different flavor of "upgrade". Indeed, according to John's figures, we could have done without any psd= tag. Using obsolete data is a bug, not a feature. Or using data that is accidentally correct most of the time, where alternatives are available. Either way, +1. +1 from me too. Note, though, that the (current) DNS is accidentally correct most of the time, as far as our Tree Walk is concerned. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy wrote: > On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman > wrote: > >> >> I think a choice within DMARCbis is a bad idea. Effectively the >> choice exists. Evaluators will have the choice to stay with an RFC 7489 >> design or to upgrade to DMARCbis. >> > >> >The incentive to upgrade is not clear. DMARC filters can run based on >> an obsolete version of the PSL with no inconvenience, for a different >> flavor of "upgrade". Indeed, according to John's figures, we could have >> done without any psd= tag. >> > >> Using obsolete data is a bug, not a feature. >> > > Or using data that is accidentally correct most of the time, where > alternatives are available. Either way, +1. > > >Doug's idea of checking the results is a means to draw the attention of >> operators on both the PSL version they use and its agreement with the DNS >> at large. New implementations could be encouraged to track the differences >> and produce some kind of report about them. IME, although running a very >> small mail site, it does happen to hit some PSL entry, a fact which I >> realized by chance —browsing the logs— so I cannot tell figures. >> > >> What would operators do with such a report? Receivers tracking sender >> configuration issues and reporting issues back to them is a very 1990s >> approach to making the Internet work. I don't think it's relevant to >> anything useful these days. >> > > If we think this is important data to put in front of people, this WG > could do that sort of survey once there are implementations and include the > result in an appendix, or put it in the WG's wiki or in the IETF's > collection of implementation reports: > https://www.ietf.org/how/runningcode/implementation-reports/ > > It sounds like we're mostly there already given the analysis John did > previously. > > >> We can't get rid of the PSL without getting rid of the PSL. >> >> >> >> There's no way to constrain it within the document. If we have a >> 'choice', we are essentially signing up the IETF to a future effort to >> produce an update to actually get rid of it. >> > >> >Right, that would be the Internet Standard. >> >> Not really. To drop functionality going to Internet Standard, don't you >> have to show it's not used? How would that even work? >> > > RFC 2026 lays out the criteria for progressing a Proposed Standard to a > Draft Standard and then to Internet Standard, and RFC 6410 later > consolidated the latter two. The criterion to which I think you're > referring asserts that any unused features need to be removed before a > protocol can advance. However, RFC 7489 is not a Proposed Standard, so > we're not constrained by that here. > > In any case, I agree that the longer the PSL remains in the equation, the > longer we have to keep it, due to both inertia and growth of the deployed > base. > > My understanding is that the IETF, based on past experiences, doesn't do >> flag days where everyone has to switch to some new thing by a specific date. >> > > I think that's right, though Barry's memory on this might be better than > mine. At a minimum, they're exceedingly rare. A working group or other > community pushing for a flag day needs to have quite a bit of momentum to > make it work. > > >> Currently we don't have any procedural requirement for backward >> compatibility, since RFC 7489 isn't an IETF document. Based on the working >> group charter and good engineering practice we should limit changes that >> affect existing deployments, but we have more flexibility now than we will >> ever have again. >> >> In my view, standardizing two ways to do policy discovery and alignment >> would be a substantial danger to interoperability and we'd be stuck with it >> approximately forever. >> > > +1 to this, for the reasons John gave in the email right below this one > that just came in. > > Bite the bullet and mark use of the PSL historical for DMARC. As has been pointed out, there will always be a long tail but we are talking rare corner cases where the results from the two approaches diverge. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman wrote: > >> I think a choice within DMARCbis is a bad idea. Effectively the choice > exists. Evaluators will have the choice to stay with an RFC 7489 design or > to upgrade to DMARCbis. > > > >The incentive to upgrade is not clear. DMARC filters can run based on an > obsolete version of the PSL with no inconvenience, for a different flavor > of "upgrade". Indeed, according to John's figures, we could have done > without any psd= tag. > > > Using obsolete data is a bug, not a feature. > Or using data that is accidentally correct most of the time, where alternatives are available. Either way, +1. >Doug's idea of checking the results is a means to draw the attention of > operators on both the PSL version they use and its agreement with the DNS > at large. New implementations could be encouraged to track the differences > and produce some kind of report about them. IME, although running a very > small mail site, it does happen to hit some PSL entry, a fact which I > realized by chance —browsing the logs— so I cannot tell figures. > > What would operators do with such a report? Receivers tracking sender > configuration issues and reporting issues back to them is a very 1990s > approach to making the Internet work. I don't think it's relevant to > anything useful these days. > If we think this is important data to put in front of people, this WG could do that sort of survey once there are implementations and include the result in an appendix, or put it in the WG's wiki or in the IETF's collection of implementation reports: https://www.ietf.org/how/runningcode/implementation-reports/ It sounds like we're mostly there already given the analysis John did previously. >> We can't get rid of the PSL without getting rid of the PSL. > >> > >> There's no way to constrain it within the document. If we have a > 'choice', we are essentially signing up the IETF to a future effort to > produce an update to actually get rid of it. > > > >Right, that would be the Internet Standard. > > Not really. To drop functionality going to Internet Standard, don't you > have to show it's not used? How would that even work? > RFC 2026 lays out the criteria for progressing a Proposed Standard to a Draft Standard and then to Internet Standard, and RFC 6410 later consolidated the latter two. The criterion to which I think you're referring asserts that any unused features need to be removed before a protocol can advance. However, RFC 7489 is not a Proposed Standard, so we're not constrained by that here. In any case, I agree that the longer the PSL remains in the equation, the longer we have to keep it, due to both inertia and growth of the deployed base. My understanding is that the IETF, based on past experiences, doesn't do > flag days where everyone has to switch to some new thing by a specific date. > I think that's right, though Barry's memory on this might be better than mine. At a minimum, they're exceedingly rare. A working group or other community pushing for a flag day needs to have quite a bit of momentum to make it work. > Currently we don't have any procedural requirement for backward > compatibility, since RFC 7489 isn't an IETF document. Based on the working > group charter and good engineering practice we should limit changes that > affect existing deployments, but we have more flexibility now than we will > ever have again. > > In my view, standardizing two ways to do policy discovery and alignment > would be a substantial danger to interoperability and we'd be stuck with it > approximately forever. > +1 to this, for the reasons John gave in the email right below this one that just came in. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Thu, 14 Jul 2022, Scott Kitterman wrote: In my view, standardizing two ways to do policy discovery and alignment would be a substantial danger to interoperability and we'd be stuck with it approximately forever. I agree, it's a self-evidently terrible idea. "Temporary" transition periods inevitably turn out to be permanent, or so close to permanent that we'll all be dead before it's over. What I expect to happen is that we publish 7489bis with the tree walk as the method to find org domains*. There are a handful of widely used libraries that implmenent DMARC, most of which have developers who read this list or are otherwise people we know, so we can encourage them to update their software. Large providers like Google and Microsoft have their own implementations but we know them too. So over perhaps a year the places that upgrade their software will get new libraries and start to use the tree walk. There will always be a long tail of sites that never update their software, but that's life. Fortunately, for the majority of normal mail the old and new methods get the same result, so it's unlikely the long tail will run into problems any worse than they already have with the obsolete software they use, e.g. TLS 1.1 making STARTTLS fail. R's, John * and occasionally PSDs. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On July 14, 2022 12:11:57 PM UTC, Alessandro Vesely wrote: >On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote: >> On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" >> wrote: >>> Once again, participating only: >>> On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote: [...] >>> 3) The critical question is whether we can treat the PSL as replaced without obtaining the markers first. On this issue, John and I have a different assessment of the risk. I can accept a solution which lays out the assumptions and risks to the evaluator, and lets them decide what to do. This is what sections 4.7. and 4.8 in my text from Sunday night attempted to do. >>> >>> My suggestion would be that if we are going to offer a choice, there should >>> be some eventual path toward convergence rather than an open-ended period >>> of people doing either. Otherwise, the PSL will be a part of DMARC for far >>> longer than we'd like. >> >> I think a choice within DMARCbis is a bad idea. Effectively the choice >> exists. Evaluators will have the choice to stay with an RFC 7489 design or >> to upgrade to DMARCbis. > > >The incentive to upgrade is not clear. DMARC filters can run based on an >obsolete version of the PSL with no inconvenience, for a different flavor of >"upgrade". Indeed, according to John's figures, we could have done without >any psd= tag. > Using obsolete data is a bug, not a feature. >Doug's idea of checking the results is a means to draw the attention of >operators on both the PSL version they use and its agreement with the DNS at >large. New implementations could be encouraged to track the differences and >produce some kind of report about them. IME, although running a very small >mail site, it does happen to hit some PSL entry, a fact which I realized by >chance —browsing the logs— so I cannot tell figures. What would operators do with such a report? Receivers tracking sender configuration issues and reporting issues back to them is a very 1990s approach to making the Internet work. I don't think it's relevant to anything useful these days. > >> We can't get rid of the PSL without getting rid of the PSL. >> >> There's no way to constrain it within the document. If we have a 'choice', >> we are essentially signing up the IETF to a future effort to produce an >> update to actually get rid of it. > > >Right, that would be the Internet Standard. Not really. To drop functionality going to Internet Standard, don't you have to show it's not used? How would that even work? My understanding is that the IETF, based on past experiences, doesn't do flag days where everyone has to switch to some new thing by a specific date. Currently we don't have any procedural requirement for backward compatibility, since RFC 7489 isn't an IETF document. Based on the working group charter and good engineering practice we should limit changes that affect existing deployments, but we have more flexibility now than we will ever have again. In my view, standardizing two ways to do policy discovery and alignment would be a substantial danger to interoperability and we'd be stuck with it approximately forever. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote: On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" wrote: Once again, participating only: On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote: [...] 3) The critical question is whether we can treat the PSL as replaced without obtaining the markers first. On this issue, John and I have a different assessment of the risk. I can accept a solution which lays out the assumptions and risks to the evaluator, and lets them decide what to do. This is what sections 4.7. and 4.8 in my text from Sunday night attempted to do. My suggestion would be that if we are going to offer a choice, there should be some eventual path toward convergence rather than an open-ended period of people doing either. Otherwise, the PSL will be a part of DMARC for far longer than we'd like. I think a choice within DMARCbis is a bad idea. Effectively the choice exists. Evaluators will have the choice to stay with an RFC 7489 design or to upgrade to DMARCbis. The incentive to upgrade is not clear. DMARC filters can run based on an obsolete version of the PSL with no inconvenience, for a different flavor of "upgrade". Indeed, according to John's figures, we could have done without any psd= tag. Doug's idea of checking the results is a means to draw the attention of operators on both the PSL version they use and its agreement with the DNS at large. New implementations could be encouraged to track the differences and produce some kind of report about them. IME, although running a very small mail site, it does happen to hit some PSL entry, a fact which I realized by chance —browsing the logs— so I cannot tell figures. We can't get rid of the PSL without getting rid of the PSL. There's no way to constrain it within the document. If we have a 'choice', we are essentially signing up the IETF to a future effort to produce an update to actually get rid of it. Right, that would be the Internet Standard. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
We can limit the transition period by specifying a date, after which any untagged record is interpreted with strict alignment. On Wed, Jul 13, 2022, 11:10 AM Murray S. Kucherawy wrote: > Once again, participating only: > > On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> [...] >> > >> 2) I believe that the document needs a vigorous explanation of why the >> PSL needs to be replaced. I made a stab at the effort in the text that I >> sent Sunday night. Murray's text here is more comprehensive. But we >> need something. We are asking evaluators to undertake a change which >> requires effort and any change creates multiple risks. >> > > I don't know about "vigorous", but I think some tutorial would be useful > given the wide variability of experience in the ultimate audience. An > appendix would suffice. > > >> 3) The critical question is whether we can treat the PSL as replaced >> without obtaining the markers first. On this issue, John and I have a >> different assessment of the risk. I can accept a solution which lays out >> the assumptions and risks to the evaluator, and lets them decide what to >> do. This is what sections 4.7. and 4.8 in my text from Sunday night >> attempted to do. >> > > My suggestion would be that if we are going to offer a choice, there > should be some eventual path toward convergence rather than an open-ended > period of people doing either. Otherwise, the PSL will be a part of DMARC > for far longer than we'd like. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
It appears that Murray S. Kucherawy said: >There is indeed more of a burden on sending domains and registry operators >to publish the needed markers in the DNS before this will all work the way >we want it to. ... Not really. If a mail sender has a DMARC record at its org domain, and there are no DMARC records above the org domain, things will work correctly, no psd tag needed. I expect that in practice this will happen 100% of the time, rounding to the closest 0.01%. That's why it is not a problem that popular TLDs like .com, .org, and .net will never publish a DMARC record, with or without psd=y. There are at least 200 million registered domains but less than 1 domains in the PSL. For PSDs, we are talking about one domain in 20,000, or about 0.005% of registered domains. Having surveyed all of the domains in the PSL to see which ones publish DMARC records, I can report that the ones where the lack of a psd tag might plausibly cause problems can be counted on your fingers. Some of those already have np= tags which tells us they're aware of what's going on. (See for example _dmarc.uk.com.) The tree walk works fine. The psd tag is an arcane nit, mostly useful to a handful of TLDs like .bank and .insurance that want to use the aggregate reports to audit their registrants' mail configuration. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
Whois vs RDAP isn't the issue. PII about registrants has been restricted by ICANN policy since GDPR. Barry On Wed, Jul 13, 2022 at 11:04 AM Murray S. Kucherawy wrote: > > On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote: >> >> Uh? manuals recommend to look up WHOIS to determine the owner of >> domains reported to suffer lame delegation and contact them... >> Nowadays, contacts for domain names are not available that way. >> >> We could hijack reporting addresses, though. > > > Since WHOIS is obsolete, you could try RDAP. If that doesn't work, use the > email address that's part of the SOA record (which is what it's for, really; > see 3.3.13 of RFC 1035). Still, automation of such notifications runs the > risk of generating a lot of unwanted email, so we would really need to > undertake such an effort carefully. > > -MSK > ___ > 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
Re: [dmarc-ietf] what to document about the tree walk
On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" wrote: >Once again, participating only: > >On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> [...] >> > >> 2) I believe that the document needs a vigorous explanation of why the PSL >> needs to be replaced. I made a stab at the effort in the text that I sent >> Sunday night. Murray's text here is more comprehensive. But we need >> something. We are asking evaluators to undertake a change which requires >> effort and any change creates multiple risks. >> > >I don't know about "vigorous", but I think some tutorial would be useful >given the wide variability of experience in the ultimate audience. An >appendix would suffice. > > >> 3) The critical question is whether we can treat the PSL as replaced >> without obtaining the markers first. On this issue, John and I have a >> different assessment of the risk. I can accept a solution which lays out >> the assumptions and risks to the evaluator, and lets them decide what to >> do. This is what sections 4.7. and 4.8 in my text from Sunday night >> attempted to do. >> > >My suggestion would be that if we are going to offer a choice, there should >be some eventual path toward convergence rather than an open-ended period >of people doing either. Otherwise, the PSL will be a part of DMARC for far >longer than we'd like. I think a choice within DMARCbis is a bad idea. Effectively the choice exists. Evaluators will have the choice to stay with an RFC 7489 design or to upgrade to DMARCbis. We can't get rid of the PSL without getting rid of the PSL. There's no way to constrain it within the document. If we have a 'choice', we are essentially signing up the IETF to a future effort to produce an update to actually get rid of it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
Once again, participating only: On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > [...] > > 2) I believe that the document needs a vigorous explanation of why the PSL > needs to be replaced. I made a stab at the effort in the text that I sent > Sunday night. Murray's text here is more comprehensive. But we need > something. We are asking evaluators to undertake a change which requires > effort and any change creates multiple risks. > I don't know about "vigorous", but I think some tutorial would be useful given the wide variability of experience in the ultimate audience. An appendix would suffice. > 3) The critical question is whether we can treat the PSL as replaced > without obtaining the markers first. On this issue, John and I have a > different assessment of the risk. I can accept a solution which lays out > the assumptions and risks to the evaluator, and lets them decide what to > do. This is what sections 4.7. and 4.8 in my text from Sunday night > attempted to do. > My suggestion would be that if we are going to offer a choice, there should be some eventual path toward convergence rather than an open-ended period of people doing either. Otherwise, the PSL will be a part of DMARC for far longer than we'd like. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Wed, Jul 13, 2022 at 3:05 AM Alessandro Vesely wrote: > Uh? manuals recommend to look up WHOIS to determine the owner of > domains reported to suffer lame delegation and contact them... > Nowadays, contacts for domain names are not available that way. > > We could hijack reporting addresses, though. > Since WHOIS is obsolete, you could try RDAP. If that doesn't work, use the email address that's part of the SOA record (which is what it's for, really; see 3.3.13 of RFC 1035). Still, automation of such notifications runs the risk of generating a lot of unwanted email, so we would really need to undertake such an effort carefully. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Tue 12/Jul/2022 17:12:40 +0200 John Levine wrote: A.6 seems to be dealing with a different subject. I can still sketch some text to be added there, though. I attach the diff. I realize this is getting repetitive but: -- PSDs are very, very rare, and users will generally never see them That doesn't entail developers can generally skip considering them. -- long discussions of PSDs will just confuse people You keep reiterating this concern, to which I try and conform without fully understanding it. At the same time, the opposite concern, that people acting as PSD won't publish as needed, is neglected. The lack of a full explanation will motivate people to write interpretations and suggestions of their own --the same reaction which is motivating me now. -- I don't even think these examples get the tree walk right. I tried to interpret the current draft. Please correct me where I'm wrong. For convenience, I paste the relevant text below. Hence, this change is not an improvement. I don't plan to argue further unless we see more support for this very bad idea. Even if it's not an improvement, I think some points deserve a bit of discussion. For example, the current draft allows psd.example.com to skip defining any DMARC record at all, which wouldn't work. The text (minor change: s/NODATA// and fix a typo): A.6.2. Tree Walk Example Let's now make a corner case example, where "psd.example.com" operates as a public suffix domain. That is, it delegates subdomains to third parties. "Example.com" itself is a regular domain and has its own DMARC record: _dmarc.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-feedb...@example.com; "Psd.example.com" is the kind of domain that the PSL would list as private domains, as opposed to ICANN domains. Most public suffix domains (PSD) don't publish a DMARC record. In this example, "psd.example.com" should publish a record, declaring its role as a PSD: _dmarc.psd.example.com IN TXT "v=DMARC1; psd=y; p=reject" Finally, let's consider a customer "rockabilly.psd.example.com". This is a regular domain, register under a private PSD. It can have a DMARC record too: _dmarc.rockabilly.psd.example.com IN TXT "v=DMARC1; p=none; rua=mailto:el...@rockabilly.psd.example.com; Now, assuming that any other subdomain of "example.com" has no DMARC record,let's consider some message cases: Case 1: Author Domain: example.com SPF-authenticated Identifier: mail.example.com DKIM-authenticated Identifier: example.com To verify alignment, the receiver looks up the records for all three labels, getting NXDOMAIN for "_dmarc.mail.example.com" and for "_dmarc.com". "Example.com" is the organizational domain of all three identifier. Therefore they are all aligned. Case 2: Author Domain: psd.example.com SPF-authenticated Identifier: mail.psd.example.com DKIM-authenticated Identifier: rockabilly.psd.example.com This message won't pass, because it is badly engineered as if "psd.example.com" were an independent organization. It is not. It is a subdomain of "example.com", albeit its being used as a base for independent domains. For the Author Domain, "psd.example.com" is the starting point, so the tree walk doesn't stop even if it finds psd=y. Lookups for the remaining labels bring to the conclusion that the organizational domain is "example.com". For SPF, "mail.psd.example.com" is the organizational domain, as it is the label before the one with psd=y. It is not aligned. Similarly, "rockabilly.psd.example.com" is --correctly-- considered the organizational domain and is not aligned. Case 3: Author Domain: rockabilly.psd.example.com SPF-authenticated Identifier: mail.rockabilly.psd.example.com DKIM-authenticated Identifier: rockabilly.psd.example.com TBD Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
1) I believe that replacing the PSL is a good thing, if it is done with markers present. The domain owner is the best source of information about the organization boundaries. We MUST provide him with a way to communicate that knowledge in DNS, and a compliant implementation MUST find and use that information when it is present. 2) I believe that the document needs a vigorous explanation of why the PSL needs to be replaced. I made a stab at the effort in the text that I sent Sunday night. Murray's text here is more comprehensive. But we need something. We are asking evaluators to undertake a change which requires effort and any change creates multiple risks. 3) The critical question is whether we can treat the PSL as replaced without obtaining the markers first. On this issue, John and I have a different assessment of the risk. I can accept a solution which lays out the assumptions and risks to the evaluator, and lets them decide what to do. This is what sections 4.7. and 4.8 in my text from Sunday night attempted to do. Doug On Wed, Jul 13, 2022 at 1:12 AM Murray S. Kucherawy wrote: > Hatless once again. > > On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> The tree walk solves the problem IF the policy has boundary information >> provided by the domain owner. Without that, aren't we substituting one >> insufficiently reliable solution for another insufficiently reliable one? >> > > Another way to look at it: The PSL was never designed to provide the > information for which DMARC has been using it. Hanging DMARC on it was a > reasonable thing for a proof of concept, which is what RFC 7489 really was; > it happens to give the right answer most of the time, but that's something > of a coincidence. Here we're taking control over the input to the > Organizational Domain and Policy Discovery algorithms, which is a more > defensible way to do things if you're heading for the Standards Track. > > The tree walk also eliminates any concern that two compliant operators are > using different versions of the input data. There is no guarantee that my > copy of the PSL is any more or less up to date than yours is, leading us > both to different determinations about the very same message. But once > we're using the DNS for this, then, other than staleness caused by > short-term caching, we're all talking about the same thing. > > There is indeed more of a burden on sending domains and registry operators > to publish the needed markers in the DNS before this will all work the way > we want it to. My view is that the working group perceives the risk of > continued use of the PSL to be less favorable than taking on that burden. > The tree walk has been a goal for years. > > Changes to nodes in the DNS tree are visible immediately; changes to the > PSL take an unknown amount of time to be published and deployed globally. > > Changes to the DNS are made by the operator in charge of the name(s) being > updated; as far as I'm aware, changes to the PSL are made by a limited > community not involved in (or perhaps even interested in, or cognizant of) > DMARC. > > If we want a migration period, some kind of hybrid model might work: Do > the DNS tree walk, but at each step, if you find you've hit a name that's > present in the PSL, you can stop and pretend you found a marker you're > looking for. When those markers are all (or mostly) actually published, > then stop doing that. For bonus points, find some non-DoS way to notify > those operators that they really should be publishing the missing markers. > (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to > remember that SPF had a not-so-great transition plan, so we need to be > careful how we craft this one. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Wed 13/Jul/2022 07:12:25 +0200 Murray S. Kucherawy wrote: If we want a migration period, some kind of hybrid model might work: Do the DNS tree walk, but at each step, if you find you've hit a name that's present in the PSL, you can stop and pretend you found a marker you're looking for. When those markers are all (or mostly) actually published, then stop doing that. For bonus points, find some non-DoS way to notify those operators that they really should be publishing the missing markers. (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to remember that SPF had a not-so-great transition plan, so we need to be careful how we craft this one. Uh? manuals recommend to look up WHOIS to determine the owner of domains reported to suffer lame delegation and contact them... Nowadays, contacts for domain names are not available that way. We could hijack reporting addresses, though. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
Hatless once again. On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The tree walk solves the problem IF the policy has boundary information > provided by the domain owner. Without that, aren't we substituting one > insufficiently reliable solution for another insufficiently reliable one? > Another way to look at it: The PSL was never designed to provide the information for which DMARC has been using it. Hanging DMARC on it was a reasonable thing for a proof of concept, which is what RFC 7489 really was; it happens to give the right answer most of the time, but that's something of a coincidence. Here we're taking control over the input to the Organizational Domain and Policy Discovery algorithms, which is a more defensible way to do things if you're heading for the Standards Track. The tree walk also eliminates any concern that two compliant operators are using different versions of the input data. There is no guarantee that my copy of the PSL is any more or less up to date than yours is, leading us both to different determinations about the very same message. But once we're using the DNS for this, then, other than staleness caused by short-term caching, we're all talking about the same thing. There is indeed more of a burden on sending domains and registry operators to publish the needed markers in the DNS before this will all work the way we want it to. My view is that the working group perceives the risk of continued use of the PSL to be less favorable than taking on that burden. The tree walk has been a goal for years. Changes to nodes in the DNS tree are visible immediately; changes to the PSL take an unknown amount of time to be published and deployed globally. Changes to the DNS are made by the operator in charge of the name(s) being updated; as far as I'm aware, changes to the PSL are made by a limited community not involved in (or perhaps even interested in, or cognizant of) DMARC. If we want a migration period, some kind of hybrid model might work: Do the DNS tree walk, but at each step, if you find you've hit a name that's present in the PSL, you can stop and pretend you found a marker you're looking for. When those markers are all (or mostly) actually published, then stop doing that. For bonus points, find some non-DoS way to notify those operators that they really should be publishing the missing markers. (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to remember that SPF had a not-so-great transition plan, so we need to be careful how we craft this one. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On July 13, 2022 2:05:45 AM UTC, John Levine wrote: >It appears that Todd Herr said: >>On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster < >>dougfoster.emailstanda...@gmail.com> wrote: >> >>> What problem does this tree walk solve? Can anyone explain how this tree >>> walk improves on RFC7489 evaluation results? >>> >>> >>RFC 7489 acknowledged that its methods for discovering the organizational >>domain had shortcomings. ... > >While I agree with everything you said, I really hope we can avoid >wasting time relitigating decisions we've already made. Yes. Please! Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
It appears that Todd Herr said: >On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> What problem does this tree walk solve? Can anyone explain how this tree >> walk improves on RFC7489 evaluation results? >> >> >RFC 7489 acknowledged that its methods for discovering the organizational >domain had shortcomings. ... While I agree with everything you said, I really hope we can avoid wasting time relitigating decisions we've already made. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
The tree walk solves the problem IF the policy has boundary information provided by the domain owner. Without that, aren't we substituting one insufficiently reliable solution for another insufficiently reliable one? As I have said previously: errors in the PSL are expected to org-fragmenting and therefore inconvenient, while the tree walk errors are likely to be org-consolidating and therefore grievous. I do not see that we have changed the risk profile favorably. Please help. DF On Tue, Jul 12, 2022, 2:41 PM Todd Herr wrote: > On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> What problem does this tree walk solve? Can anyone explain how this tree >> walk improves on RFC7489 evaluation results? >> >> > RFC 7489 acknowledged that its methods for discovering the organizational > domain had shortcomings. > > https://datatracker.ietf.org/doc/html/rfc7489#section-3.2, which > described the method for determining the organizational domain, one reliant > on the PSL, included the sentence: > >The process of determining a suffix is currently a heuristic one. No >list is guaranteed to be accurate or current. > > https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.6, titled > Organizational Domain Discovery Issues, reads in part: > >The DNS does not provide a method by which the "domain of record", or > >the domain that was actually registered with a domain registrar, can > >be determined given an arbitrary domain name. Suggestions have been > >made that attempt to glean such information from SOA or NS resource > >records, but these too are not fully reliable, as the partitioning of > the >DNS is not always done at administrative boundaries. > >When seeking domain-specific policy based on an arbitrary domain > >name, one could "climb the tree", dropping labels off the left end of > >the name until the root is reached or a policy is discovered, but > >then one could craft a name that has a large number of nonsense > >labels; this would cause a Mail Receiver to attempt a large number of > >queries in search of a policy record. Sending many such messages >constitutes an amplified denial-of-service attack. > The tree walk, therefore, addresses the shortcomings acknowledged in RFC > 7489 and does so in a manner that addresses the denial-of-service attack > possibility by limiting the DNS queries to no more than five, regardless of > the name length. > > > > -- > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* todd.h...@valimail.com > *m:* 703.220.4153 > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Tue, Jul 12, 2022 at 1:30 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > What problem does this tree walk solve? Can anyone explain how this tree > walk improves on RFC7489 evaluation results? > > RFC 7489 acknowledged that its methods for discovering the organizational domain had shortcomings. https://datatracker.ietf.org/doc/html/rfc7489#section-3.2, which described the method for determining the organizational domain, one reliant on the PSL, included the sentence: The process of determining a suffix is currently a heuristic one. No list is guaranteed to be accurate or current. https://datatracker.ietf.org/doc/html/rfc7489#appendix-A.6, titled Organizational Domain Discovery Issues, reads in part: The DNS does not provide a method by which the "domain of record", or the domain that was actually registered with a domain registrar, can be determined given an arbitrary domain name. Suggestions have been made that attempt to glean such information from SOA or NS resource records, but these too are not fully reliable, as the partitioning of the DNS is not always done at administrative boundaries. When seeking domain-specific policy based on an arbitrary domain name, one could "climb the tree", dropping labels off the left end of the name until the root is reached or a policy is discovered, but then one could craft a name that has a large number of nonsense labels; this would cause a Mail Receiver to attempt a large number of queries in search of a policy record. Sending many such messages constitutes an amplified denial-of-service attack. The tree walk, therefore, addresses the shortcomings acknowledged in RFC 7489 and does so in a manner that addresses the denial-of-service attack possibility by limiting the DNS queries to no more than five, regardless of the name length. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
What problem does this tree walk solve? Can anyone explain how this tree walk improves on RFC7489 evaluation results? On Tue, Jul 12, 2022, 11:13 AM John R Levine wrote: > > A.6 seems to be dealing with a different subject. I can still sketch > some > > text to be added there, though. I attach the diff. > > I realize this is getting repetitive but: > > -- PSDs are very, very rare, and users will generally never see them > -- long discussions of PSDs will just confuse people > -- I don't even think these examples get the tree walk right. > > Hence, this change is not an improvement. I don't plan to argue further > unless we see more support for this very bad idea. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > 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
Re: [dmarc-ietf] what to document about the tree walk
A.6 seems to be dealing with a different subject. I can still sketch some text to be added there, though. I attach the diff. I realize this is getting repetitive but: -- PSDs are very, very rare, and users will generally never see them -- long discussions of PSDs will just confuse people -- I don't even think these examples get the tree walk right. Hence, this change is not an improvement. I don't plan to argue further unless we see more support for this very bad idea. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Mon 11/Jul/2022 21:54:25 +0200 John Levine wrote: On Mon, 11 Jul 2022, Alessandro Vesely wrote: We are proposing an alternative to the PSL without having any experience of it. I think a Proposed Standard should give full explanations of design choices, so that possible, future amendments can be thoughtful and considered. Could you explain, preferably in detail, why Appendix A.6 in the draft doesn't do that? A.6 seems to be dealing with a different subject. I can still sketch some text to be added there, though. I attach the diff. Best Ale -- <<< text/html; charset=UTF-8; name="Diff_draft-ietf-dmarc-dmarcbis-12.txt.html": Unrecognized >>> ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] what to document about the tree walk
On Mon, 11 Jul 2022, Alessandro Vesely wrote: We are proposing an alternative to the PSL without having any experience of it. I think a Proposed Standard should give full explanations of design choices, so that possible, future amendments can be thoughtful and considered. Could you explain, preferably in detail, why Appendix A.6 in the draft doesn't do that? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
