Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Dotzero]

On Thursday, August 20, 2020, Jesse Thompson  wrote:

> On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote:
> > Neither atps or spf include are really designed for large scale usage
>
> That's my conclusion, as well.  I don't want to authorize every potential
> MLM to use all addresses in all of our domains cart blanch, even if I would
> otherwise trust them (e.g. their purported ARC results).
>
> I *do* want to authorize our *own* MLM(s) to use our own domains for
> *internal* use... so I thought for a minute... maybe ATSP has merit for
> small scale usage, as an alternative to SPF include?  But no, I don't know
> if any MLM has a way to check to see if they are authorized via any
> mechanism, so they will continue to munge the From header for our
> DMARC-enabled domains anyway.  So, for this *internal* use case, maybe I'll
> just check the ARC result from the trusted MLM and replace the From header
> with the value of Reply-to/X-Original-From, and call it a day.
>
> Jesse
>

This is why I proposed a tag that would have a value consisting of the
authorized intermediary domain. It would only be valid for that message.
Because the tag is signed separately from the rest of the message, it
should survive even if the intermediary modifies other parts of the
message. If the intermediary DKIM signs the modified message with their own
signature, that provides some assurance to the receiver.

I haven't seen enough favorable response to justify working on a detailed
submission to the group. I'm not an IETF standards wonk.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Jesse Thompson]

On 8/20/20 4:00 PM, blong=40google@dmarc.ietf.org wrote:
> Neither atps or spf include are really designed for large scale usage

That's my conclusion, as well.  I don't want to authorize every potential MLM 
to use all addresses in all of our domains cart blanch, even if I would 
otherwise trust them (e.g. their purported ARC results).

I *do* want to authorize our *own* MLM(s) to use our own domains for *internal* 
use... so I thought for a minute... maybe ATSP has merit for small scale usage, 
as an alternative to SPF include?  But no, I don't know if any MLM has a way to 
check to see if they are authorized via any mechanism, so they will continue to 
munge the From header for our DMARC-enabled domains anyway.  So, for this 
*internal* use case, maybe I'll just check the ARC result from the trusted MLM 
and replace the From header with the value of Reply-to/X-Original-From, and 
call it a day.

Jesse 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Brandon Long]

On Thu, Aug 20, 2020 at 1:36 PM Tim Draegen  wrote:

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy 
> wrote:
>
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  wrote:
>
>> I am wondering whether companies like Dmarcian could implement third-pary
>> whitelisting.  As they receive and analyze DMARC aggregate reports on
>> behalf of many mail sites, they probably are able to distinguish various
>> level of authentication failures, from mailing lists to misaligned ESPs, to
>> actual abusers.  In that case, they could maintain a whitelist tailored for
>> any given client.  The client would set, say:
>>
>> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
>> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
>> [...]
>>
>
> Having spent a lot of time and energy building a DKIM-based reputation
> system that (IMHO) showed promise, I made it available for people to try
> for free.  There was no uptake, even after presenting its promising results
> in places like M3AAWG.  Times may have changed, but in retrospect I think
> there are too many "what-ifs" for add-ons of this nature to be seen as
> feasible.  The issues seem to be:
>
>
> Hi MSK, hi Ale,
>
> I can second that MSK's DKIM-based reputation system is amazing. From
> where I sit, it's like a flying saucer that humans just haven't figured out
> how to fuel quite yet. I believe that fuel comes from widespread adoption
> of domain-based email authentication aka DMARC. The challenge of getting
> the email universe to embrace something like DMARC feels at times
> impossible, but the fact is it just takes a lot of coordination,
> dedication, and consistent levels of exercise to stay sane.
>
> That said, Ale, I like the idea of a Domain Owner being able to share some
> sort of exception list for email flows that are recognized by the Domain
> Owner, but are still (for various reasons) beyond the ability of the Domain
> Owner to address. Something like, "I've got a vendor that will never send
> DMARC-compliant email on my behalf". It appeals to my fondness to be able
> to Just Fix Things without having to bother anyone. I don't think it would
> work, though, because it relies on email receivers having to widely
> implement new stuff, and it relies on Domain Owners accurately maintaining
> another thing. It's easier and more effective to get the vendor to do the
> right thing.
>
> Oh, on 2nd read (I've been consumed with the non-IETF world for a few
> months and only took this up because Ale emailed me at work).. I think
> keying off of "Sender:" is a really bad idea. Multiple policy keys into a
> single piece of email has never made sense.
> Third party authorization makes sense to me in theory as a tool for a very
> specific problem. In practice, people and organizations struggle to get
> first party authorization into place. Once they start to tackle their own
> first party authorization, the need for third party authorization tends to
> evaporate. What's left over? People that want to put together a list of
> authorized third parties but aren't quite ready to do their own first party
> auth?
>
> From a receiver's perspective, it then looks like the first party has no
> idea what it is doing (which is the default anti-spam stance for all
> Internet mail), so then the receiver is now looking at a bunch of factors
> unrelated to first-party auth.. including any third party authorization.
> EG, the receiver notes that the email is authorized by a third-party - a
> newsletter company. "First party" authorization is NOT established, so the
> receiver has to process the email based on the strength of the newsletter
> company's reputation (among other things). So then why bother at all with
> the construct of "third party authorization"?
>
> So I guess put me in the camp of not seeing utility in third party
> authorizations. Better to make the work that needs to be done as clear and
> as simple as possible.
>

