Re: [dmarc-ietf] DMARC threat analysis needed

[Murray S. Kucherawy]

On Mon, Jul 20, 2020 at 1:42 AM Alessandro Vesely  wrote:

> On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:
> > On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely 
> wrote:
> >
> >>> Still unresolved, IMHO, is Dave's point about whether the RFC5322.From
> >>> domain truly matters.
> >>
> >> 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/]
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC threat analysis needed

[Alessandro Vesely]

On Sun 19/Jul/2020 20:13:46 +0200 Murray S. Kucherawy wrote:

On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely  wrote:


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


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
--
























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

Re: [dmarc-ietf] DMARC threat analysis needed

[Murray S. Kucherawy]

On Sun, Jul 19, 2020 at 3:14 AM Alessandro Vesely  wrote:

> > Still unresolved, IMHO, is Dave's point about whether the RFC5322.From
> > domain truly matters.
>
> While the opinions of big players are relevant, you yourself mentioned
> that
> they tend to follow DMARC design.


Sorry, I said what?

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

Re: [dmarc-ietf] DMARC threat analysis needed

[Alessandro Vesely]

On Sun 19/Jul/2020 02:13:53 +0200 Murray S. Kucherawy wrote:

On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton  wrote:


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'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.). [...]



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.



I think the WG charter is clear enough.



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



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
--


























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

Re: [dmarc-ietf] DMARC threat analysis needed

[Murray S. Kucherawy]

On Sat, Jul 18, 2020 at 10:17 AM Jim Fenton  wrote:

> 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.
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC threat analysis needed

[Jim Fenton]

Hi Hector,

On 7/17/20 9:01 AM, Hector Santos wrote:
> 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.

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

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

Re: [dmarc-ietf] DMARC threat analysis needed

[Jim Fenton]

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
>  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.
>
> 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?".

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


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

Re: [dmarc-ietf] DMARC threat analysis needed

[Doug Foster]

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:dmarc-boun...@ietf.org] On Behalf Of Hector Santos
Sent: Friday, July 17, 2020 12:02 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC threat analysis needed

On 7/15/2020 8:14 PM, Jim Fenton wrote:
> 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, 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

Re: [dmarc-ietf] DMARC threat analysis needed

[Hector Santos]

On 7/15/2020 8:14 PM, Jim Fenton wrote:

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, 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


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

Re: [dmarc-ietf] DMARC threat analysis needed

[Dotzero]

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  wrote:

> 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
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] DMARC threat analysis needed

[Jim Fenton]

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

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