Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On April 12, 2023 9:51:14 AM UTC, Alessandro Vesely wrote: >On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote: >> >> >> On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote: >>> On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: > On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: >> I don't feel strongly about N=10, but I do feel strongly that N=5 is >> insufficient. My gut feel is that 6 or 7 is likely more than enough to >> cover all real world examples, but it's a gut feel only and not backed >> by data. > > IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 > (instead of 4), and then say that N=5 is the value we currently consider > good but recommend to make it configurable. Or we could leave the text > as is (if it's easier to understand it that way) and just recommend to > not hardcode "5" and "4". I don't think everyone picking their own N is going to promote interoperability. >>> >>> It would, as long as subsequent standard revisions suggest different >>> values, and people more or less follow. Compare with suggested/ >>> recommended RSA key lengths. >> >> I don't think that's an apt comparison, but even if it were, what's the >> advantage of making the outcome of record lookups less consistent? > > >Not getting stuck in hard-coded limits, like 10 lookups for SPF, for example. If we'd written N lookups where N=10 instead of 10 lookups, the impact on the installed base would be no different. We'll publish a new RFC and everyone will update their systems in no time isn't a thing. It's also not a topic I think it's useful to spend time on, so I'm out of this thread. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote: On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote: On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: I don't feel strongly about N=10, but I do feel strongly that N=5 is insufficient. My gut feel is that 6 or 7 is likely more than enough to cover all real world examples, but it's a gut feel only and not backed by data. IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then say that N=5 is the value we currently consider good but recommend to make it configurable. Or we could leave the text as is (if it's easier to understand it that way) and just recommend to not hardcode "5" and "4". I don't think everyone picking their own N is going to promote interoperability. It would, as long as subsequent standard revisions suggest different values, and people more or less follow. Compare with suggested/ recommended RSA key lengths. I don't think that's an apt comparison, but even if it were, what's the advantage of making the outcome of record lookups less consistent? Not getting stuck in hard-coded limits, like 10 lookups for SPF, for example. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote: >On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: >> On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: >>> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: I don't feel strongly about N=10, but I do feel strongly that N=5 is insufficient. My gut feel is that 6 or 7 is likely more than enough to cover all real world examples, but it's a gut feel only and not backed by data. >>> >>> IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 >>> (instead of 4), and then say that N=5 is the value we currently consider >>> good but recommend to make it configurable. Or we could leave the text as >>> is (if it's easier to understand it that way) and just recommend to not >>> hardcode "5" and "4". >> >> I don't think everyone picking their own N is going to promote >> interoperability. > > >It would, as long as subsequent standard revisions suggest different values, >and people more or less follow. Compare with suggested/ recommended RSA key >lengths. > I don't think that's an apt comparison, but even if it were, what's the advantage of making the outcome of record lookups less consistent? Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: I don't feel strongly about N=10, but I do feel strongly that N=5 is insufficient. My gut feel is that 6 or 7 is likely more than enough to cover all real world examples, but it's a gut feel only and not backed by data. IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then say that N=5 is the value we currently consider good but recommend to make it configurable. Or we could leave the text as is (if it's easier to understand it that way) and just recommend to not hardcode "5" and "4". I don't think everyone picking their own N is going to promote interoperability. It would, as long as subsequent standard revisions suggest different values, and people more or less follow. Compare with suggested/ recommended RSA key lengths. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On Saturday, April 8, 2023 9:49:24 AM EDT John Levine wrote: > It appears that Seth Blank said: > >So how do we handle this? What’s the worst case? Looking at the above > >example, the longest “complex org” would be 5 labels long. I think we’ve > >already agreed, backed by data from the PSL, that the longest PSD would be > >4 labels long. ... > > > >To be clear, due to the current policy discovery mechanics (check author > >domain then jump to organizational domain), I'm not aware of any of these > >complex orgs setting dmarc policies on Author Domains at such a depth. i.e. > >N=5 today would not break anything currently in place. However, the tree > >walk now enables these complex orgs to set policy much deeper in their > >hierarchy, which would then potentially not work as expected and possibly > >send reports to the wrong destination due to the current N=5. > > I wouldn't object to 7 but I would like to see a stronger justification than > "nobody needs it now but someone might want it later." I've been considering my reply to Seth's original email (and was about to write it when this came in). Ultimately, I think Seth's concern isn't a DMARC problem since it's really an internal organizational routing problem. As I understand the issue, Seth's concern isn't that reports aren't sent, but that they will not go to the right part of a super complex organization. I don't think that's a problem we should try to solve. I think we can prove up to 5 is needed, so going a little further as a mitigation for future uncertainty is OK, but I agree we should have more than hand waving to get beyond that. I'm not certain we need to change it, but 6 or 7 is something I could live with. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
It appears that Seth Blank said: >So how do we handle this? What’s the worst case? Looking at the above >example, the longest “complex org” would be 5 labels long. I think we’ve >already agreed, backed by data from the PSL, that the longest PSD would be >4 labels long. ... >To be clear, due to the current policy discovery mechanics (check author >domain then jump to organizational domain), I'm not aware of any of these >complex orgs setting dmarc policies on Author Domains at such a depth. i.e. >N=5 today would not break anything currently in place. However, the tree >walk now enables these complex orgs to set policy much deeper in their >hierarchy, which would then potentially not work as expected and possibly >send reports to the wrong destination due to the current N=5. I wouldn't object to 7 but I would like to see a stronger justification than "nobody needs it now but someone might want it later." R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: >On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: >> I don't feel strongly about N=10, but I do feel strongly that N=5 is >> insufficient. My gut feel is that 6 or 7 is likely more than enough to cover >> all real world examples, but it's a gut feel only and not backed by data. > > >IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 >(instead of 4), and then say that N=5 is the value we currently consider good >but recommend to make it configurable. Or we could leave the text as is (if >it's easier to understand it that way) and just recommend to not hardcode "5" >and "4". > I don't think everyone picking their own N is going to promote interoperability. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: I don't feel strongly about N=10, but I do feel strongly that N=5 is insufficient. My gut feel is that 6 or 7 is likely more than enough to cover all real world examples, but it's a gut feel only and not backed by data. IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then say that N=5 is the value we currently consider good but recommend to make it configurable. Or we could leave the text as is (if it's easier to understand it that way) and just recommend to not hardcode "5" and "4". Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