I tend to agree with the negative stance on third party auth, but SPF
obviously has the include: statement which is third party auth at the most
basic level...
atps[1] is the obvious equivalent for DKIM.  I don't know if atps failed
because it wasn't all that useful, or if it was tied in folks minds to
adps, or the failure of the follow-on reputation system stuff..

Neither atps or spf include are really designed for large scale usage
across thousands of "relays" etc, and I don't think they should be used for
that, but for a bunch of small to medium entities, it could be the thing
that makes higher p= possible.

Brandon

[1] I just looked atps again, but I might have missed something that makes
it less useful
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Tim Draegen]

> On Aug 20, 2020, at 2:16 PM, Murray S. Kucherawy  wrote:
> 
> On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  > wrote:
> I am wondering whether companies like Dmarcian could implement third-pary 
> whitelisting.  As they receive and analyze DMARC aggregate reports on behalf 
> of many mail sites, they probably are able to distinguish various level of 
> authentication failures, from mailing lists to misaligned ESPs, to actual 
> abusers.  In that case, they could maintain a whitelist tailored for any 
> given client.  The client would set, say:
> 
> _dmarc.client.domain.example IN TXT "v=DMARC1; 
> rua=mailto:client...@ag.dmarcian.com ; 
> snd=client-id.rhswl.dmarcian.com ; 
> [...]"
> [...]
> 
> Having spent a lot of time and energy building a DKIM-based reputation system 
> that (IMHO) showed promise, I made it available for people to try for free.  
> There was no uptake, even after presenting its promising results in places 
> like M3AAWG.  Times may have changed, but in retrospect I think there are too 
> many "what-ifs" for add-ons of this nature to be seen as feasible.  The 
> issues seem to be:

Hi MSK, hi Ale,
I can second that MSK's DKIM-based reputation system is amazing. From where I 
sit, it's like a flying saucer that humans just haven't figured out how to fuel 
quite yet. I believe that fuel comes from widespread adoption of domain-based 
email authentication aka DMARC. The challenge of getting the email universe to 
embrace something like DMARC feels at times impossible, but the fact is it just 
takes a lot of coordination, dedication, and consistent levels of exercise to 
stay sane.

That said, Ale, I like the idea of a Domain Owner being able to share some sort 
of exception list for email flows that are recognized by the Domain Owner, but 
are still (for various reasons) beyond the ability of the Domain Owner to 
address. Something like, "I've got a vendor that will never send 
DMARC-compliant email on my behalf". It appeals to my fondness to be able to 
Just Fix Things without having to bother anyone. I don't think it would work, 
though, because it relies on email receivers having to widely implement new 
stuff, and it relies on Domain Owners accurately maintaining another thing. 
It's easier and more effective to get the vendor to do the right thing.

Oh, on 2nd read (I've been consumed with the non-IETF world for a few months 
and only took this up because Ale emailed me at work).. I think keying off of 
"Sender:" is a really bad idea. Multiple policy keys into a single piece of 
email has never made sense.

Third party authorization makes sense to me in theory as a tool for a very 
specific problem. In practice, people and organizations struggle to get first 
party authorization into place. Once they start to tackle their own first party 
authorization, the need for third party authorization tends to evaporate. 
What's left over? People that want to put together a list of authorized third 
parties but aren't quite ready to do their own first party auth?

From a receiver's perspective, it then looks like the first party has no idea 
what it is doing (which is the default anti-spam stance for all Internet mail), 
so then the receiver is now looking at a bunch of factors unrelated to 
first-party auth.. including any third party authorization. EG, the receiver 
notes that the email is authorized by a third-party - a newsletter company. 
"First party" authorization is NOT established, so the receiver has to process 
the email based on the strength of the newsletter company's reputation (among 
other things). So then why bother at all with the construct of "third party 
authorization"?

So I guess put me in the camp of not seeing utility in third party 
authorizations. Better to make the work that needs to be done as clear and as 
simple as possible.

=- Tim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Murray S. Kucherawy]

