Subject: [dmarc-ietf] Email security beyond DMARC?

From: "Douglas E. Foster" <[email-masked]>
Date: Sat, 16 Mar 2019 08:56:20 -0400

I tried to understand what IETF is doing about email security, and this 
working group seems to be the only surviving effort.   Based on the index, 
the groups attention is focused on polishing the existing DMARC 
implementaton rather than plowing new territory.   Given the devastating 
effect of WannaCry and the success of other email-based attacks, I think 
our work is far from finished.     

 DMARC / DKIM / SPF rely entirely on sender participation.   Too few 
legitimate senders are implementing these measures in the manner that was 
envisioned, and too few , and too many spam filters fail to use these tools 
fully.
  
 DMARC represents a powerful concept which can be applied by the receiver, 
with adjustments, in ways that liberates the receiver from dependency on 
legitimate senders becoming fearless.   I can articulate how that could be 
done, but I do not know how to start that discussion appropriately.
  
 Doug Foster

---

From: Grant Taylor <[email-masked]>
Date: Sat, 16 Mar 2019 10:59:26 -0600

On 3/16/19 6:56 AM, Douglas E. Foster wrote:
> working group seems to be the only surviving effort.   Based on the 
> index, the groups attention is focused on polishing the existing DMARC 

I can understand why you think there is more work to be done about email 
security.  However I don't know that this, DMARC, group is the best 
location to push for it.

I don't know what is left to do with DMARC, other than refining—or 
polishing as you said—needs to be done.  I'm not saying that there isn't 
anything left to do, just that I'm ignorant of what that might be. 
Please share suggestions if you have any.

I also think it's somewhat unfair to imply that DMARC, and other email 
protection technologies, don't protect email to the desired level, 
*especially* when people don't /properly/ utilize said technology.  I am 
willing to accept that said technologies may be too difficult for mass 
adoption.

I do believe that SPF, DKIM, and DMARC are capable of protecting email 
when they are used /properly/.

There a numerous other technologies that have been developed in the last 
100 years that help protect against one form of problem or another.  Yet 
these technologies, some simple to use, don't get utilized like they 
should.  Some examples that come to mind are the seat belt in cars, 
HTTPS encryption on web servers, IPsec, even S/MIME encryption for email 
comes to mind.  Sure, some of these technologies need some help 
initially configuring.  But almost all of them are simple to use /after/ 
they have been configured.  Yet, all of them are under utilized.

I think that this pattern says something about humans choosing to not 
use technology, even when a viable solution for the problem at hand exists.

> legitimate senders are implementing these measures in the manner that 
> was envisioned, and too few , and too many spam filters fail to use 
> these tools fully.

IMHO, the execution of a technology is independent of the viability of 
said technology.  Unless it is an indication of a symptomatic problem 
with said technology.

> DMARC represents a powerful concept which can be applied by the 
> receiver, with adjustments, in ways that liberates the receiver from 
> dependency on legitimate senders becoming fearless.

I am curious to learn what you are talking about.

> I can articulate how that could be done, but I do not know how to start 
> that discussion appropriately.

I don't know what the proper process is.  But given how you are 
referencing DMARC, I'm guessing that you're not completely out of the 
ball park by bringing it up on this mailing list.

-- 
Grant. . . .
unix || die

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Mar 2019 16:04:17 -0700

On 3/16/2019 5:56 AM, Douglas E. Foster wrote:
> dependency on legitimate senders

Since use of DMARC begins with a record publish by the author domain 
owner, I can't imagine how you think DMARC can be used without 
dependence on legitimate senders.  Nor can I guess what protections or 
scenarios you have in mind.

d

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 18 Mar 2019 13:57:54 +0100 (CET)

Hi Doug

> our work is far from finished.

You may want to have a look on some upcoming work. We just started a new 
mailing list, which includes the topic of email security:

  MEDUP -- Missing Elements for Decentralized and Usable Privacy

To subscribe:

- https://www.ietf.org/mailman/listinfo/medup

Please find more information on:

- https://mailarchive.ietf.org/arch/msg/medup/mbrbhFekt_srXShzpCa4RiXgPbY

- https://mailarchive.ietf.org/arch/msg/pearg/oBjgAwG3_eoR6tpLQGTE_9OggzQ

The former also includes a list of Internet-Drafts describing the MEDUP 
challenges.

Please be also informated that the LAMPS WG has requested a new work item 
on email header protection to be added to its charter.

