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

[Jesse Thompson]

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

[Dotzero]

On Sun, Jul 26, 2020 at 9:42 AM Dave Crocker  wrote:

> On 7/21/2020 12:32 PM, Dotzero wrote:
>
> The original DMARC effort was, in fact, to detect actual cases of
>> spoofing, namely unauthorized use of a domain name by outside actors.
>>
>> Different problem.
>>
>
> Actually, part of the effort was to enable Sending domains to identify
> their own mail that was being sent without aligned DKIM signing or from
> places not authorized through SPF - in other words, not properly authorized
> but legitimate, hence feedback loops.
>
>
> As I recall, this was /not/ part of the original purpose of DMARC, which
> was discussed strictly in terms of mail from bulk senders.
>
> What you describe was,  rather, the basis for the later use, which is what
> then started causing problems for mail going through Mediators.
>

Notice I didn't use the word "users" Many of the sending domains in the
original effort had/have a complex number of mail streams for transactional
mail from multiple domains (in some cases thousands), including through
multiple 3rd parties. This is what I was referring to.

Michael Hammer.
___
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

[Douglas E. Foster]

The link provided by Laura Atkins on 7/21 is relevant and worth 
reading.Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Dave Crocker  Date: 
7/26/20  2:35 PM  (GMT-05:00) To: hsan...@isdg.net 
Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Response 
to a claim in draft-crocker-dmarc-author-00 security considerations 

On 7/26/2020 11:29 AM, Hector Santos wrote:
> Dave, for a number of years of practice, depending in the system or 
> service, users have been provided with trust-related decisions . Do 
> you need real examples? 


There is a difference between providing a signal, versus its getting 
received and use.

Please provide objective data that these signals are being perceived and 
used effectively by end users.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

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

[Hector Santos]

On 7/26/2020 2:34 PM, Dave Crocker wrote:

On 7/26/2020 11:29 AM, Hector Santos wrote:

Dave, for a number of years of practice, depending in the system or
service, users have been provided with trust-related decisions . Do
you need real examples?



There is a difference between providing a signal, versus its getting
received and use.

Please provide objective data that these signals are being perceived
and used effectively by end users.


Dave, I made a mistake to preempt the remaining comment by saying  "Do 
you need real examples?"  I thought I had removed it.  It was rude. Sorry.


Please read the remaining part in my previous message with my input 
explaining how GMAIL provides Trust-Related decision options to the 
layman user mail reader.


There is a lot more to this and I need to go.   I think you are 
correct in suggesting the user has no input in the protocols are are 
looking for.   Its the deterministic vs subjective/learning/heuristics 
protocols issue again.  In reality, we don't have the latter (IETF 
public domain standard for a non-deterministic filtering engine). 
Unless we want to include SpamAssasin as the Default EmailCore AVS 
Engine, it has been a long time missing, desirable part of the total 
picture.  With that engine, users would be a natural part of the 
equation. Unfortunately, we are not there.  But with the former, I 
always thought these deterministic protocols were targeted for 
unsolicited, anonymous transactions where only the AUTHOR DOMAIN, the 
self-signing domain, is the only trusted source.  Not the user or even 
the sender unless IFF there is an Author::Sender association established.


Have a good day, off to relax at the safe-distancing pool.

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

[Dave Crocker]

On 7/26/2020 11:29 AM, Hector Santos wrote:
Dave, for a number of years of practice, depending in the system or 
service, users have been provided with trust-related decisions . Do 
you need real examples? 



There is a difference between providing a signal, versus its getting 
received and use.


Please provide objective data that these signals are being perceived and 
used effectively by end users.


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

[Hector Santos]

On 7/26/2020 12:12 PM, Dave Crocker wrote:>

My comment was about observable behavior, not philosophical anything.

The issue isn't about was is available to users, but what they
actually do.  Behavior.


Dave, for a number of years of practice, depending in the system or 
service, users have been provided with trust-related decisions . Do 
you need real examples?


Gmail moves spam into Spam box.

If you user do not look into their spam box, their inaction is used to 
give spam weight to false positives.   If the user is looking for 
something, finds it in the spam box, it will see something like this:


   "What is this message in spam? (specific or vague reason)"
   "REPORT NOT SPAM"

Clicking "REPORT NOT SPAM" it doesn't guarantee it will be moved to an 
area you can see it.  It's been reported as lost, you just can't find 
it.  So it is sent again.  The next time another message of the same 
type is received, it will also be placed in the spam box but this time 
it says:


   "What is this message in spam? it is similar to messages 
identified as spam in past"

   "REPORT NOT SPAM"

Clicking "REPORT NOT SPAM" it doesn't guarantee the next transaction 
will not be moved into the spam box the next time.   There are 
properly other behaviors the user must make before the message source 
is "white listed."


I am not sure if we can model this behavior based on the different 
ways it may be done, but let me outline what I have observed with users:


- May never check spam box
- May check if expecting a message unexpectedly delayed.
- Ignore it, it gets weighted as spam.
- Click Report not Spam. Cross finger you can see it in-box.
- Next similar messages are still moved to spam box

It is the last behavior that is concerning because when you are 
dealing with layman users who may see an message in a spam box but 
leave it there, it appears GMAIL will keep adding weight to it as a 
spam, negatively impacting the source identities of the mail.


In the end, the positive of SPAM box are lost because now you are 
forcing the user to scrutinize the Spam Box opening the door to 
reading and accidental clicks. if REPORT NOT SPAM does not clear it 
up, there is even more confusion for the purpose of that button or any 
similar AI learning logic that may be employed.




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

[Douglas E. Foster]

Recipient domains determine what messages they will accept or reject.Fairness 
and precedence are not necessarily applicable.I suggest that the DMARC 
standards track be placed on hold for at least a year.   It is not clear to me, 
from this group's membership, that DMARC implementers feel an urgent need for 
standard status, so a delay should be tolerable to them.A Mailing List 
Protection WG should be formed to develop his ideas into an informational or 
experimental RFC.   Then that RFC can be promoted to see if it wins over any 
current users of DMARC Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Dave Crocker  Date: 
7/26/20  9:50 AM  (GMT-05:00) To: Brandon Long  
Cc: IETF DMARC WG , Dotzero  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
On 7/21/2020 1:42 PM, Brandon Long wrote:
> Stricter validation is not an uncommon addition to protocols over the
> last 45 years.


If there are examples of adding stricter validation in a way that
essentially requires changing the semantics of the payload, in order for
the payload to survive, I can't think of any. Not TLS, not DNSSec, not
S/MIME or PGP.

DMARC essentially enforces a semantic on the From: field as a handling
identifier, rather than an author identifier.

When activity that has a long history of semantic validity and a
continued desire for operation is forced to break the denotational
source of authoring information, in order to get the mail delivered,
then we are in new territory.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

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

[Dave Crocker]

On 7/26/2020 10:10 AM, Jim Fenton wrote:


On 7/26/20 6:42 AM, Dave Crocker wrote:


On 7/21/2020 12:32 PM, Dotzero wrote:


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside
actors.

Different problem.


Actually, part of the effort was to enable Sending domains to 
identify their own mail that was being sent without aligned DKIM 
signing or from places not authorized through SPF - in other words, 
not properly authorized but legitimate, hence feedback loops.


As I recall, this was /not/ part of the original purpose of DMARC, 
which was discussed strictly in terms of mail from bulk senders.


What you describe was,  rather, the basis for the later use, which is 
what then started causing problems for mail going through Mediators.


Just identifying their own mail their own email that was sent...: Yes, 
that's always been part of the original purpose of DMARC, and is the 
purpose of the reporting mechanisms. Yes,




Looking over the original I-D posted for DMARC -- which was written 
after DMARC was already functioning, from work outside the IETF -- I'm 
unclear where this goal of "identify[ing] their own mail that was being 
sent without aligned DKIM signing" is clearly explained.(*)


Rather, note:


2.  Introduction



This memo defines Domain-based Message Authentication, Reporting and
Compliance (DMARC), a mechanism by which email operators leverage
existing authentication and policy advertisement technologies to
enable both message-stream feedback and enforcement of policies
against unauthenticated email.


and


3.1.  High-Level Requirements

At a high level, DMARC is designed to satisfy the following
requirements:

o  Minimize false positives.



o  Reduce the amount of successfully delivered phish.



(Caveat: None of the text I've excised explicity supports this claimed 
use.  To the extent someone thinks it or any other text in this draft 
does demonstrate that intended use, please explain how that 
interpretation is clear from the text in the draft.)



