Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-12.txt
On Wed, Jul 6, 2022 at 7:34 AM 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-12.txt > Pages : 66 > Date: 2022-07-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. > Speaking as an AD now, you should expect me to complain about the "SHOULD" in Section 4.7. Specifically, since "SHOULD" ultimately permits a choice, we ought to [1] give implementers some guidance about when one might opt not to do what that "SHOULD" says, or in the alternative, make it a "MAY" or "MUST" (probably the latter?). This might also be true of other MUSTard in the document, but since I was just reviewing that section, it jumped out at me. -MSK [1] https://datatracker.ietf.org/doc/html/rfc6919 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] "psd=" tag early assignment
On Mon, Jul 11, 2022 at 5:57 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We should talk about "correct results". > > The PSL gets the correct results in 99-dot-something percent of messages, > but we are proposing a new algorithm because it is wrong on some fraction > of a percent. The size of the fraction is not a reason to ignore a > problem. I support a change. But is the proposed change an improvement? > You had me up until "because". I don't think the fact that the PSL is wrong in some cases is the single impetus to replace it. I mentioned in another message just now what I think the reasons are for pursuing a DNS solution. > We also think the proposed tree walk will also return a correct result in > 99-dot-something percent. But are they better answers? On what basis > would we answer that question? > I think it's hard to measure that until it's fully deployed, but I'm more drawn to the solution whose engineering and operation is easier to describe and justify, even if it's occasionally wrong (because it's easier to fix). What matters is whether the new algorithm produces correct answers when the > PSL produces wrong ones, and whether it does this without introducing new > errors that are not present in the PSL solution. On that question, the > answer is at best uncertain. When the PSL and Tree Walk produce different > results, we simply have no basis for choosing between the two, because the > proposed Tree Walk is sourced on no new information. > Suppose they do give different answers. Irrespective of which one is actually right, I think it's easier for me to explain the DNS answer and why it might be wrong than have to explain in full why the PSL got it wrong, or why fixing it is not a matter of editing my own DNS records. > However, when the Tree Walk result is based on explicit tagging > provided by the domain owner, then we do have a better answer than the PSL, > because the domain owner knows more about his organizational structure than > the PSL volunteers, and we have every reason to trust the domain > owner's assertions. > > [...] > Right. Note this, too, from the PSL's own web site, emphasis theirs: -- snip -- Some use the PSL to determine what is a valid domain name and what isn't. *This is dangerous*. gTLDs and ccTLDs are constantly updating, coming and going - and certainly not static. If the PSL is incorporated in a static manner, and your software does not regularly receive PSL updates, it will erroneously think that valid TLDs are not valid, or conversely treat decommissioned TLDs that should be invalid as valid. The DNS should be the proper source for this information, despite the performance benefits of some local source to pre-empt network latency. If you must use the PSL for this purpose, please do not bake static copies of the PSL into your software without update mechanisms that are frequently checking for its frequent updates and incorporating them. -- snip -- If I'm a serious email receiver (and currently I am not employed by one), this would scare me off of using the PSL completely, and I would seek to develop or subscribe to some kind of DNS solution. -MSK ___ 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
