Re: [dmarc-ietf] Why Relaxed Alignment?

[Jesse Thompson]

Correct. ESPs need to process async bounces to help their customers adhere to 
best practices. The only way to do that (for a rfc5322.from domain which 
typically has MX pointed at a mailbox host) is to use a return path subdomain 
with MX pointed at the ESP.

Strict DKIM alignment would be easier to consider requiring since individual 
selectors can be delegated easily.

Jesse 

On Wed, Oct 18, 2023, at 3:45 PM, Neil Anuskiewicz wrote:
> 
> 
> 
>> On Oct 18, 2023, at 7:24 AM, Todd Herr 
>>  wrote:
>> 
>> On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster 
>>  wrote:
>>> Why do we need to support relaxed alignment at all?
>>> 
>> 
>> A common use case for relaxed alignment is when an organization (e.g., 
>> WeSellStuff) employs a third party Email Service Provider (e.g., 
>> WeSendEmail) to send mail on the organization's behalf. In that case, we 
>> might have the following:
>> 
>> Return-Path domain: bounces.wesellstuff.com
>> DKIM signing domain: wesendemail.wesellstuff.com
>> RFC5322.From domain: marketing.wesellstuff.com
>> 
>> The above configuration allows for WeSendEmail to manage the SPF record for 
>> bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to 
>> be pointed at WeSendEmail, so that they can handle bounce processing and 
>> other Delivery Status Notifications.
>> 
>> It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using a 
>> dedicated subdomain that is delegated to WeSendEmail, which can publish the 
>> public key in DNS and generate the private key and keep it private to use 
>> for signing mail it sends. 
>> 
>> Meanwhile, WeSellStuff only has to delegate responsibility for those parts 
>> of the DNS that are specific to WeSendEmail's sending to WeSendEmail.
> 
> Yes, strict alignment would be *very* disruptive to a LOT of senders.
> ___
> 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] Why Relaxed Alignment?

[Neil Anuskiewicz]

On Oct 18, 2023, at 7:24 AM, Todd Herr  wrote:On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster  wrote:Why do we need to support relaxed alignment at all?A common use case for relaxed alignment is when an organization (e.g., WeSellStuff) employs a third party Email Service Provider (e.g., WeSendEmail) to send mail on the organization's behalf. In that case, we might have the following:Return-Path domain: bounces.wesellstuff.comDKIM signing domain: wesendemail.wesellstuff.comRFC5322.From domain: marketing.wesellstuff.comThe above configuration allows for WeSendEmail to manage the SPF record for bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to be pointed at WeSendEmail, so that they can handle bounce processing and other Delivery Status Notifications.It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using a dedicated subdomain that is delegated to WeSendEmail, which can publish the public key in DNS and generate the private key and keep it private to use for signing mail it sends. Meanwhile, WeSellStuff only has to delegate responsibility for those parts of the DNS that are specific to WeSendEmail's sending to WeSendEmail.Yes, strict alignment would be *very* disruptive to a LOT of senders.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Why Relaxed Alignment?

[Murray S. Kucherawy]

On Tue, Oct 17, 2023 at 6:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Why do we need to support relaxed alignment at all?
>

Because the charter says:

   The working group will seek to preserve interoperability with the
   installed base of DMARC systems, and provide detailed justification
   for any non-interoperability.

Dropping "relaxed" would be a move squarely against this constraint.

For that matter, it says right after that:

   [...] it will seek to maintain the
   end-to-end nature of existing identifier fields in mail, in
   particular avoiding solutions that require rewriting of originator
   fields.

...which looks a lot like telling lists to just do From rewriting to solve
all of their related problems so that they can comply with the new world
order also has a high bar that needs justification.

So if we want to start advocating for either thing, and we believe there's
consensus to do so, please start proposing such supporting text.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Why Relaxed Alignment?

[Todd Herr]

On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Why do we need to support relaxed alignment at all?
>
>
A common use case for relaxed alignment is when an organization (e.g.,
WeSellStuff) employs a third party Email Service Provider (e.g.,
WeSendEmail) to send mail on the organization's behalf. In that case, we
might have the following:

Return-Path domain: bounces.wesellstuff.com
DKIM signing domain: wesendemail.wesellstuff.com
RFC5322.From domain: marketing.wesellstuff.com

The above configuration allows for WeSendEmail to manage the SPF record for
bounces.wesellstuff.com and for an MX record for bounces.wesellstuff.com to
be pointed at WeSendEmail, so that they can handle bounce processing and
other Delivery Status Notifications.

It also allows for WeSendEmail to DKIM sign on behalf of WeSellStuff using
a dedicated subdomain that is delegated to WeSendEmail, which can publish
the public key in DNS and generate the private key and keep it private to
use for signing mail it sends.

Meanwhile, WeSellStuff only has to delegate responsibility for those parts
of the DNS that are specific to WeSendEmail's sending to WeSendEmail.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*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] Why Relaxed Alignment?

[Seth Blank]

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 
> wrote:
>
>>
>>
>> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely 
>> wrote:
>> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
>> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely 
>> 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 

Re: [dmarc-ietf] Why Relaxed Alignment?

[Douglas Foster]

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  wrote:

>
>
> On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely 
> wrote:
> >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote:
> >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely 
> wrote:
> >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote:
>  On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely 
> 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
>
>