d/


(*) 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/00/?include_text=1


--
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/26/20 6:42 AM, Dave Crocker wrote:

> On 7/21/2020 12:32 PM, Dotzero wrote:
>>
>> The original DMARC effort was, in fact, to detect actual cases of
>> spoofing, namely unauthorized use of a domain name by outside actors.
>>
>> Different problem.
>>
>>
>> Actually, part of the effort was to enable Sending domains to
>> identify their own mail that was being sent without aligned DKIM
>> signing or from places not authorized through SPF - in other words,
>> not properly authorized but legitimate, hence feedback loops.
>
>
> As I recall, this was /not/ part of the original purpose of DMARC,
> which was discussed strictly in terms of mail from bulk senders.
>
> What you describe was,  rather, the basis for the later use, which is
> what then started causing problems for mail going through Mediators.
>

Just identifying their own mail their own email that was sent...: Yes,
that's always been part of the original purpose of DMARC, and is the
purpose of the reporting mechanisms. Yes, the reports will contain
information on many mediators, but that's just noise in the reports. It
also contains information when, for example, the product XYZ marketing
department decided to use a new mail sending partner without telling
anyone. That's useful.

It's the policy mechanism (or more specifically its use by other than
transactional domains) that's causing the problem here.

-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

[Dave Crocker]

My wording was not careful enough.  What I /meant/ was: end-users are
not relevant to the /trust-related decision making/ that is the goal
of these protection mechanisms.


This may be a philosophical theory, but in reality, in lieu of having 
deterministic mechanisms, we do have mail systems who do allow the 
user to make these type of trust decisions.  If a trust-related 
question is answered wrong by the user, the true victim is the honest 
sender.


My comment was about observable behavior, not philosophical anything.

The issue isn't about was is available to users, but what they actually 
do.  Behavior.



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

[Hector Santos]

On 7/26/2020 7:40 AM, Dave Crocker wrote:


My wording was not careful enough.  What I /meant/ was: end-users are
not relevant to the /trust-related decision making/ that is the goal
of these protection mechanisms.


This may be a philosophical theory, but in reality, in lieu of having 
deterministic mechanisms, we do have mail systems who do allow the 
user to make these type of trust decisions.  If a trust-related 
question is answered wrong by the user, the true victim is the honest 
sender.


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

[Dave Crocker]

On 7/21/2020 1:42 PM, Brandon Long wrote:
Stricter validation is not an uncommon addition to protocols over the 
last 45 years.



If there are examples of adding stricter validation in a way that 
essentially requires changing the semantics of the payload, in order for 
the payload to survive, I can't think of any. Not TLS, not DNSSec, not 
S/MIME or PGP.


DMARC essentially enforces a semantic on the From: field as a handling 
identifier, rather than an author identifier.


When activity that has a long history of semantic validity and a 
continued desire for operation is forced to break the denotational 
source of authoring information, in order to get the mail delivered, 
then we are in new territory.


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

[Dave Crocker]

On 7/21/2020 12:32 PM, Dotzero wrote:


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.


Actually, part of the effort was to enable Sending domains to identify 
their own mail that was being sent without aligned DKIM signing or 
from places not authorized through SPF - in other words, not properly 
authorized but legitimate, hence feedback loops.



As I recall, this was /not/ part of the original purpose of DMARC, which 
was discussed strictly in terms of mail from bulk senders.


What you describe was,  rather, the basis for the later use, which is 
what then started causing problems for mail going through Mediators.



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

[Dave Crocker]

On 7/20/2020 3:05 PM, Jesse Thompson wrote:

On 7/19/20 1:33 PM,dcroc...@gmail.com  wrote:

The essential point that needs to be made is that standards like this MUST NOT 
be cast in terms of what end users will do.  In practical terms, this work has 
nothing to do with end users.  Really.  Nothing.

To the extent that anyone wants to make an affirmative claim that 
end-users/are/  relevant to this work, they need to lay that case out clearly, 
carefully, and with material that provides objective support.(*)

I'll take a shot (admittedly, I'm having trouble keeping up with all of the 
points that have been made):

We're migrating 30,000 lists, of various types/use cases, from a MLM provider 
that is DMARC-



** We have had many complaints from users about the From munging **



My wording was not careful enough.  What I /meant/ was: end-users are 
not relevant to the /trust-related decision making/ that is the goal of 
these protection mechanisms.


They certainly /are/ relevant to the sorting/searching/presentation 
issues that are disrupted by having mail authored by the same person 
contain different From: field data.


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

[Dave Crocker]

On 7/20/2020 1:44 AM, Alessandro Vesely wrote:

On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote:
The essential point that needs to be made is that standards like this 
MUST NOT be cast in terms of what end users will do.  In practical 
terms, this work has nothing to do with end users. Really.  Nothing.

[...]
(*) I've seen one posting here or somewhere else that noted that 
letting bad mail through can lead to end-users being deceived. I'll 
claim that while true, it is not relevant, since the behavior happens 
after DMARC, and the like, are relevant.  That is, DMARC, etc., do 
not inform the end-user behavior.


Aren't those two paragraphs self-contradictory?


No.

A specification defines a field of activity.  (A sandbox.) Things 
outside that field are not relevant to the specification, even though 
they might be highly relevant from a larger perspective. There is a 
constant desire to have a specification that involves security-related 
decision-making include the (human) recipient be an actor within the 
scope of the specification. The first paragraph, quoted above, is a 
reminder that we need to resist that desire.


The second paragraph, quoted above, is a reminder about a specific 
example of this, namely about the DMARC specification. It acknowledges 
that, in general, recipients can be deceived, for the specific From: 
field protection that DMARC provides, the recipient is not a relevant actor.



If DMARC were dependable, maybe users would learn to trust From:. Or 
maybe not.  Avoiding end user considerations cuts both ways. Yet, we 
can trust that if we do a well-defined, clear job, then the whole 
system will work better.


It is expensive and highly risky to create an international standard 
that relies on such a tenuous hope about future behavior, especially in 
the face of consistent empirical evidence that it won't happen.


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

[Dave Crocker]

On 7/23/2020 6: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?



Technical specifications are not policy advisories or expressions of 
opinion.  They definebehavior to be used by actors that are trying to 
follow the specification.  A specification defines a sandbox.  Normative 
statements apply to actors that have chosen to be inside the sandbox.


So, normative language in specifications is meaningful only when it will 
be followed.  Giving directives to actors not participating in the topic 
of the specification is wasteful and likely misleading.


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

[Joseph Brennan]

On Mon, Jul 20, 2020 at 6:05 PM Jesse Thompson
 wrote:
>
>
>
> It calls into question whether we (or any domain) should publish DMARC 
> policies.  Gmail.com doesn't publish a DMARC policy, after all, and many 
> people (such as some on this list) are using gmail.com to subscribe to lists, 
> and they don't have to suffer the consequences of DMARC.


I interpret Gmail's approach as a fine marketing decision. It means
mail from gmail.com is more deliverable than mail from yahoo and aol.
They must be smiling every time some domain rejects end-user mail for
DMARC violations.

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









-- 
Joseph Brennan
Lead, Email and Systems Applications

___
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

[Dotzero]

On Wed, Jul 22, 2020 at 6:38 PM Jesse Thompson  wrote:

> On 7/22/20 12:05 PM, John Levine wrote:
> > I don't believe we have a charter to tell mailing list operators what
> > to do, even if we believed, against all experience, that they would
> > take our advice.
>
> https://cyber.dhs.gov/bod/18-01/ references
> https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F
>
> Who should be giving them advice?
>

Probably not a technical standards group.

>
>
> > As may have been pointed out a few times, mailing lists had been
> > serving their users perfectly well for decades before AOL and Yahoo made
> them
> > DMARC roadkill.
>
> Given that the email security industry's marketing now shames domain
> owners for not adopting DMARC, I think that the statute of limitations for
> AOL and Yahoo has passed.
>

Despite my personal opinions regarding mailing lists, DMARC and anti-abuse,
this working group is not the running dog for the email security industry's
marketing efforts to shame domain owners. Perhaps you would like to submit
an Internet Draft on how to resist feeling shamed. I have a feeling it
would be informational at best.

I would also suggest that this group, lacking significant representation of
MUA providers, should also refrain from thinking it reasonable that this
group should tell MUA providers how they should go about their business.

Michael Hammer
___
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

[Jesse Thompson]