Hope that helps!

Best,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

---

From: DAMY gustavo <[email-masked]>
Date: Tue, 19 Mar 2019 18:02:59 +0000

Very useful links Bernie, thanks for the info.
I wonder if this working group will eventually will make reference  to the concept of PeP  protocol to reinforce the usage of DMARC  you are mentioning below? 

Best Regards
Gustavo Damy

-----Original Message-----
From: Bernie Hoeneisen <[email-masked]> 
Sent: Monday, March 18, 2019 1:58 PM
To: Douglas E. Foster <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Hi Doug

On Sat, 16 Mar 2019, Douglas E. Foster wrote:

> I tried to understand what IETF is doing about email security, and 
> this working group seems to be the only surviving effort.  Based on 
> the index, the groups attention is focused on polishing the existing 
> DMARC implementaton rather than plowing new territory.  Given the 
> devastating effect of WannaCry and the success of other email-based 
> attacks, I think our work is far from finished.

You may want to have a look on some upcoming work. We just started a new mailing list, which includes the topic of email security:

To subscribe:

The former also includes a list of Internet-Drafts describing the MEDUP challenges.

Hope that helps!

Best,
  Bernie

--

http://ucom.ch/

---

From: "Doug Foster" <[email-masked]>
Date: Tue, 19 Mar 2019 14:25:14 -0400

Can one of you elaborate on the potential connection between PeP and DMARC,
or more generally, the connection beteen PeP and spam filtering? 

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of DAMY gustavo
Sent: Tuesday, March 19, 2019 2:03 PM
To: [email-masked]
Cc: Bernie Hoeneisen
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Very useful links Bernie, thanks for the info.
I wonder if this working group will eventually will make reference  to the
concept of PeP  protocol to reinforce the usage of DMARC  you are mentioning
below? 

Best Regards
Gustavo Damy

-----Original Message-----
From: Bernie Hoeneisen <[email-masked]>
Sent: Monday, March 18, 2019 1:58 PM
To: Douglas E. Foster <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Hi Doug

To subscribe:

Please be also informated that the LAMPS WG has requested a new work item on
email header protection to be added to its charter.

Hope that helps!

Best,
  Bernie

--

http://ucom.ch/

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

---

From: "John Levine" <[email-masked]>
Date: 19 Mar 2019 14:42:09 -0400

>or more generally, the connection beteen PeP and spam filtering? 

I presume that PeP would make spam filtering much harder since the filters can't
look inside the messages.

Be careful what you wish for, and remember that bad guys can use all
our shiny toys, too.

R's,
John

---

From: 'Bernie Hoeneisen' <[email-masked]>
Date: Tue, 19 Mar 2019 19:43:57 +0100 (CET)

Dear Doug / Damy

There is no direct connection between pEp and DMARC, as pEp is not relying 
on centralized infrastructure.

cheers
  Bernie

---

From: DAMY gustavo <[email-masked]>
Date: Wed, 20 Mar 2019 09:33:45 +0000

OK thank you Bernie, 
But pEp  is also based on MIME   (which requires trust on at least one centralized  CA which falls into the centralized infrastructure  isn't it ?)

And yes I agree bad guys could use this as well (but probably they already do it anyway) so through pEp  + DMARC it wouldn't be even safer to exchange messages finally an easy way to have End to end encryption using open protocols for webmail  (and not just rely on existing APPS/SW) implementations? 

At the end you have to trust someone and that could be linked to existing DMARC DNS records? 

Regards
Gustavo

-----Original Message-----
From: 'Bernie Hoeneisen' <[email-masked]> 
Sent: Tuesday, March 19, 2019 7:44 PM
To: Doug Foster <[email-masked]>
Cc: DAMY gustavo <[email-masked]>; [email-masked]
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

Dear Doug / Damy

There is no direct connection between pEp and DMARC, as pEp is not relying on centralized infrastructure.

cheers
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 20 Mar 2019 15:05:19 +0100 (CET)

> look inside the messages.

This is a mutual challenge of email systems that use true end-to-end 
encryption. While those improve Privacy, spam mitigation means need to be 
adjusted.

On the other hand, pEp (inherently) also provides some additional means 
for spam mitigation / detection (on the client), e.g. end-to-end 
authentication of the peer user.

If pEp is applied on top of existing email infrastructure (which is likely 
the case in most scenarios), DMARC can also be used in conjunction with 
pEp emails.

cheers,
  Bernie

---

From: Bernie Hoeneisen <[email-masked]>
Date: Wed, 20 Mar 2019 15:22:35 +0100 (CET)

On Wed, 20 Mar 2019, DAMY gustavo wrote:

> But pEp is also based on MIME (which requires trust on at least one 
> centralized CA which falls into the centralized infrastructure isn't it 
> ?)

MIME does not require a centralized CA. I presume your mean S/MIME. pEp is 
not based on S/MIME. However, pEp is working on interoperability with 
S/MIME.

> And yes I agree bad guys could use this as well (but probably they 
> already do it anyway) so through pEp + DMARC it wouldn't be even safer 
> to exchange messages finally an easy way to have End to end encryption 
> using open protocols for webmail (and not just rely on existing APPS/SW) 
> implementations?

This depends on the requirements or threat scenarios a system is based on. 
If Privacy is top priority, I see no other way than using a true 
end-to-end system.

cheers,
  Bernie

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Mar 2019 07:25:24 -0700

On 3/20/2019 7:22 AM, Bernie Hoeneisen wrote:
>> centralized CA which falls into the centralized infrastructure isn't 
>> it ?)
> 
> MIME does not require a centralized CA. I presume your mean S/MIME. pEp 
> is not based on S/MIME. However, pEp is working on interoperability with 
> S/MIME.

