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: some...@example.com
Sender: a...@example.net
The DMARC record at example.com:
v=DMARC1; p=reject; snd=lst.rhswl.example; rua=mailto:r...@example.com;
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