On 7/22/20 12:05 PM, John Levine wrote:
> I don't believe we have a charter to tell mailing list operators what
> to do, even if we believed, against all experience, that they would
> take our advice.

https://cyber.dhs.gov/bod/18-01/ references 
https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F

Who should be giving them advice?


> As may have been pointed out a few times, mailing lists had been
> serving their users perfectly well for decades before AOL and Yahoo made them
> DMARC roadkill.

Given that the email security industry's marketing now shames domain owners for 
not adopting DMARC, I think that the statute of limitations for AOL and Yahoo 
has passed.

Jesse

___
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

[John Levine]

In article <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com> you write:
>Since the conflict between DMARC and Mailing Lists is related to the changes 
>that Mailing List apply
>to a received message, it may be useful to review the purposes that each of 
>those changes serve, with
>a goal of eliminating unnecessary changes.

I don't believe we have a charter to tell mailing list operators what
to do, even if we believed, against all experience, that they would
take our advice.

As may have been pointed out a few times, mailing lists had been
serving their users perfectly well for decades before AOL and Yahoo made them
DMARC roadkill.

R's,
John


___
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

[Doug Foster]

Since the conflict between DMARC and Mailing Lists is related to the changes 
that Mailing List apply to a received message, it may be useful to review the 
purposes that each of those changes serve, with a goal of eliminating 
unnecessary changes.

Specifically, this list adds a footer to every message.   Is the footer a 
"trust indicator" which serves an imaginary purpose, or a necessary addition 
for other reasons?   If it is added as a trust indicator, perhaps it could be 
dropped.

I would be willing to format my submissions to IETF specifications, if it would 
protect the integrity of my signature.   But IETF has not disclosed a way for 
that to be done.   What I can determine is that the footer addition is 
currently unconditional, as evidenced by reply messages with multiple copies of 
the footer, and therefore I cannot prevent my signature from being invalidated.

DF

-Original Message-
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, July 22, 2020 9:24 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations

On 7/21/2020 1:08 AM, Laura Atkins wrote:
> When we’re basing a protocol on “what the user sees” and “what the 
> user can trust” then I think we have to. DMARC says “users can trust 
> that mail from @domain.example is really from @domain.example” but if 
> the user never sees that, how do they know?


I think this can be connected to the query about threats that DMARC is 
intended to respond to, by virtue of suggesting clarity about /where/ 
the responding takes place.

My contention is that it takes place in a receiving filtering engine and 
does not take place at the user level.

Further, it's one more data point in that engine's analysis process, 
rather than being in any simple way definitive.

In any event, work here really should make a point of creating text that 
is clear about threats DMARC is intended to respond to, and clear about 
where such responding takes place.

To the extent any of that text makes assertions about the performance of 
end users, it needs to cite the basis for the assertions.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

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

[Dave Crocker]

On 7/21/2020 1:08 AM, Laura Atkins wrote:
When we’re basing a protocol on “what the user sees” and “what the 
user can trust” then I think we have to. DMARC says “users can trust 
that mail from @domain.example is really from @domain.example” but if 
the user never sees that, how do they know? 



I think this can be connected to the query about threats that DMARC is 
intended to respond to, by virtue of suggesting clarity about /where/ 
the responding takes place.


My contention is that it takes place in a receiving filtering engine and 
does not take place at the user level.


Further, it's one more data point in that engine's analysis process, 
rather than being in any simple way definitive.


In any event, work here really should make a point of creating text that 
is clear about threats DMARC is intended to respond to, and clear about 
where such responding takes place.


To the extent any of that text makes assertions about the performance of 
end users, it needs to cite the basis for the assertions.


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

[Dave Crocker]

On 7/21/2020 1:42 PM, Brandon Long wrote:
I'd be curious when MLMs modifying the mail going through them became 
a thing, I guess I assume it wasn't 45 years ago, but I know it's 
irrelevant.



When I said 45 years, I wasn't not kidding...

The Subject line and the To: field were modified, here:


Date: 7 JUN 1975 1432-PDT
Sender: FARBER at USC-ISI
Subject: MSGGROUP# 001 TCTALK
From: FARBER at USC-ISI
To: MessageGroup:
Message-ID: <[USC-ISI]7-JUN-75 14:32:54-PDT.FARBER>


There is a distributed network teleconferencing facility oriented
to networks experimentally  avilable  called  TCTALK.  It was the
result of a thesis of Jim  Calvin  at  BBN. It can be accessed at
the ISIA site via  TCTALK. questions relative to it
can be answered by Calvin  or  Geoff at SRI-AI. I would recommend
that you try it if you have not. Improvements are being made on a
time available basis by Calvin.

The full discription of TCTALK is available via the net and is in
essense Calvins CASE thesis. Contact CAlvin for that.

Dave


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

[Douglas E. Foster]

Your credit card scenario is one legitimate way of viewing the problem.   I 
have also been thinking about a credit card scenario, but coming to a different 
conclusion:

For many years, Bill Smith has been using the credit card of his sister-in-law, 
Tracy Jones.   This is an informal arrangement because Bill does not want a 
card of his own.He faithfully pays Tracy for all of his charges.   No 
cashier has ever asked Bill for any ID other than his credit card.

Suddenly, the bank reissues all cards with photos, in an attempt to reduce card 
fraud.   Cashiers begin looking at the photos and will not let Bill use Tracy's 
credit car anymore.   Bill cries foul because he has the cardholder's 
permission.Bill has the trust of Tracy, but he does not have the trust of 
the bank, and as a result, he does not have the trust of the retail clerk.

Should the bank remove those photos to accommodate Bill?

DF


From: Dave Crocker 
Sent: 7/21/20 3:45 PM
To: Dotzero 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations
On 7/21/2020 12:32 PM, Dotzero wrote:

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker  wrote:
On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "spoofing".  You 
wrote "MLM is authorized by the user". Someone without authority cannot 
authorize. In this case the user externalized the problem, not DMARC.

That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline purchases 
while running errands for me.  You take the car on a cross-country joyride, 
running the cc charges for gasoline up.  The stations that  charged the gas to 
the card did nothing wrong.  The problem is internal, between you and me.

The MLM's did not do any spoofing.  They acted appropriately, as they have for 
45 years.

If the domain owner has a problem with the user's behavior, that's internal, 
between the domain owner and the user.

Using language that casts the MLM as doing something wrong is a fundamental 
misrepresentation of the situation.

> If that is the problem, why did you participate in the original DMARC
> effort? The issue was clear even back then.

The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.

Actually, part of the effort was to enable Sending domains to identify their 
own mail that was being sent without aligned DKIM signing or from places not 
authorized through SPF - in other words, not properly authorized but 
legitimate, hence feedback loops.

This was a point of significant confusing during the initial effort.

It is not reasonable to impose a substantial and permanent cost on the external 
internet, for an organization's inability to monitor and regulate behavior 
within the organization.

Whereas it is entirely reasonable to have a standard that facilitates detecting 
externally-generated traffic that has unauthorized use of a domain name.

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

[Dave Crocker]

On 7/21/2020 12:32 PM, Dotzero wrote:



On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker > wrote:


On 7/21/2020 10:58 AM, Dotzero wrote:
For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".

Please note that I did noy use either the word "spoof" or "spoofing".  
You wrote "MLM is authorized by the user". Someone without authority 
cannot authorize. In this case the user externalized the problem, not 
DMARC.


That's simple incorrect.

I give you my credit card, telling you to use it only for gasoline 
purchases while running errands for me.  You take the car on a 
cross-country joyride, running the cc charges for gasoline up.  The 
stations that  charged the gas to the card did nothing wrong.  The 
problem is internal, between you and me.


The MLM's did not do any spoofing.  They acted appropriately, as they 
have for 45 years.


If the domain owner has a problem with the user's behavior, that's 
internal, between the domain owner and the user.


Using language that casts the MLM as doing something wrong is a 
fundamental misrepresentation of the situation.




> If that is the problem, why did you participate in the original
DMARC
> effort? The issue was clear even back then.


The original DMARC effort was, in fact, to detect actual cases of
spoofing, namely unauthorized use of a domain name by outside actors.

Different problem.


Actually, part of the effort was to enable Sending domains to identify 
their own mail that was being sent without aligned DKIM signing or 
from places not authorized through SPF - in other words, not properly 
authorized but legitimate, hence feedback loops.



This was a point of significant confusing during the initial effort.