well, mime uses IANA for registering types, and that's certainly a 
centralized operation...

d/

---

From: Grant Taylor <[email-masked]>
Date: Wed, 20 Mar 2019 08:47:24 -0600

> well, mime uses IANA for registering types, and that's certainly a 

True.

However there is a distinct difference in a central numbering authority 
verses a central certificate authority.  The former has little impact on 
system security (presuming that everyone agrees / uses the same value 
for things) compared to the latter, which has significant impact on 
security.

We can also operate without said central numbering authority if we all 
agree that specific things are specific values.  We can't (effectively) 
operate without central certificate authorities.  At least not given our 
current operating model at the scale that we operate ate.

-- 
Grant. . . .
unix || die

---

From: "John R Levine" <[email-masked]>
Date: 20 Mar 2019 10:48:48 -0400

On Wed, 20 Mar 2019, Bernie Hoeneisen wrote:
>>  I presume that PeP would make spam filtering much harder since the filters
>>  can't look inside the messages.
>

I'm assuming that you don't have have much experience with spam filtering 
at scale.  Let me just say that if you can't look inside the messages, 
there is a vast amount of spam you can't catch.  Many systems send a 
mixture of spam and legit mail, which from the outside look the same.

> On the other hand, pEp (inherently) also provides some additional means for 
> spam mitigation / detection (on the client), e.g. end-to-end authentication 
> of the peer user.

This is a common misconception among people unfamiliar with spam 
filtering.  The majority of the spam that makes it into my inbox is sent 
from real accounts that are either compromised or created in bulk at free 
mail sytstems.  Authentication would make no difference since all that 
spam could authenticate perfectly.

> the case in most scenarios), DMARC can also be used in conjunction with pEp 
> emails.

DMARC has never been an anti-spam scheme.  It's about phishing, which is 
not the same thing.

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

---

From: DAMY gustavo <[email-masked]>
Date: Thu, 21 Mar 2019 13:00:46 +0000

Dear John,

But if the AIM is to have an end to end easier to implement encryption +  phishing protection, probably it would make sense? 
This will not reduce the SPAM but using DMARC and properly tune the policy P=reject; pct=100 would help to secure the content and reduce the phishing,  (and sure definitely will not help  to avoid SPAM)  from those compromised accounts.

> If pEp is applied on top of existing email infrastructure (which is 
> likely the case in most scenarios), DMARC can also be used in 
> conjunction with pEp emails.

DMARC has never been an anti-spam scheme.  It's about phishing, which is not the same thing.

Regards.
Gustavo

---

From: Dotzero <[email-masked]>
Date: Thu, 21 Mar 2019 09:36:13 -0400

> DMARC has never been an anti-spam scheme.  It's about phishing, which is

I'm going to have to disagree with you John. DMARC is about preventing
direct domain abuse. It does not specifically address phishing as the bad
guys can simply use cousin domains, homoglyphs, etc.

Michael Hammer

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2019 10:31:00 -0400

> But if the AIM is to have an end to end easier to implement encryption + 
> phishing protection, probably it would make sense?

