Subject: [dmarc-ietf] DMARC threat analysis needed

From: Jim Fenton <[email-masked]>
Date: Wed, 15 Jul 2020 17:14:44 -0700

Unburying this from a different thread.

I'm really struggling to understand what problem(s) DMARC is trying to
solve. The most common answer I have heard says something about
"defending brand identity", which is a marketing, not a technical
consideration.

IMO we need a threat analysis, ala RFC 4686 or RFC 5016, to define the
technical requirements. I am NOT volunteering to do this.

-Jim

---

From: Dotzero <[email-masked]>
Date: Wed, 15 Jul 2020 21:31:19 -0400

As part of the original DMARC team and having worked with anti-abuse for a
long time at scale for a large set of websites, I can speak to my
motivation. It's not really about defending brand identity. The data shows
(although it is not mine to share) that end users will click on anything
based on the right social engineering. Love, money, etc. are powerful
motivators. The first thing that DMARC enables is for a brand/domain to
signal to validators/receivers that the domain has control of it's mail
streams and is identifying those mail streams using the combination of
SPF/DKIM/DMARC. This enables receivers to process those mail streams with a
certain amount of confidence. This leaves open the question of when good
domains go bad but that falls into the realm of local policy on th part of
the receiver. I think anyone who makes an assertion about "DMARC policy"
needs.to remember that at best it is a request to validators/receivers.

 Yes, the issues of cousin domains, homoglyphs, etc. are thrown out there
as reasons why DMARC is "irrelevant" to solving problems such as spam or
phishing. It doesn't solve spam but it does have an impact on phishing, if
only to push the bad guys to "push reality". If I get a phishing email from
a bank that is not my own, I as an end user am less likely to fall for that
particular phishing scheme. It makes it easier for validators/receivers to
differentiate real from Memorex. It's also important to recognize that the
environment isn't static. The bad guys are always thinking up new
approaches as the old/currnt ones yield declining results. This evolving
context is sometimes brandished against DMARC as an indicator that it isn't
useful.

My experience with a number of brands/domains that were aggressive in
implementing SPF/DKIM/DMARC as well as other measures, we were able to
drive down abuse against those brands/domains by over 95%. Did the bad guys
continue to test both external abuse as well as probe for weaknesses that
would enable abuse through the systems? Absolutely. Did they move on to
other brands/domains to abuse? Absolutely.

When Jim asks the question "What problem are we trying to solve?", perhaps
the prior question should be "Who are we?".

Michael Hammer

On Wed, Jul 15, 2020 at 8:15 PM Jim Fenton <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Hector Santos <[email-masked]>
Date: Fri, 17 Jul 2020 12:01:48 -0400

> technical requirements. I am NOT volunteering to do this.

Jim, if we review both RFC4686 and RC5016, I believe we might find 
there is not much to be changed. However, imo, something will have to 
be done regarding RFC5016 section 5.3 item:

   https://tools.ietf.org/html/rfc5016#section-5.3
   5.3.  Practice and Expectation Requirements

   10. SSP MUST NOT provide a mechanism that impugns the existence of
       non-first party signatures in a message.  A corollary of this
       requirement is that the protocol MUST NOT link practices of first
       party signers with the practices of third party signers.

        INFORMATIVE NOTE: the main thrust of this requirement is that
        practices should only be published for that which the publisher
        has control, and should not meddle in what is ultimately the
        local policy of the receiver.

This provision with strict protocol language "MUST NOT" prohibits any 
DKIM Policy protocol, formally called SSP "Sender Signing Practices" 
and now today, DMARC, from impugning on 3rd party policies such as how 
a MLM operator via local policy exceptions can ignorantly and blinding 
destroy the integrity and resign the mail instead of just honoring it.

This language would have be updated or removed and just leave the 
implicit idea that local policy always prevails in all SMTP situations.

Have a good weekend, be safe.

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

---

From: "Doug Foster" <[email-masked]>
Date: Fri, 17 Jul 2020 14:57:25 -0400

Hector, I think I am reading RFC 5016 section 5.3 differently from you.   My
paraphrase:

This SSP assertion is allowed:
"Example.com says:  Example.com messages can be considered authorized if and
only if they have a signature from our domain."

This SSP assertion is not allowed:
"Example.com says:  Example.com messages can be considered authorized if and
only if they have a signature from our domain, and DO NOT have a signature
from OtherGuy.com domain"

The second assertion is not allowed because Example.com should not be
"impugning" the validity of a signature from OtherGuy.com.   Example.com is
not empowered to be a reputation service for unrelated entities.

However, the language of this section directly supports the DMARC
implementation. 

To solve the MLM problem, you need to explain how MLMs become authorized by
the author domain to send on behalf of the author, without authorizing
spammers to send on behalf of the author.