It is not reasonable to impose a substantial and permanent cost on the 
external internet, for an organization's inability to monitor and 
regulate behavior within the organization.


Whereas it is entirely reasonable to have a standard that facilitates 
detecting externally-generated traffic that has unauthorized use of a 
domain name.


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

[Dotzero]

On Tue, Jul 21, 2020 at 2:06 PM Dave Crocker  wrote:

> On 7/21/2020 10:58 AM, Dotzero wrote:
> >
> >
> > On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker  > > wrote:
> >
> > The mail is not spoofed.  Consider the definition of the word. Then
> > consider that the MLM is authorized by the user with the address in
> the
> > original From field.
> >
> > This is an interesting statement and raises a question.. Does a user
> > have the authority to authorize (some) use of a domain in a manner
> > contravening the express statement (p=reject) of the domain
> > owner/administrator? I'm going to have to say no.
>
> The user is authorized to use that address.  The problem here is not
> 'spoofing' but rather an internal personnel problem, with the user not
> adhering to the policies of the organization that authorized the user.
>
> For this case, DMARC externalizes that internal personnel problem.
>
> But it does not fit the definition of "spoofing".
>
> Please note that I did noy use either the word "spoof" or "spoofing".  You
wrote "MLM is authorized by the user". Someone without authority cannot
authorize. In this case the user externalized the problem, not DMARC.


>
> >
> > Also then consider that the existing MLM behavior has existed and
> been
> > useful for roughly 45 years.
> >
> > Slavery existed for a long time (still does in some places) and was
> > useful (for some) for a long time. Things change and evolve.
> >
> > The problem, here, is DMARC's imposing a change in email semantics.
> >
> >
> > If that is the problem, why did you participate in the original DMARC
> > effort? The issue was clear even back then.
>
>
> The original DMARC effort was, in fact, to detect actual cases of
> spoofing, namely unauthorized use of a domain name by outside actors.
>
> Different problem.
>

Actually, part of the effort was to enable Sending domains to identify
their own mail that was being sent without aligned DKIM signing or from
places not authorized through SPF - in other words, not properly authorized
but legitimate, hence feedback loops.

Michael Hammer
___
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

[Joseph Brennan]

On Tue, Jul 21, 2020 at 2:08 PM Hector Santos
 wrote:
>


> Second, DMARC is imposing a new security protocol based on the premise
> the "From" is not expected to be changed. How will the MLM/MLS fit?
>
> It can:
>
> 1) Supports the security protocol and the problem is solved.
> Exclusive domains made a published policy statement for exclusive
> signing.  The Exclusive Domains does not expect its users to be using
> their domains outside the work place. The policy is honored.

My understanding of DMARC's purpose was to protect transactional
messages from sources like banks, credit card issuers, online shopping
venues, and the like. It supposed that those messages should pass only
directly from the source to the end point, and that that was so
important to security that transport through any intermediary should
be rejected as possible forgery. For example my bank statements come
from a different domain than mail from a person at the bank.

What blew it away was Yahoo's implementation of DMARC on end user
personal mail. It was at first believed by many that Yahoo would have
to roll it back when their users could not contribute to mailing lists
or send mail to people who had old-school forwarding. Instead the
industry started developing ways to get around DMARC by changing RFC
822 From headers and RFC 821 MAIL commands... which pretty much un-did
the DMARC concept of authorization.

It has been demonstrated that #1 is not happening, and it's because
sheer deliverability of legitimate email is the priority.


-- 
Joseph Brennan
Lead, Email and Systems Applications

___
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

[Hector Santos]

On 7/21/2020 11:51 AM, Dave Crocker wrote:


Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.

The problem, here, is DMARC's imposing a change in email semantics.


Dave, there are different ways of looking at this. I've work with and 
developed MLM/MLS for as many years, and there are "mail engineering 
ethics" here to consider.


The first is Mail Tampering, which is part of 1986 US ECPA guidelines, 
  Mail Tampering was an exception, not a rule, with the MLM/MLS to 
allow for body changes. This was not a normal expectation except to 
allow a very basic overhead level with headers/footers. Absolutely no 
tampering with the context, the "gist" of the copyrighted messages, is 
never expected to be altered. It was never expected for the Author 
field to be changed unless you had a digest or something like it where 
clearly the mail was not coming from you.  In general, it would have 
been a US ECPA violation.  It was not something you often seen done, 
if ever.  The Newspaper Publisher industry is the only industry where 
legal concept of "Print To Fit" was acceptable for 100+ years.  But if 
a MLM/MLS is considered a publisher, would it be exempt?  Even then, 
the From is not changed in your letter to the editor.


Second, DMARC is imposing a new security protocol based on the premise 
the "From" is not expected to be changed. How will the MLM/MLS fit?


It can:

1) Supports the security protocol and the problem is solved. 
Exclusive domains made a published policy statement for exclusive 
signing.  The Exclusive Domains does not expect its users to be using 
their domains outside the work place. The policy is honored.


2) Unintentionally ignorant of the security protocol, does nothing. 
This is your true legacy system.


3) Intentionally ignorant of security protocol while continue to 
resign mail. This is not a legacy system if it has adapted to resign 
mail and chose to neglect and ignore the security protocol.


4) Same as #3 but also rewrites From field.

#1 and #4 will resolve the problem.  The proper protocol engineering 
fit is with #1. While #4 resolves the issue, it is perpetuating an 
undesirable design that can have serious mail engineering consequences 
simply by watering down the value of persistent 5322.From.  The #2 and 
#3 MLM/MLS will be remain as problems until they change or the user is 
made aware he can't use his exclusive domain on a public forum.



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

[Dave Crocker]

On 7/21/2020 10:58 AM, Dotzero wrote:



On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker > wrote:


The mail is not spoofed.  Consider the definition of the word. Then
consider that the MLM is authorized by the user with the address in the
original From field.

This is an interesting statement and raises a question.. Does a user 
have the authority to authorize (some) use of a domain in a manner 
contravening the express statement (p=reject) of the domain 
owner/administrator? I'm going to have to say no.


The user is authorized to use that address.  The problem here is not 
'spoofing' but rather an internal personnel problem, with the user not 
adhering to the policies of the organization that authorized the user.


For this case, DMARC externalizes that internal personnel problem.

But it does not fit the definition of "spoofing".




Also then consider that the existing MLM behavior has existed and been
useful for roughly 45 years.

Slavery existed for a long time (still does in some places) and was 
useful (for some) for a long time. Things change and evolve.


The problem, here, is DMARC's imposing a change in email semantics.


If that is the problem, why did you participate in the original DMARC 
effort? The issue was clear even back then.



The original DMARC effort was, in fact, to detect actual cases of 
spoofing, namely unauthorized use of a domain name by outside actors.


Different problem.

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

[Dotzero]

On Tue, Jul 21, 2020 at 11:52 AM Dave Crocker  wrote:

> On 7/21/2020 8:48 AM, Jesse Thompson wrote:
> > On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> >> I am advocating for MLMs to stop spoofing and make their peace with
> DMARC.
> > Maybe the recommendation should be that MLMs (or any ESP, for that
> matter) should never send as a domain they do not directly own unless it's
> authorized to send aligned mail as that domain.  (I say this as I have a
> distinguished PhD (not of CS) complaining to me that when he sends spoofed
> email from his Gmail account the messages go into spam because of DMARC.
> Why do these ESPs even allow it in the first place, putting the domain
> owner's decision to adopt DMARC as the boogieman?)
>
>
> This being a technical forum, we need to be careful and precise about
> terminology and history and, well, quite a bit more.
>
> The mail is not spoofed.  Consider the definition of the word. Then
> consider that the MLM is authorized by the user with the address in the
> original From field.
>
> This is an interesting statement and raises a question.. Does a user have
the authority to authorize (some) use of a domain in a manner contravening
the express statement (p=reject) of the domain owner/administrator? I'm
going to have to say no.


> Also then consider that the existing MLM behavior has existed and been
> useful for roughly 45 years.
>
> Slavery existed for a long time (still does in some places) and was useful
(for some) for a long time. Things change and evolve.


> The problem, here, is DMARC's imposing a change in email semantics.
>

If that is the problem, why did you participate in the original DMARC
effort? The issue was clear even back then.

Michael Hammer
___
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/21/2020 8:48 AM, Jesse Thompson wrote:

On 7/20/20 7:55 AM, Douglas E. Foster wrote:

I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) 
should never send as a domain they do not directly own unless it's authorized 
to send aligned mail as that domain.  (I say this as I have a distinguished PhD 
(not of CS) complaining to me that when he sends spoofed email from his Gmail 
account the messages go into spam because of DMARC.  Why do these ESPs even 
allow it in the first place, putting the domain owner's decision to adopt DMARC 
as the boogieman?)