Not really.

> This will not reduce the SPAM but using DMARC and properly tune the 
> policy P=reject; pct=100 would help to secure the content and reduce the 
> phishing, (and sure definitely will not help to avoid SPAM)  from those 
> compromised accounts.

Nope.  Please review my previous message.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2019 10:32:34 -0400

> guys can simply use cousin domains, homoglyphs, etc.

Well, it's abount a subset of phishing.  It's surely more about phishing 
than about spam.

R's,
John

PS: on the other hand, if your point is that DMARC impases significant 
costs for small and dubious benefits, I wouldn't disagree.

---

From: Ken Simpson <[email-masked]>
Date: Thu, 21 Mar 2019 10:00:49 -0700

> Well, it's abount a subset of phishing.  It's surely more about phishing

IMHO, by cutting out direct domain spoofing, DMARC makes it easier for
receivers to craft algorithms that spot impersonation attacks. Once you
have configured DMARC, receivers can build - for example - a machine
learning system that learns what your legitimate email looks like. They can
use that same system to identify messages that look like your legitimate
email but which do not actually originate from your domain.

If you want to detect domain impersonation or "brand" impersonation, you
first have to have a verifiable ground truth corpus. That is what DMARC
offers.

Regards,
Ken

---

From: "John R Levine" <[email-masked]>
Date: 21 Mar 2019 13:09:18 -0400

> receivers to craft algorithms that spot impersonation attacks.

I realize that's the theory, but do we know how well that works in 
practice?

Regards,

---

From: Ken Simpson <[email-masked]>
Date: Thu, 21 Mar 2019 10:12:52 -0700

> I realize that's the theory, but do we know how well that works in

That would be crossing into the realm of tradecraft.

Regards,
Ken

---

From: Dave Crocker <[email-masked]>
Date: Thu, 21 Mar 2019 10:45:42 -0700

> That would be crossing into the realm of tradecraft.

While I understand and respect the reality of that point, I fear it is 
problematic from an industry standpoint...

d/

---

From: "Doug Foster" <[email-masked]>
Date: Thu, 21 Mar 2019 14:36:04 -0400

I am all for anything that cuts unwanted email.   Not sure of the need to distinguish between spam and phishing.

I am assuming that I am the only one in this group not using DMARC.   You heard my problems with SPF.  

What do you do for SPF Exceptions?

·         We have never seen a legitimate sender who needed an exception?

·         We whitelist the source IP address and trust that it will only be used for appropriate domains?

·         We whitelist the sender domain and hope it will never be spoofed?

·         Something else?

Also, how do you handle SPF non-pass:   Neutral, Softfail, Syntax errors,  or  Excessive nesting

Do you handle SPF any differently between senders with DMARC enforcement and those without?

Doug Foster

From: dmarc [mailto:[email-masked]] On Behalf Of Ken Simpson
Sent: Thursday, March 21, 2019 1:01 PM
To: John R Levine
Cc: IETF DMARC WG; Dotzero
Subject: Re: [dmarc-ietf] Email security beyond DMARC?

IMHO, by cutting out direct domain spoofing, DMARC makes it easier for receivers to craft algorithms that spot impersonation attacks. Once you have configured DMARC, receivers can build - for example - a machine learning system that learns what your legitimate email looks like. They can use that same system to identify messages that look like your legitimate email but which do not actually originate from your domain.

If you want to detect domain impersonation or "brand" impersonation, you first have to have a verifiable ground truth corpus. That is what DMARC offers.

Regards,

Ken

---

From: Дилян Палаузов <[email-masked]>
Date: Fri, 29 Mar 2019 21:12:31 +0000

Hello Doug,

my understanding is, that SPF complements DKIM only in the cases, where the MTA is not capable to sign an email, e.g. a
bounce.

So, if your MTA can DKIM-sign everything, you do not need SPF.

> Do you handle SPF any differently between senders with DMARC enforcement and those without?

No, SPF does not work with aliases (where no SRS is applied).

My experience sending email over a mailing list to some domains directly and to the same domains indirectly (over other
hosts, which in fact do aliasing) for a DKIM signature that failed is, that due SPF the direct emails were delivered,
whereas the indirect emails were not.  This also created indirect feedback, that is not in my logs very precise.  So I
concluded to remove SPF TXT records and next time such things happen, I can check in the logs which message in
particular was rejected and maybe avoid such situations in the future.

Regards
  Дилян