Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
On 7/23/20 8:07 AM, Joseph Brennan wrote: >> I think that we just have to agree that From-munging by MLMs is a permanent >> reality. It needs to be documented more prominently (and promoted as part >> of the DMARC marketing) so that implementations are more consistent, so that >> un-munging tactics and/or MUA behavior can be consistently implemented. >> > I'd be happier for the proposed standard to say that DMARC policy > "SHOULD NOT" be compromised by rewriting From lines-- and see how that > goes over. My reasoning is that blessing the practice makes it easier > for bad actors to craft spoofed mail and get it accepted. The opposite > of the purpose of DMARC, isn't it? (sorry, I forgot to reply earlier) I realize that your worry is valid if anyone attempted to un-munge the messages and then use the un-munged state somehow to validate authenticity. I assume that un-munging would only be attempted locally if the message passes DMARC and is trusted by local policy. (Similarly, as I've suggested in other contexts, it would be nice if the Receiver could preemptively communicate this trust to the Intermediary so that the munging didn't need to occur in the first place and ARC could come to fuition, but I digress.) As others have said, munged messages sent via a MLM aren't much different than someone posting to a web form and it then distributing the post to a set of email recipients. That web form isn't expecting to be able to use the author's domain, and the pattern it uses in the Friendly From is somewhat arbitrary and could be co-opted by spammers. I don't think that bad actors crafting is a huge worry since I think that in both scenarios it would just fall back on the reputation of the domain (and other factors). (just spit balling... it's getting late on a Friday...) Perhaps an interesting local policy enforcement (to get at your concern) would be to require that messages with certain Friendly From patterns to be DMARC aligned (regardless of policy) since I could assume that any MLM (that I care about) that's DMARC aware enough to munge would also have aligned SPF and/or DKIM results. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Fri, 31 Jul 2020, Jesse Thompson wrote: I think they want their IT staff to deploy an email system and policies that work the way they would expect. They want their organization to be seen as secure, so they don't want to be on the Buzzfeed list of Fortune 500 companies that have neglected to secure their domains with DMARC. Well, that's the problem, isn't it? If your expectations for e-mail are shaped by experience with paper mail and you don't realize how different an organization's internal highly controlled mail system is from e-mail on the outside, you're inevitably going to be surprised, sometimes unpleasantly. I would like for us to avoid the Yes Minister Tautology: We must do something, this is something, therefore we must do this. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] non-mailing list use case for differing header domains
In article you write: >I think you're right, and isn't the market indicating that there is demand for >DMARC designed for other usage patterns? e.g. >Would the CEO of any of those fortune 500 companies like the idea of their >personal address being spoofed? I dunno. Would they like the idea of mail their assistants send out for them being silently discarded because it's falsely tagged as being "spoofed"? R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] LSAP - Lightweight Signer Authorization Protocol methodology
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: - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. - 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
Re: [dmarc-ietf] non-mailing list use case for differing header domains
On Wed 29/Jul/2020 19:34:48 +0200 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."
[...]
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:dmarc-...@isdg.net;
ruf=mailto:dmarc-...@isdg.net;
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
Isn't that overly complicated? Why SHA1? An alternative method to authorize
3rd parties is RHSWLs, 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.
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.
Best
Ale
--
[*] https://mailarchive.ietf.org/arch/msg/dmarc/jQlUhE-ijiWeb1CybKy6367eVn8
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
