Re: [dmarc-ietf] non-mailing list use case for differing header domains

[Jesse Thompson <[e-mail]>]

On 7/29/20 12:34 PM, Hector Santos wrote:
> On 7/28/2020 1:19 PM, Doug Foster wrote:
>> Hector, I do not understand this comment:
>>
>> "The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains. DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going dilemma."
>>
> 
> SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.
> 
> The problem we have with DMARC was the same with SSP which was replaced by ADSP which attempted to ignore the problem. Generally, as it often done with ambiguous issues in the IETF, we ignore it, we make it out of scope, we keep it open ended, etc.  It just wasn't resolved and ADSP was abandoned but returned as DMARC but it also kept the same 3rd party ignorance as ADSP did.   If this issue is not resolved for DMARC, I see an interesting situation during DMARCBis Last Call explaining how we abandoned ADSP for having problem XYZ and then reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ.
> 
>> Domains that participate with a mailing list have the option of including the ML servers in their SPF record, or delegating them a DKIM scope and key.    But to obtain that authorization from the sending domain, someone would have to ask for it, and might not receive the desired answer.
>>
>> The goal of this discussion is to find a way to coerce trust.   We do not lack ways to grant trust on request.
> 
> This issue is not about the known, but the unknown. We don't have an issue with proactive authorization and whitelisting methods.
> 
> I've been in this DKIM project for 15+ years, and to me, the goal has also been to find a reasonable, scalable deterministic protocol that will handle unsolicited, unknown 3rd party domain signers. Not necessarily unknown in a bad sense, unknown that you don't know anything about them. So you ask the author, "Hey, is this 3rd party signer ok?"
> 
> SPF allows 3rd party IP declarations.  DKIM POLICY model does not offer this capability.
> 
> We have DKIM Policy extension proposals like ATPS (RFC6541) that offers a deterministic method to associate the author domain with 3rd party signer domains.   This authorization is defined by the Originating, Author Domain.
> 
> Look at my DMARC record for my isdg.net domain:
> 
> v=DMARC1; p=reject; atps=y; rua=mailto:[e-mail]; ruf=mailto:[e-mail];
> 
> The atps=y tells an ATPS compliant receiver that if it sees a 3rd party domain signature:
> 
>   Author Domain IS NOT EQUAL TO Signer Domain
> 
> Then it can do a ATPS look:
> 
>    base32(sha1(SIGNER-DOMAIN))._atps.isdg.net
> 
> So if I wanted to authorized bayviewphysicians.com to be able to sign for me, I would go to the wizard https://secure.winserver.com/public/wcdmarc,  enter your domain in the list of authorized signers, click Zone Record and I get a record I can add to my isdg.net zone:
> 
> e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps  TXT ("v=atps01; d=bayviewphysicians.com;")
> 
> So anyone out there can see that I authorized bayviewphysicians.com to sign for isdg.net
> 
> It is really sample.
> 
> Whether we can "coerce" receivers to honor any of this is a different situation.  In general, all you can do create a PROTOCOL that makes good engineering sense and usable by the IETF community. If not, then generally systems will ignore it.

I admittedly know nothing about ATPS, but I think its fundamental problem is that it authorizes 3rd parties at the domain level and that makes it not much better than SPF, just different.  

Email domains that have more than a few users don't want to authorize every potential 3rd party (converges quickly to all of them, for large/complex organizations) to sign as every user/address in the domain.  Even if SPF didn't have the 10 DNS lookup limitation, I would not choose put every 3rd party into our domains' SPF records.  I'd essentially be authorizing most of the [legitimate] internet to use the domains.

Ironically, you'll notice some domains actually doing this via SPF record flattening and macros specifically because they do not even want to attempt to solve the 3rd party authorization problem (look at umich.edu).

On the other hand, something like ATPS might be a partial solution for the MLM header munging problem, at least for intra-organizational email leveraging 3rd party platforms.  e.g. If I authorize only mlm.wisc.edu (and not every subdomain, so aspf=r is not an option) to send as wisc.edu (and potentially all of our ~480 domains which aren't all subdomains of wisc.edu), then the MLM platform should know that it doesn't need to rewrite the From header for messages from users in those domains.

It's kind of the inverse of the ARC dillemma.  ARC is missing a mechanism to tell an Intermediary if it will be safe to *not* rewrite the From header, and the lack of having a mechanism to convey historical or intended trust means that Intermediaries will always need to munge all email, by default.

Jesse