This being a technical forum, we need to be careful and precise about 
terminology and history and, well, quite a bit more.


The mail is not spoofed.  Consider the definition of the word. Then 
consider that the MLM is authorized by the user with the address in the 
original From field.


Also then consider that the existing MLM behavior has existed and been 
useful for roughly 45 years.


The problem, here, is DMARC's imposing a change in email semantics.

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

[Jesse Thompson]

On 7/20/20 7:55 AM, Douglas E. Foster wrote:
> I am advocating for MLMs to stop spoofing and make their peace with DMARC.

Maybe the recommendation should be that MLMs (or any ESP, for that matter) 
should never send as a domain they do not directly own unless it's authorized 
to send aligned mail as that domain.  (I say this as I have a distinguished PhD 
(not of CS) complaining to me that when he sends spoofed email from his Gmail 
account the messages go into spam because of DMARC.  Why do these ESPs even 
allow it in the first place, putting the domain owner's decision to adopt DMARC 
as the boogieman?)

The DMARC conditional rewriting logic that the MLM providers implement inhibits 
larger DMARC adoption because it segregates people into two camps, based solely 
on their domain owner's stance towards DMARC.  If a large enough group of 
stakeholders fall into the camp of "this domain I'm using to subscribe to lists 
isn't and should never be subjected to DMARC rewriting", they will push back on 
the domain owner's attempts to publish DMARC.

Maybe this ties back into the DMARCbis discussion about pct=0.  We use pct=0 
specifically to reduce end-user confusion about MLM rewriting behavior.  Could 
the behavior induced by pct=0 be the default, somehow, rather than p=none?

Jesse

___
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

[Laura Atkins]

> On 21 Jul 2020, at 02:18, Murray S. Kucherawy  wrote:
> 
> On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins  > wrote:
> There was a research project done by an inbox provider and a major supporter 
> of DMARC presented at a MAAWG meeting a few years ago. They tried adding 
> trust indicators to the message list but found no statistically significant 
> behavioral changes by users. Given the conference policies, I hesitate to 
> mention it here, but there is research. There’s also a conference paper I 
> found, done by a computer science research team at VA Tech that looked at 
> this as well. 
> 
> I remember something about the former.  I'll see if I can find a public 
> reference to it.
> 
> "Data, data, data; we cannot make bricks without clay."

https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-hu.pdf 
 
is the conference talk I was mentioning. 

I’ll be honest, I do think both phishing and UX has evolved significantly since 
DMARC was initially announced. The protocol has not kept up with the evolution 
and it’s benefits are much less obvious than when it was initially launched. 
We’re forcing a lot of damage on normal email usage, for non-obvious benefits. 

>   
> Most clients these days seem to be hiding the RFC5322.From domain from the 
> individual end users. Mail.app on OSX does unless you change that setting 
> specifically (and it seems every few upgrades they reset the setting and then 
> hide the checkbox again). The iOS mail app doesn’t even have a setting to 
> change that I’ve been able to find. I seem to remember the last time I set up 
> a mailbox on Thunderbird (pre-2016 election as I was tracking some candidate 
> mail) they also hid the 5322.From address. 
> 
> I could be wrong but I seem to recall that at the time DMARC was published, 
> this wasn't the case.  (See my previous remarks about Gmail.)  But I agree 
> that it does seem to be the case now.

I don’t remember, either. I think clients were going down that route, though. I 
know, for instance, that the iOS mail client has never shown the email address, 
always the friendly from. 

> I'm not sure we've ever fully faced the idea that what MUAs choose to display 
> needs to be factored into the evolution of these protocols.  For as long as 
> I've been working on this, it's been the opposite.

When we’re basing a protocol on “what the user sees” and “what the user can 
trust” then I think we have to. DMARC says “users can trust that mail from 
@domain.example is really from @domain.example” but if the user never sees 
that, how do they know? 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
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

[Laura Atkins]

> On 21 Jul 2020, at 00:20, Brandon Long  
> wrote:
> 
> 
> 
> On Mon, Jul 20, 2020 at 2:00 AM Laura Atkins  > wrote:
> 
>> On 19 Jul 2020, at 19:08, Murray S. Kucherawy > > wrote:
> 
>>>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.
>> 1. That's not what it suggests, at all
>> 
>> Then I don't know what else you might mean by "end users do not reliably 
>> make trust decisions based on /any/ of the information in the rfc5322.From 
>> field".  What other data exist upon which to make trust decisions in the 
>> display of a mailbox?
> 
> There was a research project done by an inbox provider and a major supporter 
> of DMARC presented at a MAAWG meeting a few years ago. They tried adding 
> trust indicators to the message list but found no statistically significant 
> behavioral changes by users. Given the conference policies, I hesitate to 
> mention it here, but there is research. There’s also a conference paper I 
> found, done by a computer science research team at VA Tech that looked at 
> this as well. 
> 
> Was it us?  If so, I can push on folks to find and make it releasable, but I 
> don't recall that we had such a presentation but I've also been out of the 
> loop for a while and wasn't there are
> the beginning of DMARC either.  Ie, I know the ecert goldkey stuff failed on 
> this, but don't think I ever saw the data.

Wasn’t Google (which doesn’t mean Google hasn’t done similar work. Following up 
offlist. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
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

[John Levine]

In article  you write:
>Why should the rest of end-users suffer?  (some might say)
>
>Granted, we are a university.  Maybe these are just faculty being 
>hyper-sensitive to how
>their messages are appearing to their peers/students.  But isn't that enough 
>evidence that
>end-users *are* relevant?  With time, maybe we can change these end-user 
>expectations, and
>From rewriting will be the new reality that people will accept.

I don't think the claim is that users don't see anything, it's that
they're no good at using what they see to make security decisions,
something that has more to do with mental models and metaphors between
what's on the screen and reality.

>I think that draft-kucherawy-dkim-transform-02 is getting at what I was 
>originally thinking. 
>In my opinion, MLMs will *always* need to munge, because they will never know 
>if an arbitrary
>receiver will trust their non-munged mail.  Giving the receivers a way to 
>un-munge (if they
>can and/or want and/or trust) would be a productive path forward out of this 
>situation.

We already have a couple of ways to do reversible message munging,
starting with MIME message wrapping. In principle it works fine, in
practice it's awful because MUAs don't show wrapped messages
consistently and often in ways that are painful, e.g., you can see the
original author address but there's no button you can push to respond
to it.

Unwrapping a MIME attachment is a lot easier than the proposed DKIM
unmunging but I doubt either is going to show up in MTAs any time
soon.  Perhaps you could do it in the mail gateway.

R's,
John

___
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/20/2020 6:18 PM, Murray S. Kucherawy wrote:
I'm not sure we've ever fully faced the idea that what MUAs choose to 
display needs to be factored into the evolution of these protocols.  
For as long as I've been working on this, it's been the opposite.



Although various people keep citing affecting display based on dmarc, 
that's never been the essence of its motivation.  Which is good, because 
users are not affected by trust indicators. Really.  Not.


It's entirely reasonable to start with the idea that it might (or 
should) help end-user evaluation, but human factors don't serve the 
master of that kind of logic. To date, online experience is that users 
are essentially impervious to trust indicators.(*)


Rather, DMARC serves to provide some clean data to the receiving 
filtering engine, which is the only venue that matters for email 
safety.  (Well, and originating filtering engines, of course.) Not the MUA.




d/

(*) Obviously, if you have some data to the contrary...

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

On Mon, Jul 20, 2020 at 1:59 AM Laura Atkins 
wrote:

> There was a research project done by an inbox provider and a major
> supporter of DMARC presented at a MAAWG meeting a few years ago. They tried
> adding trust indicators to the message list but found no statistically
> significant behavioral changes by users. Given the conference policies, I
> hesitate to mention it here, but there is research. There’s also a
> conference paper I found, done by a computer science research team at VA
> Tech that looked at this as well.
>

I remember something about the former.  I'll see if I can find a public
reference to it.

"Data, data, data; we cannot make bricks without clay."


