I’m sorry— the entire ecosystem only uses relaxed alignment. What
operational concern, per charter, are you concerned about? This is what
people do, and we’ve already discussed the data as a working group.
Seth, as Chair, and confused
On Tue, Oct 17, 2023 at 18:51 Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Why do we need to support relaxed alignment at all?
>
> When a domain is suddenly harmed by a PSL error, the necessary fix is to
> implement same-domain policies with same-domain signatures. The
> appropriate technique to prevent that problem, before it happens, is
> exactly the same configuration. This configuration strategy remains in
> effect as long as any imperfect version of the PSL is in use. After that,
> it will persist if tbe TreeWalk ever produces incorrect results. It is
> simply in the domain owner's interest to avoid relaxed alignment and the
> dependency that it creates on an imperfect PSL,
>
> It is also in the evaluator's interest to avoid relaxed alignment.
> Relaxed alignment requires more processing overhead under any algorithm,
> while increasing risk. Relaxed alignment, using a domain policy and
> sibling authentication, is simply not the same risk profile as strict
> alignment using a same-domain policy.
>
> A domain that is not signing its messages is not serious about
> authentication. When adding signatures to a server, configuring a
> same-domain signature should be exactly the same effort as using a
> non-matching one. In fact, a super-majority of aligned signatures already
> provide strict alignment for exactly that reason. Relaxed alignment
> primarily serves to sanctify SPF results and thereby make DKIM appear
> unnecessary.
>
> Instead of asking evaluators to undertake a new design with new overhead,
> we should tell domain owners to do the right thing: provide proof of
> authenticity that can be verified quickly and easily by evaluators. Those
> requirements are met by strict alignment with same-domain policies, and
> anything less is deprecated. Relaxed alignment will continue being
> accepted as long as evaluators grant grace, but domain owners should not
> assume that they will do so forever. We have proven that relaxed alignment
> provides only sloppy security. Building a better version of sloppy will
> not fix the mess.
>
> Doug Foster
>
>
>
>
> On Tue, Oct 17, 2023, 2:41 PM Scott Kitterman <skl...@kitterman.com>
> wrote:
>
>>
>>
>> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely <ves...@tana.it>
>> wrote:
>> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely <ves...@tana.it>
>> wrote:
>> >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
>> >>>> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely <
>> ves...@tana.it> wrote:
>> >>>>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote:
>> >>>>>> Thank you, sir. That’s part of the reason to cautiously transition
>> away from the PSL. It has the feel of a throwback to a time when people
>> thought the number of total users would be in the hundreds or thousands.
>> Wouldn’t a cautious transition alleviate your concerns? Not everyone,
>> everywhere will pull the switch at midnight.
>> >>>>>
>> >>>>> Can we engage ICANN for sending a kind request to upgrade their
>> DMARC records to all PSDs? Or can we do it on their behalf? Or on IETF
>> behalf? Or?
>> >>>>>
>> >>>>> Is that a subject for 118?
>> >>>>
>> >>>> Which ICANN managed TLDs have DMARC records (PSDs which are either
>> not TLDs or not ICANN managed TLDs are not anything ICANN has anything to
>> say about)?
>> >>>
>> >>> According to Doug's file:
>> >>>
>> >>> ale@pcale:~/tmp/zdkimfilter/regdom$ for d in $(grep -v '^[/* ]'
>> icann_public_suffix_list.dat); do l=$(grep "^$d,"
>> PSL_entries_with_DMARC_policies.csv); if [ -n "$l" ]; then echo "$d -> $l";
>> fi done
>> >>> ...
>> >>> [list elided]
>> >>> ...
>> >>
>> >> Unless I missed one, none of those are TLDs except gov and mil and all
>> of the rest are under CC TLDs, so doubly nothing to do with ICANN. ICANN
>> doesn't manage gov and mil, but they both have psd=y in their records
>> already, so I'm not sure why they are even on the list.
>> >
>> >
>> >Ok, those are PSDs, not TLDs. They are in the ICANN part of the PSL.
>> Does that imply they have nothing to do with ICANN?!?
>> >
>> >If ICANN cannot help, we can as well consider the so-called private
>> domains of the PSL.
>> >
>> >DMARCbis assumes that PSOs include this tag with a value of 'y' to
>> indicate that the domain is a PSD. Indeed, Section 5.6 specifies:
>> >
>> > In addition to the DMARC Domain Owner actions, if a PSO publishes a
>> DMARC
>> > record it MUST include the psd tag (see Section 5.3) with a value of
>> 'y'
>> > ("psd=y").
>> >
>> >Non-compliance in this case affects all independent subdomains of those
>> PSL domains. Admittedly, they are not so frequently met. However, before
>> switching from PSL to Tree Walk, operators would probably want to see at
>> least a (significant) part of those set their tags, no?
>> >
>>
>> Nothing in the PSL has anything to do with ICANN.
>>
>> Most of those don't have independent sub-domains, so no, most is not
>> relevant.
>>
>> If I were updating an implementation to support DMARCbis, I might want to
>> consider that, but it has nothing to do with actually developing the
>> updated standard, which is what I thought we were trying to do.
>>
>> Scott K
>>
>> _______________________________________________
>> 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
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
