Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Murray S. Kucherawy]

On Sat, Jul 18, 2020 at 6:32 PM Dave Crocker  wrote:

> If end users do not reliably make trust decisions based on /any/ of the
> information in the rfc5322.From field, then how is this question
> important.  It seems to be seeking precise data about something that
> isn't even secondary.
>

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.

While I'm intrigued by the discussion about the domain name isn't visible
and thus may not be as important to protect as we originally thought, I'm
less convinced by the notion that all of the RFC5322.From is disregarded by
the preponderance of users when deciding what level of trust to put in the
message's content.  That suggests we blindly open and read absolutely
everything, and I suspect that isn't the case.

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/18/2020 5:16 PM, Murray S. Kucherawy wrote:
At some point in the past, Gmail decided to show the email address 
only unless that address was in the recipient's contact list, or if 
the recipient had replied to that address previously, or something 
like that.  In those cases, the RFC5322.From address was trusted, and 
so the display name was shown.  Is there logic like that still in place?



If end users do not reliably make trust decisions based on /any/ of the 
information in the rfc5322.From field, then how is this question 
important.  It seems to be seeking precise data about something that 
isn't even secondary.


The persistence of thinking that end users are influenced by trust 
indicators is pernicious.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Murray S. Kucherawy]

Brandon Long, if you're watching:

On Fri, Jul 17, 2020 at 2:01 PM Dave Crocker on behalf of Kurt Andersen <
jo...@taugh.com> wrote:

> In article  you write:
> >> I'd counter by personal anecdote that we have had to undertake
> >> security remediations because of messages which were forwarded by our
> >> CEO to other employees for responses which happened to contain malware
> >> and/or bad links. ...
>
> >Except that the problem isn't the email address, especially since almost
> >no one sees those any more.  And the display name isn't protected.
>
> Do we have any recent numbers on how many users see the From address rather
> than or in addition to the display name?
>
> Signed,
> uh, someone
>

At some point in the past, Gmail decided to show the email address only
unless that address was in the recipient's contact list, or if the
recipient had replied to that address previously, or something like that.
In those cases, the RFC5322.From address was trusted, and so the display
name was shown.  Is there logic like that still in place?

Any other UI developers got a policy here?

-MSK, sans chapeau
___
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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/17/2020 2:00 PM, Dave Crocker on behalf of Kurt Andersen wrote:

Do we have any recent numbers on how many users see the From address rather
than or in addition to the display name?


Thereby making clear that this is a spoofed message, since I wouldn't 
ask a question like that, potentially distracting from the substance of 
the topic.  Beyond, none vs. some vs. all, the numbers shouldn't matter.


There is ample evidence that trust markers presented to end users do not 
produce adequately differential (and useful) decision-making about 
whether a message is trustworthy.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Jim Fenton]

On 7/18/20 1:45 AM, Alessandro Vesely wrote:

> DMARC filtering is designed to operate at the (edge) MX, not MUA.  If
> applied consistently, it grants a well defined kind of protection. 
> That is just a building block, not a silver bullet.  Our problem is
> that DMARC filtering cannot be applied consistently, because of MLMs. 
> Lowering DMARC's contractual obligations is not a proper solution.
>
>
You lost me there. What do you mean by "DMARC's contractual obligations"?

-Jim

___
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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Alessandro Vesely]

On Fri 17/Jul/2020 23:00:53 +0200 John Levine wrote:

In article  you write:
I'd counter by personal anecdote that we have had to undertake 
security remediations because of messages which were forwarded by our 
CEO to other employees for responses which happened to contain malware 
and/or bad links. ...


Except that the problem isn't the email address, especially since almost 
no one sees those any more.  And the display name isn't protected.


Do we have any recent numbers on how many users see the From address rather
than or in addition to the display name?



Similar problems are typosquatting and homograph attacks.  I heard the latter 
is being addressed also in email clients —which implies they target users who 
look beyond the display name.  We used to hold that DMARC does not cover those 
topics.  Why should we worry about display names?


DMARC filtering is designed to operate at the (edge) MX, not MUA.  If applied 
consistently, it grants a well defined kind of protection.  That is just a 
building block, not a silver bullet.  Our problem is that DMARC filtering 
cannot be applied consistently, because of MLMs.  Lowering DMARC's contractual 
obligations is not a proper solution.



Best
Ale
--































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