> Most clients these days seem to be hiding the RFC5322.From domain from the
> individual end users. Mail.app on OSX does unless you change that setting
> specifically (and it seems every few upgrades they reset the setting and
> then hide the checkbox again). The iOS mail app doesn’t even have a setting
> to change that I’ve been able to find. I seem to remember the last time I
> set up a mailbox on Thunderbird (pre-2016 election as I was tracking some
> candidate mail) they also hid the 5322.From address.
>

I could be wrong but I seem to recall that at the time DMARC was published,
this wasn't the case.  (See my previous remarks about Gmail.)  But I agree
that it does seem to be the case now.

I'm not sure we've ever fully faced the idea that what MUAs choose to
display needs to be factored into the evolution of these protocols.  For as
long as I've been working on this, it's been the opposite.

-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

[Jesse Thompson]

On 7/19/20 1:33 PM, dcroc...@gmail.com wrote:
> The essential point that needs to be made is that standards like this MUST 
> NOT be cast in terms of what end users will do.  In practical terms, this 
> work has nothing to do with end users.  Really.  Nothing.
> 
> To the extent that anyone wants to make an affirmative claim that end-users 
> /are/ relevant to this work, they need to lay that case out clearly, 
> carefully, and with material that provides objective support.(*)

I'll take a shot (admittedly, I'm having trouble keeping up with all of the 
points that have been made):

We're migrating 30,000 lists, of various types/use cases, from a MLM provider 
that is DMARC-ignorant to one that munges the From.  It rewrites the 
friendly-From in addition to the From address (this touches on Laura's point 
that even though some/most MUAs hide the domain, recipients still *see* 
something different)

We have a DMARC policy published for our 500ish domains, and an increasing 
number of the domains of our external list members are publishing DMARC.  DMARC 
enforcement (outside of our control) is also increasing - which motivates us to 
accelerate our transition to the DMARC-friendly MLM platform (one that rewrites 
the From)
 
** We have had many complaints from users about the From munging **

I could try to quantify, if that's the only way to prove the point that 
end-users matter and are relevant to this conversation.

It calls into question whether we (or any domain) should publish DMARC 
policies.  Gmail.com doesn't publish a DMARC policy, after all, and many people 
(such as some on this list) are using gmail.com to subscribe to lists, and they 
don't have to suffer the consequences of DMARC.  

Why should the rest of end-users suffer?  (some might say)

Granted, we are a university.  Maybe these are just faculty being 
hyper-sensitive to how their messages are appearing to their peers/students.  
But isn't that enough evidence that end-users *are* relevant?  With time, maybe 
we can change these end-user expectations, and From rewriting will be the new 
reality that people will accept.

The To-rewrite strategy seems interesting, in a "From-rewriting is here to 
stay" assumed world, to force MUA behavior and to help mitigate the 
auto-collecting address problem.

I think that draft-kucherawy-dkim-transform-02 is getting at what I was 
originally thinking.  In my opinion, MLMs will *always* need to munge, because 
they will never know if an arbitrary receiver will trust their non-munged mail. 
 Giving the receivers a way to un-munge (if they can and/or want and/or trust) 
would be a productive path forward out of this situation.

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.

Jesse

___
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

[Douglas E. Foster]

The court system is a poor substitute for prior deterrence or attack 
disruption.   DMARC seems to do both.

The Internet limits the utility of legal remedies because of the difficulty of 
attribution, a problem which also DMARC helps to solve.   Litigation is also 
hampered by jurisdictional boundaries that create little risk of consequences 
for the perpetrators of crime.

This forum was proposed for upgrading DMARC from informational status to 
standard status.   Instead, it has become a conspiracy to demolish it.The 
MLM problem will only be :"solved" if DMARC is completely abandoned, so that 
spoofing is once again uninhibited.   Therefore, moving from normal IETF 
"suggestion" mode to "enforced" mode will be necessary to achieve what MLM 
proponents want.   It is not what I am advocating; quite the reverse.   I am 
advocating for MLMs to stop spoofing and make their peace with DMARC.

DF


From: Benny Lyne Amorsen 
Sent: 7/20/20 5:44 AM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 
security considerations
"Douglas E. Foster"  writes:

> Ultimately, this becomes a question of power. Do domain owners have
> the right, with the help of their correspondents, to prohibit spoofing
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the
case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.

> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=reject on your domains. Many mail servers will keep
using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
body, so it appears there are better venues for you.

___
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

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

[Benny Lyne Amorsen]

Dotzero  writes:

> One might point to the fact that DMARC was just such an effort before
> it was publicly published. While there was much criticism of this when
> it was submitted to the IETF - "You just want us to rubber stamp this"
> - there was no such intent. It had worked well within the group of
> senders and receivers implementing it through private peering that the
> effort was made so that any domain of any size, both senders and
> receivers, could implement it if so desired. I think the adoption rate
> in the wild speaks for itself (volume of mail covered by DMARC).

Volume of mail covered by DMARC seems to be rather unimpressive unless
you count p=none as covered.

> You have left out one significant way of convincing receiver domains
> and their admins. We used to have our CSRs (customer service) tell
> people who received spoof emails (resulting in phishing, malware
> compromise, etc.) from emails claiming to be from our domains that
> they should contact their mail provider or email admin because the
> problem could have been avoided if DMARC were being checked. We would
> even provide them with the details and a form with all the information
> in non-technical terms. It is amazing how quickly a provider pays
> attention when their customers/users are complaining to them that the
> provider could have prevented the heartache and grief but chose not
> to. Again, this was for domains sending transactional mail with only a
> limited number (intentionally) of role and support accounts.

You can obviously do all that, but that is not what Douglas E. Foster
advocated.

> While IETF is not a lawmaking body, it has an impact on the decisions
> of lawmaking bodies just as the decisions of lawmaking bodies can
> impact the implementation of standards.

Using the IETF as a way to get laws passed favouring ones business seems
at best underhanded.

___
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

[Dotzero]

On Mon, Jul 20, 2020 at 5:44 AM Benny Lyne Amorsen 
wrote:

> "Douglas E. Foster"  writes:
>
> > Ultimately, this becomes a question of power.  Do domain owners have
> > the right, with the help of their correspondents, to prohibit spoofing
> > (unauthorized use) of their digital identity?
>
> Domain owners are free to use the court system to assert trademark
> rights and copyright. They are also free to apply whichever seals of
> digital identity that they want, of course.
>
> > Or since they are technically leaseholders, not owners, are their
> > rights conditional?
>
> You seem to be laboring under the impression that domain owners have a
> right to compel mail recipients to respect a DRM scheme. This is not the
> case. You can try to sue Google to force them to reject incoming email
> with your domain in the From: field and no valid DKIM (or whatever)
> signature, of course, but I have a hard time imagining which right you
> would assert to make the suit successful.
>
>
DMARC clearly recognizes and documents local policy.


> > Specificslly, do Internet insiders have the right to declare their
> > spoofing control efforts to be based on foolish premises, both
> > unnecessary and inconvenient, and therefore not allowed?
>
> No one, certainly not "Internet insiders" of which I am certainly not
> one, is stopping you from doing whichever spoofing control efforts you
> want on your systems.
>

One might point to the fact that DMARC was just such an effort before it
was publicly published. While there was much criticism of this when it was
submitted to the IETF - "You just want us to rubber stamp this" -  there
was no such intent. It had worked well within the group of senders and
receivers implementing it through private peering that the effort was made
so that any domain of any size, both senders and receivers, could
implement it if so desired. I think the adoption rate in the wild speaks
for itself (volume of mail covered by DMARC).

>
> Feel free to keep p=reject on your domains. Many mail servers will keep
> using that as a signal among many others, rather than as a blanket
> reject.
>
> If you want recipient mail servers to change that policy you can either
> do it by convincing their administrators or by getting a law passed. So
> far you appear to favour the latter approach, with your focus on
> "prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
> body, so it appears there are better venues for you.
>

You have left out one significant way of convincing receiver domains and
their admins. We used to have our CSRs (customer service) tell people who
received spoof emails (resulting in phishing, malware compromise, etc.)
from emails claiming to be from our domains that they should contact their
mail provider or email admin because the problem could have been avoided if
DMARC were being checked. We would even provide them with the details and a
form with all the information in non-technical terms. It is amazing how
quickly a provider pays attention when their customers/users are
complaining to them that the provider could have prevented the heartache
and grief but chose not to. Again, this was for domains sending
transactional mail with only a limited number (intentionally) of role and
support accounts.

While IETF is not a lawmaking body, it has an impact on the decisions of
lawmaking bodies just as the decisions of lawmaking bodies can impact the
implementation of standards. One need only look at the "great firewall of
China" as one example.

Michael Hammer
___
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

[Benny Lyne Amorsen]

"Douglas E. Foster"  writes:

> Ultimately, this becomes a question of power.  Do domain owners have
> the right, with the help of their correspondents, to prohibit spoofing
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the
case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.

> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=reject on your domains. Many mail servers will keep
using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
body, so it appears there are better venues for you.

___
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

[Laura Atkins]

> On 19 Jul 2020, at 19:08, Murray S. Kucherawy  wrote:

>>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.
> 1. That's not what it suggests, at all
> 
> Then I don't know what else you might mean by "end users do not reliably make 
> trust decisions based on /any/ of the information in the rfc5322.From field". 
>  What other data exist upon which to make trust decisions in the display of a 
> mailbox?

There was a research project done by an inbox provider and a major supporter of 
DMARC presented at a MAAWG meeting a few years ago. They tried adding trust 
indicators to the message list but found no statistically significant 
behavioral changes by users. Given the conference policies, I hesitate to 
mention it here, but there is research. There’s also a conference paper I 
found, done by a computer science research team at VA Tech that looked at this 
as well. 

This question is actively being studied and there is research out there. We 
don’t need to speculate or bring in individual opinions, we can look at the 
different studies folks have done. 
> 2. No doubt there is a better way to put this, but I'm not thinking of it, 
> and this isn't just my second thought on the challenge, but quite a bit more 
> than that:  This demonstrates why the IETF is a very poor venue for 
> conducting human factors discussions.
> 
> No argument here. 
> Again: There is quite a bit of experience demonstrating that providing trust 
> indicators to end users does not produce reliable -- ie, useful -- 
> decision-making by end users.
> 
> We appear to be talking past each other.  I wasn't talking about trust 
> indicators, but rather whether the RFC5322.From domain is visible..  I don't 
> have any reason yet to think trust indicators are effective.

Most clients these days seem to be hiding the RFC5322.From domain from the 
individual end users. Mail.app on OSX does unless you change that setting 
specifically (and it seems every few upgrades they reset the setting and then 
hide the checkbox again). The iOS mail app doesn’t even have a setting to 
change that I’ve been able to find. I seem to remember the last time I set up a 
mailbox on Thunderbird (pre-2016 election as I was tracking some candidate 
mail) they also hid the 5322.From address. 

There was another comment elsewhere about why not change the 5322.from address 
if it’s not visible to the enduser, and there are 2 reasons I have for that: 
The ability to search for mail from a particular author and the ability to 
block mail from a particular author. Rewriting the From: address always breaks 
the first. Some mailing lists point the Reply-To: to the original author which 
means some kinds of filtering can trigger off that. Other mailing lists point 
Reply-To: to the list address, which breaks the second. Both things are 
important to mailing list usability.

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
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 Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote:


The essential point that needs to be made is that standards like this MUST NOT 
be cast in terms of what end users will do.  In practical terms, this work has 
nothing to do with end users. Really.  Nothing.


[...]


(*) I've seen one posting here or somewhere else that noted that letting bad 
mail through can lead to end-users being deceived. I'll claim that while true, 
it is not relevant, since the behavior happens after DMARC, and the like, are 
relevant.  That is, DMARC, etc., do not inform the end-user behavior.



Aren't those two paragraphs self-contradictory?

If DMARC were dependable, maybe users would learn to trust From:.  Or maybe 
not.  Avoiding end user considerations cuts both ways.  Yet, we can trust that 
if we do a well-defined, clear job, then the whole system will work better.



Best
Ale
--

























___
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

[Douglas E. Foster]

Ultimately,  this becomes a question of power.   Do domain owners have the 
right, with the help of their correspondents, to prohibit spoofing 
(unauthorized use) of their digital identity?Or since they are technically 
leaseholders, not owners, are their rights conditional?  Specificslly, do 
Internet insiders have the right to declare their spoofing control efforts to 
be based on foolish premises, both unnecessary and inconvenient, and therefore 
not allowed?

 Original message 
From: Dave Crocker  Date: 
7/19/20  8:53 PM  (GMT-05:00) To: "Murray S. Kucherawy" 
 Cc: IETF DMARC WG  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
> On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker  <mailto:dcroc...@gmail.com>> wrote:
>
> The track record is that people are unreliable at this.
>
> There is quite a bit of distance between 'unreliable' and 'blindly
> open and read absolutely everything'.
>
> Is there?

Yes.


> If there's no part of the From field that can be considered reliable,
> then by opening even this email am I not exhibiting nearly-blind faith
> that the indicators I can see (in this case the string "Dave Crocker
> (gmail.com <http://gmail.com>)") have not been falsely generated?  How
> is this message, in terms of its trustworthiness, different from any
> other?

It's an act of curiosity, not faith.  You know that mail can be
spoofed.  You might even suspect that I'm capable of lying. (Silly, I
know, but...) Or that I might be wrong. (Truly a foolish thought.)  So
the process of deciding on the validity and worth of my message is
incremental and heuristic.

Human evaluation processes vary, but mostly are pretty complex. Except
when they aren't, though then it's often problematic.

Mostly, your line of comments is trying to apply logical reasoning,
which is rarely helpful in assessing human behavior.

All of which is why this is a really terrible forum for making
assertions or, worse, decisions, about end-user behavior.

Whereas talking in terms of receiving filtering engines is both simpler
and more useful.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
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

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

[Dave Crocker]

On 7/19/2020 5:04 PM, Murray S. Kucherawy wrote:
On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker > wrote:


The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly
open and read absolutely everything'.

Is there?


Yes.


If there's no part of the From field that can be considered reliable, 
then by opening even this email am I not exhibiting nearly-blind faith 
that the indicators I can see (in this case the string "Dave Crocker 
(gmail.com )") have not been falsely generated?  How 
is this message, in terms of its trustworthiness, different from any 
other?


It's an act of curiosity, not faith.  You know that mail can be 
spoofed.  You might even suspect that I'm capable of lying. (Silly, I 
know, but...) Or that I might be wrong. (Truly a foolish thought.)  So 
the process of deciding on the validity and worth of my message is 
incremental and heuristic.


Human evaluation processes vary, but mostly are pretty complex. Except 
when they aren't, though then it's often problematic.


Mostly, your line of comments is trying to apply logical reasoning, 
which is rarely helpful in assessing human behavior.


All of which is why this is a really terrible forum for making 
assertions or, worse, decisions, about end-user behavior.


Whereas talking in terms of receiving filtering engines is both simpler 
and more useful.


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]

On Sun, Jul 19, 2020 at 11:33 AM Dave Crocker  wrote:

> On 7/19/2020 11:08 AM, Murray S. Kucherawy wrote:
>
> gain: There is quite a bit of experience demonstrating that providing
>> trust indicators to end users does not produce reliable -- ie, useful --
>> decision-making by end users.
>>
> We appear to be talking past each other.  I wasn't talking about trust
> indicators, but rather whether the RFC5322.From domain is visible.  I don't
> have any reason yet to think trust indicators are effective.
>
> The view that the From: address, or domain, or Display-Name is used, by
> end-users, for assessing the trustworthiness of a message means it/they are
> used as trust indicators.
>
> The track record is that people are unreliable at this.
>
> There is quite a bit of distance between 'unreliable' and 'blindly open
> and read absolutely everything'.
>
Is there?

If there's no part of the From field that can be considered reliable, then
by opening even this email am I not exhibiting nearly-blind faith that the
indicators I can see (in this case the string "Dave Crocker (gmail.com)")
have not been falsely generated?  How is this message, in terms of its
trustworthiness, different from any other?

-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/19/2020 11:08 AM, Murray S. Kucherawy wrote:


gain: There is quite a bit of experience demonstrating that
providing trust indicators to end users does not produce reliable
-- ie, useful -- decision-making by end users.

We appear to be talking past each other.  I wasn't talking about trust 
indicators, but rather whether the RFC5322.From domain is visible.  I 
don't have any reason yet to think trust indicators are effective.


The view that the From: address, or domain, or Display-Name is used, by 
end-users, for assessing the trustworthiness of a message means it/they 
are used as trust indicators.


The track record is that people are unreliable at this.

There is quite a bit of distance between 'unreliable' and 'blindly open 
and read absolutely everything'.


In any event...

The essential point that needs to be made is that standards like this 
MUST NOT be cast in terms of what end users will do.  In practical 
terms, this work has nothing to do with end users. Really.  Nothing.