On Thu, Aug 20, 2020 at 1:59 AM Alessandro Vesely  wrote:

> I am wondering whether companies like Dmarcian could implement third-pary
> whitelisting.  As they receive and analyze DMARC aggregate reports on
> behalf of many mail sites, they probably are able to distinguish various
> level of authentication failures, from mailing lists to misaligned ESPs, to
> actual abusers.  In that case, they could maintain a whitelist tailored for
> any given client.  The client would set, say:
>
> _dmarc.client.domain.example IN TXT "v=DMARC1; rua=mailto:
> client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"
> [...]
>

Having spent a lot of time and energy building a DKIM-based reputation
system that (IMHO) showed promise, I made it available for people to try
for free.  There was no uptake, even after presenting its promising results
in places like M3AAWG.  Times may have changed, but in retrospect I think
there are too many "what-ifs" for add-ons of this nature to be seen as
feasible.  The issues seem to be:

- it has no hope of being universally accurate; participants have to accept
that false positives and false negatives will happen

- if it's perceived as effective, demand for this will skyrocket; the host
needs to be resilient to this

- participants have to trust the company providing the service to do so
reliably and honestly (e.g., no paying to be listed or get a reputation
boost)

- depending on failure modes, the host could become a DoS target; they need
to be resilient to this

- the "lag" to which you refer might be unacceptable in some situations;
participants need to be willing to tolerate this

- there will be demands for accuracy and timely responses; interfering with
someone's mail flow for whatever reason can draw unwanted legal attention
(e.g., MAPS)

I imagine large operators already have enough information to know where the
lists are, so for them this might be moot.  It's smaller operators without
the infrastructure to make such determinations in real time that need to
collaborate on something like this.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Call for Adoption: DMARC Use of the RFC5322.Sender Header Field

[David I]

During IETF 108, the chairs realized that there was interest in Dave's
RFC5322.Sender draft.

This starts a Call for Adoption for draft-crocker-dmarc-sender

The draft is available here: 
https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/

Currently, the draft is marked as "Standards Track".  The chairs feel if the
working group does adopt this, it should begin as "Experimental".  If we start
to see adoption of this work, this can be changed back to "Standards Track" 
before
Working Group Last Call.  Of course, we welcome input from the working group on 
this.

Please review this draft to see if you think it is suitable for adoption, and
send any comments to the list, clearly stating your view.

There's some good thinking in the document, that however leads me to a 
different solution space. There are also some bits which aren't clear enough 
for me to fully analyse the security impact, and some places where I think it's 
lacking.

In a little more detail:
- The reflection that mediators are going to have to implement approaches like 
From-rewriting for at least a while leads me to think that standardising From 
rewriting is a better way to go. Standardising would allow recipient systems to 
undo the From-rewriting if they trust the intermediary and the email is 
authenticated (perhaps simple DKIM, perhaps something ARC-related). This has 
the benefit that the intermediary doesn't need to worry about whether it's 
trusted by the recipient, or whether the recipient has implemented . I agree with everyone who thinks it's somewhat distasteful, but 
seems least-worse to me given today's email environment.
- It's not clear to me in the doc which domain is being referred to in various 
places. eg assuming From: test@from.example, Sender: 
test@sender.example, which domain's DMARC policy 
should have the snd tag? If I never add the snd tag to _dmarc.from.example, do 
I get to keep today's behaviour?
- It turns a fact based check 'did the DMARC checks pass for the From domain' 
to a fuzzier reputation based one. This *may* be similarly effective at scale 
against volume spam, though I'm sceptical. I don't believe it's true for 
low-volume spear-phishing where 'a few getting through while the reputation 
system trains itself' isn't good enough.
- Comparing this to ARC, there's no passing of information about what 
authentication checks an intermediary did, nor a statement that an intermediary 
should be doing strict DMARC authentication and not passing on things which 
fail. That makes the 'trust' decision at a receiver much harder as you don't 
know if any authentication has taken place.
- As a reputation/trust based mechanism, it shares weaknesses with ARC - 
difficulty of bootstrapping, and favouring large and existing players. So I 
don't think it's expanding the solution space much, and risks distracting from 
ARC and then running into similar issues.
- The absence of a mechanism to get away from From-rewriting or similar (even 
in the long term), means this would be additional complexity with little, if 
any practical upside.

Given the above, I don't think this is a fruitful path, so I don't support 
adoption at this time.

Regards,
David

This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Revisiting the Race Condition in draft-crocker-dmarc-sender-01

[Alessandro Vesely]

On Thu 20/Aug/2020 02:06:48 +0200 Joseph Brennan wrote:

The problem was not really DMARC at all, it was abuse of DMARC.


Again, in that case we should devise a new protocol which 
/potentially/ allows all email domains to be protected.


And I'd still call such new protocol DMARC...


Best
Ale
--














___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] third party authorization, not, was non-mailing list

[Alessandro Vesely]

Hi Tim and all,

I am wondering whether companies like Dmarcian could implement third-pary 
whitelisting.  As they receive and analyze DMARC aggregate reports on behalf of 
many mail sites, they probably are able to distinguish various level of 
authentication failures, from mailing lists to misaligned ESPs, to actual 
abusers.  In that case, they could maintain a whitelist tailored for any given 
client.  The client would set, say:

_dmarc.client.domain.example IN TXT "v=DMARC1; 
rua=mailto:client...@ag.dmarcian.com; snd=client-id.rhswl.dmarcian.com; [...]"

A receiver seeing a failed From: user@client.domain.example, but an 
authenticated Sender: whate...@example.com could check authorization by 
querying the following record:

example.com.client-id.rhswl.dmarcian.com IN A 127.0.0.2

If the record exists, the sender is authorized.  That way, a Dmarcian client 
can run for some time with p=none.  Meanwhile Dmarcian fills the client's 
whitelist based on misaligned authentications and the client's desiderata.  
When the list is complete and receivers upgraded, the client can switch to 
p=reject or whatever they like.

Delivery would still lag in case, say, users subscribe to mailing lists not yet 
whitelisted, unless we make provisions for whitelisting requests to be 
submitted at subscription time.

For domain names longer than 200 octects (punycode), a whitelist may replace 
the domain name with a hash, á la ATPS.

The above setting overcomes the diagnosed non-trivial upkeep which prevented 
the diffusion of previous schemes.


Best
Ale

 Original Message 
Subject: Re: [dmarc-ietf] third party authorization, not, was non-mailing list
Date: Wed, 19 Aug 2020 21:18:29 GMT
From: Douglas E. Foster 
Reply-To: fost...@bayviewphysicians.com
To: dmarc@ietf.org 

My two cents.

1) What has changed since 2012 is DMARC, including the ability through DMARC to 
obtain feedback.  "New ATPS" would have to be implemented as a DMARC option, 
not a new thing.

2) A lot of organizations seem to be stick at p=none.   Maybe that means they 
want it that way.   Maybe it means that they are being courteous to mailing 
lists.   But maybe it means something about DMARC is too hard.   I am assuming 
that all of the problems with DMARC are related to third-party authorization, 
and something needs to be done to make it easier.

3) Delegation with an ATPS-type email entry seems functionally equivalent to 
DKIM scope delegation, with several benefits:
Easier and cheaper for the third-party to implement.   The third-party only 
needs to apply its own domain's signature.   Simpler means quicker 
implementation.  Private keys are never exchanged.

Third-party is only responsible for its own key.A big organization like 
Constant Contact or SendGrid could end up holding hundreds of thousands of DKIM 
keys, and that becomes an attractive target for attackers.  If a delegated DKIM 
key store is stolen from a third party, the attacker knows every domain that 
has been compromised.   If an ATPS-delegated third party has a corporate DKIM 
key stolen, the attacker knows that he has struck pay-dirt, but he does not 
have an immediate enumeration of compromised organizations..   That enumeration 
will require an additional data collection process, which might buy time for 
the affected organizations to take evasive measures.

An ATPS-type scope delegation could be designated for a specific user, which I 
assume will represents an application. ("SMTP address must be 
applicationname@vendordomain").   This information is something that the 
receiving system can enforce and report.   It is a weak enforcement tool, but 
limiting scope of delegation seems likely to satisfy some of the auditor 
concerns associated with any third-party delegation.  This is also a new ideas 
relative to the original ATPS.   Of course, a domain level delegation should 
also be an option for situations that the authorizing domain deems appropriate. 
 ("SMTP address must be *@vendordomain")

ATPS-type delegations could be given a pre-defined expire date (if specified 
with that feature).  This would be particularly appropriate where a third-party 
authorization is linked to a time-limited contract.   When the contract lapses, 
the authorization lapses, unless both the contract and the DNS entry are 
renewed.   This limits risk associated with the possibility of 
delegated-but-forgotten authorizations.   DKIM delegations are always 
good-til-cancelled (by removing the DNS public key).

Both DKIM and ATPS can be revoked easily, subject only to the limits of DNS 
propagation.

DKIM delegation becomes impossible if the third-party is not cooperative.   
ATPS-type delegation can be done unilaterally by the owning domain.I am 
thinking of Proofpoint in particular.   They violate my DMARC policy when my 
users, who are non-clients, respond to a secure message from one of their 
clients.   Author self-copies arrive at my gateway looking like spoof, but I