It seems that we have an architectural problem because the current
infrastructure assumes a single author.     In reality, we have multiple
situations that involve multiple authors.   For example, this message
includes your entire note, and your note includes part of Jim's note.   But
those notes no longer have valid digital signatures, so there is no proof
that I have represented you correctly, and it is technically possible for me
to rewrite your comments entirely.

A similar problem occurs if my spam filter adds content to a message as it
arrives into my domain, content that is really intended for "internal use
only".   The additions will break incoming signatures, although this is
tolerable because signatures are not checked again, as long as the message
remains internal.   But if a message is  auto-forwarded to another domain,
the additions are probably inappropriate and the message no longer passes
Sender Authentication.   I would like to be able to preserve the original
signature throughout, and remove the internal spam filter content when the
message leaves the internal domain.

Consequently, I am dreaming about an architecture that allows mediators to
add content under their own signature without voiding the signature of other
sections.   The concept is a combination of John's ARC project, which uses
nested signatures , and Murray's tagged content, which acts as a change log.
It would allow an MUA to clearly identify the content contributed by the
different authors, and it would contribute to solving the MLM problem.    It
is easier to imagine how it could be used to identify additions, such as a
message footer, then to identify alternations, such as a URL rewrite.   And
the whole thing may be too complicated to implement in a way that is upward
compatible with the present architecture.   But it would be a better model
of reality.

Doug Foster

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Friday, July 17, 2020 12:02 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] DMARC threat analysis needed

> technical requirements. I am NOT volunteering to do this.

Jim, if we review both RFC4686 and RC5016, I believe we might find there is
not much to be changed. However, imo, something will have to be done
regarding RFC5016 section 5.3 item:

This provision with strict protocol language "MUST NOT" prohibits any DKIM
Policy protocol, formally called SSP "Sender Signing Practices" 
and now today, DMARC, from impugning on 3rd party policies such as how a MLM
operator via local policy exceptions can ignorantly and blinding destroy the
integrity and resign the mail instead of just honoring it.

This language would have be updated or removed and just leave the implicit
idea that local policy always prevails in all SMTP situations.

---

From: Jim Fenton <[email-masked]>
Date: Sat, 18 Jul 2020 10:16:56 -0700

Hi Mike,

On 7/15/20 6:31 PM, Dotzero wrote:
> As part of the original DMARC team and having worked with anti-abuse
> for a long time at scale for a large set of websites, I can speak to
> my motivation. It's not really about defending brand identity. The
> data shows (although it is not mine to share) that end users will
> click on anything based on the right social engineering. Love, money,
> etc. are powerful motivators. The first thing that DMARC enables is
> for a brand/domain to signal to validators/receivers that the domain
> has control of it's mail streams and is identifying those mail streams
> using the combination of SPF/DKIM/DMARC. This enables receivers to
> process those mail streams with a certain amount of confidence. This
> leaves open the question of when good domains go bad but that falls
> into the realm of local policy on th part of the receiver. I think
> anyone who makes an assertion about "DMARC policy" needs.to
> <http://needs.to> remember that at best it is a request to
> validators/receivers.
That's correct, but domains publishing DMARC policy need to bear in mind
that some validators/receivers will honor that request and that it can
create deliverability problems for their outgoing mail in some situations.
>
>  Yes, the issues of cousin domains, homoglyphs, etc. are thrown out
> there as reasons why DMARC is "irrelevant" to solving problems such as
> spam or phishing. It doesn't solve spam but it does have an impact on
> phishing, if only to push the bad guys to "push reality". If I get a
> phishing email from a bank that is not my own, I as an end user am
> less likely to fall for that particular phishing scheme. It makes it
> easier for validators/receivers to  differentiate real from Memorex.
> It's also important to recognize that the environment isn't static.
> The bad guys are always thinking up new approaches as the
> old/currnt ones yield declining results. This evolving context is
> sometimes brandished against DMARC as an indicator that it isn't useful.
It's not that DMARC isn't useful. We need to consider (and document) the
threats that it is effective against (unauthenticated mail claiming to
come from a domain from which it should have been authenticated) and
those it is not effective against (homoglyphs, display name misuse,
etc.). And then we need to consider the collateral damage, such as
against mailing lists and their users, and do a cost/benefit analysis to
determine whether the benefit justifies the breakage. With 5 years of
experience since RFC 7489 was published it's reasonable to revisit these
issues with the benefit of that experience.
> drive down abuse against those brands/domains by over 95%. Did the bad
> guys continue to test both external abuse as well as probe for
> weaknesses that would enable abuse through the systems? Absolutely.
> Did they move on to other brands/domains to abuse? Absolutely.
>
> When Jim asks the question "What problem are we trying to solve?",
> perhaps the prior question should be "Who are we?".

