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

[Hector Santos <[e-mail]>]

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.


-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos