Subject: Re: [dmarc-ietf] Phishing attacks on the Display From

From: "John Levine" <[email-masked]>
Date: 11 Dec 2014 22:59:58 -0000

>4.       Anything else?

Figure out how to display signed mail from famous brands in a
distinctive way analogous to browser green bars, and tell people
to look for that.

Crooks can figure out ways to misspell Paypal faster than you can
blacklist them, and half the time the crooks don't even bother to fake
the From: address any more, expecting people to pay attention to the
pretty graphics in the message body.

R's,
John

PS: The technology to do green bar S/MIME signatures is about 98% in
place now.

---

From: Terry Zink <[email-masked]>
Date: Fri, 12 Dec 2014 00:56:49 +0000

> to look for that. The technology to do green bar S/MIME signatures 
> is about 98% in place now.

1. Hotmail/outlook.com puts a green shield in the web UX in front of trusted senders who authenticate. Is that what you mean?

2. They do it based upon SPF/DKIM + sender's brand is on their internal list. How is that different than the S/MIME thing you mention?

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
Sent: Thursday, December 11, 2014 3:00 PM
To: [email-masked]
Cc: Terry Zink
Subject: Re: [dmarc-ietf] Phishing attacks on the Display From

R's,
John

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Dec 2014 17:06:46 -0800

On 12/11/2014 4:56 PM, Terry Zink wrote:
>> distinctive way analogous to browser green bars, and tell people to
>> look for that. The technology to do green bar S/MIME signatures is
>> about 98% in place now.
> 
> 1. Hotmail/outlook.com puts a green shield in the web UX in front of
> trusted senders who authenticate. Is that what you mean?

Do you have some empirical data that that's useful, at scale?  That is,
that is reduces end-user mistakes?

>From your previous note:

> How do we combat Display From (Friendly From) attacks? For example:

The very difficult challenge, here, is to define the vulnerability
sufficiently precisely so that we can consider remedies while not
killing the utility of the field.  That's the simpler technical
challenge.  The more difficult one is the same as I ask about above:
Proving efficacy.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2014 22:42:37 -0500

> 1. Hotmail/outlook.com puts a green shield in the web UX in front of trusted senders who authenticate. Is that what you mean?

Only sort of.  That's ad-hoc since each recipient system has their private 
list of green-bar-worthy senders.  (I mean, if I wanted to get into it, 
how would I do so?)

> 2. They do it based upon SPF/DKIM + sender's brand is on their internal 
> list. How is that different than the S/MIME thing you mention?

S/MIME signs the message body using the same kind of certificates that 
browsers use for HTTPS connections, so you should be able to get an EV 
certificate for S/MIME the same way you do for HTTPS.  The problem is that 
as far as I know, no MUAs look for the EV flag or display EV mail any 
differently from any other signed message.  The other problem is that no 
major webmail handles S/MIME at all, even though the spec has been stable 
for decades and it's in Outlook, Thunderbird, and all the other desktop 
MUAs.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Steve Atkins <[email-masked]>
Date: Thu, 11 Dec 2014 21:23:32 -0800

On Dec 11, 2014, at 7:42 PM, John R Levine <[email-masked]> wrote:

> Only sort of.  That's ad-hoc since each recipient system has their private list of green-bar-worthy senders.  (I mean, if I wanted to get into it, how would I do so?)

It's also difficult for my bank to do any useful user education about that if it's only supported by one freemail provider. It would need to be supported by most major MUAs - with compatible implementations and a consistent UI - before they could start that process.

Cheers,
  Steve

---

From: Sven Krohlas <[email-masked]>
Date: Fri, 12 Dec 2014 08:12:45 +0100

Hi,

> distinctive way analogous to browser green bars, and tell people

in Germany there exists »trustedDialog« for that use case. Most
major ISPs take part in it and use it in their web frontends.

Basically a message is being displayed with a brand logo iff
DKIM verification was successfull and they are on a white list.

Details are only available in German, as I can see it:
http://united-internet-dialog.de/digital-mail-solutions

---

From: "John Levine" <[email-masked]>
Date: 12 Dec 2014 18:14:55 -0000

>> Only sort of.  That's ad-hoc since each recipient system has their private list of
>green-bar-worthy senders.  (I mean, if I wanted to get into it, how would I do so?)
>
>It's also difficult for my bank to do any useful user education about that if it's only
>supported by one freemail provider. It would need to be supported by most major MUAs -
>with compatible implementations and a consistent UI - before they could start that
>process.

Right.  To be useful it has to be consistent and well-publicised.
Green bar certs in browsers are the best analogy I can think of.

R's,
John

---

From: Terry Zink <[email-masked]>
Date: Sat, 13 Dec 2014 01:02:02 +0000

Thanks for everyone's thoughts. It sounds like doing something with the Display and training users on it is the consensus.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
Sent: Friday, December 12, 2014 10:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Phishing attacks on the Display From

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 12 Dec 2014 17:27:40 -0800

> Thanks for everyone's thoughts. It sounds like doing something with the Display and training users on it is the consensus.

Dear Terry,

This effort should include considerations for Sender header fields in addition to From header fields which Outlook already permits with on behalf of or by ensuring the Sender header field is displayed.  Being constrained to just the From header field is only suitable for transactional messages where it can be assumed these header fields share the same domain.  When a domain might wish to permit message forwarding to a different provider or participate in various mailing lists it is crucial recipients be able to deduce who authored the content as being distinct from that of the Sending agent.  The relationship between the Sender and the Author might be understood by the recipient or separately authorized using a mechanism like tpa-label.  Email is not HTTP. Failing to separately recognize Author/Sender roles has proven disruptive when DMARC policy is applied against normal email accounts.

Regards,
Douglas Otis