Part of the reason I ask that question is because RFC 7489 Section 2.4
says, "DMARC is designed to prevent bad actors from sending mail that
claims to come from legitimate senders, particularly senders of
transactional email (official mail that is about business
transactions)." If restrictive DMARC policies were only applied to
domains that were used for transactional email, we wouldn't be having
this problem with mailing lists and the like.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Sat, 18 Jul 2020 10:21:49 -0700

Hi Hector,

> implicit idea that local policy always prevails in all SMTP situations.

Despite its use of normative language, RFC 5016 is an informational RFC
and is therefore not binding on anything or anyone.

I was primarily citing RFC 4696 and RFC 5016 as examples of the type of
analysis I am hoping will be done for DMARC.

> Have a good weekend, be safe.

You too.

-Jim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 18 Jul 2020 17:13:53 -0700

On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton <[email-masked]> wrote:

> threats that it is effective against (unauthenticated mail claiming to come
> from a domain from which it should have been authenticated) and those it is
> not effective against (homoglyphs, display name misuse, etc.). And then we
> need to consider the collateral damage, such as against mailing lists and
> their users, and do a cost/benefit analysis to determine whether the
> benefit justifies the breakage. With 5 years of experience since RFC 7489
> was published it's reasonable to revisit these issues with the benefit of
> that experience.
>

DMARC did attempt to document these shortcomings itself, for example in
Section 12.4 of RFC 7489 which covers display name attacks.  I imagine this
would be carried forward into the standards track version, unless the
working group wants to entertain the idea of breaking it all out and
re-hashing it first.

This working group also produced RFC 7960 which talks about the problems
with respect to mailing lists.  Maybe we have more data in the last four
years?

Still unresolved, IMHO, is Dave's point about whether the RFC5322.From
domain truly matters.

-MSK, most participatorially

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 19 Jul 2020 12:14:36 +0200

On Sun 19/Jul/2020 02:13:53 +0200 Murray S. Kucherawy wrote:
>> phishing. [...]
>> not effective against (homoglyphs, display name misuse, etc.). [...]
>>
> 

I think the WG charter is clear enough.

> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From

While the opinions of big players are relevant, you yourself mentioned that 
they tend to follow DMARC design.  Perhaps, some years ago, it was the 
importance of From: domain which inspired DMARC design.  Now, it's DMARC which 
determines the importance of From: domain.

Filtering at MX level followed DMARC development rather closely.  MUA behavior 
lags behind, but seems to be plodding through.  We might suggest guidelines 
(for example, bewaring of at signs in display names), but it is their task to 
find out how to highlight domain misalignment.  The more dependable is DMARC 
filtering, the greater are MUA's motivations to follow suit.  Not the other way 
around.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Jul 2020 11:13:46 -0700

On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely <[email-masked]> wrote:

> they tend to follow DMARC design.

Sorry, I said what?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 20 Jul 2020 10:42:25 +0200

On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:
>> While the opinions of big players are relevant, you yourself mentioned 
>> that they tend to follow DMARC design. >
> 
> Sorry, I said what?

     Google strikes me as the kind of place that would make a decision
     about what to show users based on data, so I was wondering if they
     have any, because I seem to remember them talking about this back
     when DMARC was in development.
     [https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/]

Brandon hasn't chimed in, yet.  I Cc: him.  I'd guess he can confirm that 
efforts to highlight the domain name in From: addresses, if any, are inspired, 
or at least encouraged, by DMARC development.

By hijacking From:, DMARC tweaked email core somewhat, for the good and the bad 
of it.  We can either go ahead or retreat, a threat analysis being needed to 
make that decision.

Best
Ale
--

---

From: Brandon Long <[email-masked]>
Date: Mon, 20 Jul 2020 16:05:12 -0700

On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely <[email-masked]> wrote:

>      [
> https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/]
>
>

I don't have any information on that, I was never on the abuse or frontend
teams.  In general,
UX changes go through review and user testing, but the bar for such changes
might not meet
the rigor being asked for.

Yes, we continue to make changes to the display of the author of an email
address with the
understanding that it affects the handling by at least some of the
receivers.  I think everyone
understands no UX changes are going to stop all attacks, but I don't
believe anyone has
shown that changes have no effect at all.

I've invited some folks internally to these discussions, perhaps they can
add to this.

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Jul 2020 17:58:20 -0700

> https://mailarchive.ietf.org/arch/msg/dmarc/P6-4mvdCrRVXEz6DQXGunBsRKqA/]

When I said "back when DMARC was in development", that meant Gmail had
already done what I described, not that they were inspired to do what DMARC
said.  Gmail was part of that effort, in fact.

So no, I didn't say "they tend to follow DMARC design".  The order is
backwards.

-MSK