To the extent that anyone wants to make an affirmative claim that 
end-users /are/ relevant to this work, they need to lay that case out 
clearly, carefully, and with material that provides objective support.(*)


By contrast, say that this work provides input to a receiving filtering 
engine made the work easy to explain and understand and defend.


d/


(*) I've seen one posting here or somewhere else that noted that letting 
bad mail through can lead to end-users being deceived. I'll claim that 
while true, it is not relevant, since the behavior happens after DMARC, 
and the like, are relevant.  That is, DMARC, etc., do not inform the 
end-user behavior.


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

On Sun, Jul 19, 2020 at 5:40 AM Dave Crocker  wrote:

> 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,
>
>
> btw, I just logged in to gmail's web interface -- I normally access via
> imap -- and it is only showing display-name text.  No email address for
> any of the messages.  As far as I can tell, I have no address book at
> gmail.
>

Same.  That's why I attempted to invoke Brandon.

-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

[Murray S. Kucherawy]

On Sun, Jul 19, 2020 at 8:04 AM Dave Crocker  wrote:

> On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
>
> 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
>
> Perhaps, but since we don't have their data and we don't have their
> decision-criteria -- which might be quite different from what is needed
> here -- then it's probably a good idea not to make assumptions about the
> utility, nor to put all of the human factors marbles in the google camp.
>
Certainly it's only one data point, and as I recall it's the one that got
the most discussion during the early DMARC work.  That's what made me think
of it.  Data from multiple sources would of course be better, and I'd
happily solicit other possible sources.  My employer isn't in the inbox
game anymore, so I don't have any of my own data to offer.

I agree they might be quite different, but they also might not be.  Don't
know unless we ask.

>
>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.
>
> 1. That's not what it suggests, at all
>
Then I don't know what else you might mean by "end users do not reliably
make trust decisions based on /any/ of the information in the rfc5322.From
field".  What other data exist upon which to make trust decisions in the
display of a mailbox?

> 2. No doubt there is a better way to put this, but I'm not thinking of it,
> and this isn't just my second thought on the challenge, but quite a bit
> more than that:  This demonstrates why the IETF is a very poor venue for
> conducting human factors discussions.
>
No argument here.

> Again: There is quite a bit of experience demonstrating that providing
> trust indicators to end users does not produce reliable -- ie, useful --
> decision-making by end users.
>
We appear to be talking past each other.  I wasn't talking about trust
indicators, but rather whether the RFC5322.From domain is visible.  I don't
have any reason yet to think trust indicators are effective.

-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/19/2020 8:08 AM, John Levine wrote:

This tells us that at least at one big gorilla, the header address
isn't something that users see.  This leads to two questions, one being
why the From address is a better authentication handle than, say, DKIM d=.



I think the possibility of d= hasn't been considered seriously. I'm not 
going advocate, but it's worth thinking about this a bit, just to make 
sure we understand it's implications.


I've thought (assumed, recall) that From: was chosen because it is the 
only address value in email that is required to be present.  So it gives 
you a domain name to start from and then look up for a DMARC record.


There is always that domain name, even when there is no authentication 
information.


It's only possible to use the d= if there is a signature.  So a 
downgrade attack would succeed by merely removing the DKIM information.


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

[John Levine]

In article <0bbf7999-0b40-401f-24d0-09eb1c8ec...@gmail.com>,
Dave Crocker   wrote:
>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, 
>
>btw, I just logged in to gmail's web interface -- I normally access via 
>imap -- and it is only showing display-name text.  No email address for 
>any of the messages.  As far as I can tell, I have no address book at gmail.

I just sent my Gmail account a test message from an address that never existed 
before,
and it only showed the display name in the web site and the iOS and Android 
apps.

This tells us that at least at one big gorilla, the header address
isn't something that users see.  This leads to two questions, one being
why the From address is a better authentication handle than, say, DKIM d=.

The other is that if the users don't see the address, why do we care
if mailing lists change it? I think I have some reasonable answers,
starting with the way it screws up replies. something we know from
experience that Reply-To can't fix.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
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] Response to a claim in draft-crocker-dmarc-author-00 security considerations

[Dave Crocker]

On 7/18/2020 9:23 PM, Murray S. Kucherawy wrote:
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


Perhaps, but since we don't have their data and we don't have their 
decision-criteria -- which might be quite different from what is needed 
here -- then it's probably a good idea not to make assumptions about the 
utility, nor to put all of the human factors marbles in the google camp.



   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.


1. That's not what it suggests, at all

2. No doubt there is a better way to put this, but I'm not thinking of 
it, and this isn't just my second thought on the challenge, but quite a 
bit more than that:  This demonstrates why the IETF is a very poor venue 
for conducting human factors discussions.


Again: There is quite a bit of experience demonstrating that providing 
trust indicators to end users does not produce reliable -- ie, useful -- 
decision-making by end users.


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

[Douglas E. Foster]

Yes, Gmail is a win for Dave.   User has to hover to see the from address, 
instead of friendly name, except when the TO does not match the recipient.
null___
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, 



btw, I just logged in to gmail's web interface -- I normally access via 
imap -- and it is only showing display-name text.  No email address for 
any of the messages.  As far as I can tell, I have no address book at gmail.



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

[Douglas E. Foster]

Your comments mply that for non-MLM messages, the only purpose of rfc5322.From 
is trust.   A related action would be attribution:  after an attack, whom do I 
blame?  Domain owners do not want to be attributed to someone else's crime.But 
obviously, there are other purposes, such as searching and sorting.   These 
also depend on accurate values.   Consequently, spoofing affects multiple  
functions which are important to domain owners and message readers.  You 
asserted again that nearly all MUAs hide the From address, then ignored 
contrary data.   Gmail and Outlook have significant user bases.   No one has 
identified the long list of MUAs that hide, or indicated the market share of 
those MUAs.What has also not been explained is:   why it is an uncoscienable 
burden for MLMs to use rfc5322.From addresses of the form user=domain@MLM?  Any 
such attempt is weakened by your assertions that From matters to no one.Any MLM 
can create their own rules by operating in a dedicated domain which issues 
domain accounts to its subscribers.  But as long as it chooses to operate in a 
shared realm, it must accommodate the needs of others within the shared 
realm.DF

 Original message 
From: Dave Crocker  Date: 
7/18/20  9:32 PM  (GMT-05:00) To: "Murray S. Kucherawy" 
 Cc: IETF DMARC WG  
Subject: Re: [dmarc-ietf] Response to a claim in 
draft-crocker-dmarc-author-00 security considerations 
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

___
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 Sat 18/Jul/2020 19:24:10 +0200 Jim Fenton wrote:

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



One is filtering on From:

   o  Allow Domain Owners to assert the preferred handling of
  authentication failures, for messages purporting to have
  authorship within the domain.
   https://tools.ietf.org/html/rfc7489#section-2.1

Here, authorship should be meant to be something rather akin to a formal 
copyright holder, whereas the Author: field addresses moral attributions.  In 
that sense, authorization to rewrite From: is granted by BCP 78.[*]


OTOH, filtering on Sender: doesn't comply with the quoted purpose.


Best
Ale
--

[*] IANAL.



























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

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

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

[Dave Crocker on behalf of Kurt Andersen]

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

___
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 11:30 AM, Kurt Andersen (IETF) wrote:

Dave writes:

However, for all of the real and serious demonstration of users' being 
tricked by deceptive or false content in a message, there is no evidence that 
problematic content in a field providing information about message's author 
directly contributes to differential and problematic behavior by the end user.

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. Presumably, the cachet which was carried along with 
"important person says look into this" overcame whatever native 
caution or skepticism might have prevented them from falling prey 
otherwise.



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.


I'm not quite motivated enough, or I'd have had this message contain:

   Kurt Anderson 

and it would have passed the necessary tests...

In other words, when we talk about threats and we talk about 
mitigations, we need to be careful that they align properly.


(I suspect there's some irony in my choosing 'align' but it was not 
intentional, though I'll take the extra point for noting it.)


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Kurt Andersen (IETF)]

Dave writes:

However, for all of the real and serious demonstration of users' being
tricked by deceptive or false content in a message, there is no
evidence that problematic content in a field providing information
about message's author directly contributes to differential and
problematic behavior by the end user.

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.
Presumably, the cachet which was carried along with "important person says
look into this" overcame whatever native caution or skepticism might have
prevented them from falling prey otherwise.

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