[dmarc-ietf] LSAP - Lightweight Signer Authorization Protocol methodology

[Hector Santos <[e-mail]>]

On 7/31/2020 4:06 AM, Alessandro Vesely wrote:
>> hector wrote:
>>
>>     base32(sha1(SIGNER-DOMAIN))._atps.isdg.net

> Isn't that overly complicated?

I don't think so, but sure, it is not 100% "Low Code."  A hash 
"calculator" is needed.

> Why SHA1?

The intent was for a lightweight hashing that won't produce long 
hashing tags or labels or subdomains. Whats the maximum length of a 
domain?

But mainly because Murray's ATPS was based off Doug Otis's TPA-LABEL 
which used the same hashing algorithm.

   DKIM Third-Party Authorization Label
   https://tools.ietf.org/html/draft-otis-dkim-tpa-label-06

Doug provided a portable C-based TPA-Label calculator source code in 
Appendix B.

ATPS was the "simpler" version of TPA-Label. TPA-label was a little 
complex for a period when it was extremely challenging in the DKIM WG 
to get a Author::Signer relationship endorsed. Remember, we were 
dealing with push back even the 1st party DNS lookup policy.

There was general agreement TPA-Label offer more scalability. ATPS was 
just simpler to plug and play, explore and test the proof of concept 
and that it did.

> An alternative method to authorize 3rd parties is RHSWLs,

Let me (re)state I believe in a "Black Box" functional design and 
engineering.  I am not stuck on ATPS.  It is about the functional 
methodology for an Author::Signer association, a "Lightweight Signer 
Authorization Protocol" or LSAP.  We had the same with LMAP 
"Lightweight MTA Authorization Protocol."  Maybe LSAP can do for 
DMARC, what LMAP did for SPF.  But imo, we need to get consensus with 
a LSAP methodology.  With consensus, a specific method can be worked out.

> see my previous post[*].  By
> comparison with the above quote, assume we have:
>
>      From: [e-mail]
>      Sender: [e-mail]
>
> The DMARC record at example.com:
>
>    v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:[e-mail];
>
> The snd=lst.rhswl.example tells a compliant receiver that if it sees a
> 3rd party authentication (either SPF or DKIM) of the Sender domain:,
> where:
>
>      From: domain IS NOT EQUAL TO Sender: domain
>
> Then it can do a right-hand side whitelist lookup:
>
>      example.net.lst.rhswl.example
>
> If the record exists, then example.net is authorized to send on behalf
> of example.com.

Sure, again, imo, we need a BLACK BOX "LSAP" methodology to be work 
out. see below.

> Features:
>
> * Absence of cryptographic stuff (sha1) makes it simpler.
>
> * A multi-domain bank (Autumn's example) can easily build its own
> RHSWL containing all and only their domains, e.g.:
>
>    firstbrand.com.lst.mainbrand.com  IN A 127.0.0.2
>    secondbrand.com.lst.mainbrand.com IN A 127.0.0.2
>
> * Large free-email domains can build their own RHSWL so as to avoid
> the MLM problem.
>
> * Lazy mail domains can easily point to a public RHSWL which lists
> almost all the legitimate Internet.
>
> * Strictly transactional domains can still keep snd=none (the default).
>
> * Experimenting domains can have p=none; snd=lst.in-progress.example;
> while they monitor aggregate reports to see how their list is doing.

Do you have a I-D? If not, why not write up the draft proposal so it 
can better reviewed and maybe even explored?

Based on discussions, it sounds this LSAP model would include author, 
signer, sender identities:

     Authorized := LSAP(Author, Signer, Sender)

This was the same idea with LMAP for SPF.

     Authorized := LMAP(IP, Domain)

In SPF, the LMAP function is called Check_Host() with arguments:

    <ip>     - the IP address of the SMTP client that is emitting
               the mail, either IPv4 or IPv6.

    <domain> - the domain that provides the sought-after authorization
               information; initially, the domain portion of the
               "MAIL FROM" or "HELO" identity.

    <sender> - the "MAIL FROM" or "HELO" identity.


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