Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Fri, Feb 10, 2023 at 2:31 PM Michael Thomas  wrote:

> On 2/10/23 2:10 PM, Evan Burke wrote:
>
> The M3AAWG BCP will cover recommended header signing/oversigning policies.
> I'll make sure that's shared here when it's published.
>
> Any idea when that might drop?
>

I'll roughly summarize the guidance here for now. The primary audience for
these recommendations is senders/signers with high volume shared signing
domains; these domains are prime targets for replay because of their good
reputation. Other approaches exist, but these are the ones that can
generally be implemented relatively quickly.

- Screen new accounts based on industry standard methods
- Scan outbound mail for spam-like content, and restrict or block sending
based on results. Pay closer attention to new accounts, or accounts that
are otherwise high-risk.
- Monitor for signs of replay via abuse reports and third party tools
- Oversign Date and Subject headers
- Set signature expiration via x=, with expiration on the order of 30
minutes to a few days, depending on details of your signing processes
- After implementing oversigning and signature expiration, rotate keys
- Consider signing mail from new or higher risk accounts differently -
perhaps using a shorter signature expiration or different signing domain

Implied here is that Date and Subject are signed in the first place, which
in practice is almost always the case. In a small (n=35) survey of my own
personal mail last year, 97% of sending platforms signed Subject, and 89%
signed Date.

Top two most effective techniques here, in terms of minimizing long-term
viability of replay, are 1) signature expiration, and 2) shorter expiration
for higher-risk accounts.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Evan Burke]

On Mon, Feb 13, 2023 at 10:42 AM Michael Thomas  wrote:

>
> On 2/13/23 2:49 AM, Laura Atkins wrote:
> >
> > Basically saying if you're not filtering outbound mail for abuse,
> > you're part of the problem.
> >
> > I don’t see how that’s relevant to the discussion here.
> It's extremely relevant. If you don't want to be viewed as a spamming
> domain, do your part to not send spam. This really isn't rocket science.
> >
> > Most of the outbound mail is not detectable as spam (it’s not sent in
> > bulk and it is sent to opt-in email addresses). So it won’t catch the
> > send-one-message-to-myself case. If we’re looking at linking to spam
> > landing sites, it’s trivial for the site to show one thing during the
> > initial send and then be a wholly different site when it’s sent by the
> > spammer.
> According to some others here, the spammers have to go to elaborate ends
> to not have it detected as spam. I don't recall if they specified
> whether it was incoming or outgoing (or both) that they needed to evade.
>

Both - the spam group executing these replay attacks engages in extensive
testing to identify and exploit any weakness in inbound and outbound
filters. DKIM replay using a good-reputation signing domain is one way
through certain inbound filters. Manual testing of different content, to
find what's least suspicious, is a way through both outbound and inbound
filters. (DKIM replay is not their only way through inbound filters, but
it's what we're here to talk about.)

No reasonable large-scale sender operates without outbound filtering, but
given how much time this spam group spends finding content that passes
filtering, and the high amplification factor of replay (1 million to 1 is
not unheard of), outbound filtering is a minimally effective defense
against replay.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/13/23 2:49 AM, Laura Atkins wrote:


Basically saying if you're not filtering outbound mail for abuse, 
you're part of the problem.


I don’t see how that’s relevant to the discussion here.
It's extremely relevant. If you don't want to be viewed as a spamming 
domain, do your part to not send spam. This really isn't rocket science.


Most of the outbound mail is not detectable as spam (it’s not sent in 
bulk and it is sent to opt-in email addresses). So it won’t catch the 
send-one-message-to-myself case. If we’re looking at linking to spam 
landing sites, it’s trivial for the site to show one thing during the 
initial send and then be a wholly different site when it’s sent by the 
spammer.
According to some others here, the spammers have to go to elaborate ends 
to not have it detected as spam. I don't recall if they specified 
whether it was incoming or outgoing (or both) that they needed to evade.


The issue at hand is: can we tighten up the DKIM protocol to make it 
more resistant to replay attacks? Telling the victims that the problem 
is they’re not doing outbound filtering isn’t helpful, nor does it 
address the problem. Expecting the spammer to do outbound filtering 
doesn’t seem to be a useful pathway. If we could convince spammers to 
outbound filter their spam we’d have solved the problem.


Er, huh? It's the sending provider who should be doing outbound 
filtering, not the spammer. And sorry, if you want to keep your 
reputation as a sender up and you're not doing outbound filtering you 
really have nobody to blame but yourself. You're essentially an open relay.


Mike


___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Setting a stage for detection

[Laura Atkins]

> On 12 Feb 2023, at 20:48, Wei Chuang  
> wrote:
> 
> 
> 
> On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker  > wrote:
> Folks,
> 
> There appears to be no perfect way to distinguish a Replay attack from a 
> legitimate re-posting by an Alias or even a Mailing list (that preserves 
> the original DKIM signature.)
> 
> The only 'signal' that is valid, also is ambiguous.  The signal is that 
> the rfc5321.Mail command has an address that is not in any of the 
> rfc5322 address fields.   The ambiguity, of course, is that that's also 
> true for Alias.
> 
> I'm wondering about designing some assistance by the author's platform 
> and the Aliasing platform, to flag what they've done.
> 
> Imagine adding a header field like "Separate-Envelope:", possibly 
> listing the domain name of the site putting the flag there, and having 
> them add a DKIM signature to cover it and the rest of the message.
> 
> This could also be done by a spammer doing Replay, of course. But the 
> point is that this added mechanism now creates a noise-free basis for 
> evaluating this class of traffic associated with that signed domain.
> 
> Agreed that reputation systems can play a role when the spammer decides to 
> participate. 

One thing I’ve been telling folks is that a DKIM d= isn’t a reputation. The d= 
is a strong identity. That identity can be used to hang a reputation on - where 
the reputation is based on all the mail containing that identity. 

I think it might be helpful if we shifted the discussion from DKIM is a 
reputation to DKIM is an identity. That reframes the question as:

How do we improve the DKIM protocol so that we can minimize the ability of an 
unauthorized 3rd party to misappropriate the identity of the signer?

laura 



> 
> It's not that the receiving filter could not detect the disparity 
> between envelope and content addresses. It's that the receiver is 
> getting a flag from whomever did it.
> 
> If, for example, the domain name is of the originating service, then 
> it's clearly not Replay.
> 
> If it is from an Aliasing site, the receiver can quickly build up a 
> reputation for that site, to aid in determining replay or not.
> 
> Thoughts?
> 
> In this model, let's consider the Receiver's actions.  
> 1. Say the spammer doesn't want to participate in creating a 
> Separate-Envelope, how would a receiver detect this as Replay?  Is the idea 
> that Separate-Envelope identifies the Alias or Mailing-lIst?  Is the 
> verification process that the Receiver notices that the header is missing?
> 2. You've noted what happens when the spammer participates in generating 
> Separate-Envelope
> 3. A non-spammer should have a Separate-Envelope, which will validate.
>  
> FWIW a different approach but overlaps this idea is that a sender identifies 
> the domain they intend to send to.  The receiving system verifies that they 
> are the intended recipient domain.  I think John Levine has a draft about 
> this.  I have a draft that expands some of that idea further.
> 
> -Wei
>  
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net 
> mast:@dcrocker@mastodon.social
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org 
> https://www.ietf.org/mailman/listinfo/ietf-dkim 
> 
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

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






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Setting a stage for detection

[Alessandro Vesely]

On Sun 12/Feb/2023 22:51:25 +0100 Dave Crocker wrote:

On 2/12/2023 1:44 PM, Murray S. Kucherawy wrote:
Would this work if it passes through more than one layer of aliasing? That 
is, can this work if "Separate-Envelope" appears more than once? Do they all 
have to be signed, order preserved, etc.?



Sounds like re-inventing ARC.


Best
Ale
--





___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Laura Atkins]

> On 12 Feb 2023, at 21:49, Michael Thomas  wrote:
> 
> 
> 
> On 2/12/23 1:34 PM, Murray S. Kucherawy wrote:
>> On Fri, Feb 10, 2023 at 2:13 PM Michael Thomas > > wrote:
>> Another thing that should probably be discussed is outbound spam filtering. 
>> At a high level, this is really about the sender sending spam. But email 
>> afaik is silent on whether senders or receivers should filter for spam (and 
>> if there is, it would be good to reference it). Sender filtering is 
>> especially pertinent and may well have clues of how a sender can mitigate 
>> it. A breakdown of how spammers defeat that outbound filtering would be 
>> really useful. For example, is the spam intended for mailboxes on the 
>> sending domain (eg, gmail)? Or do they go through a two stage process where 
>> they first get the spam through the sender, and then test it on the intended 
>> receiving domains? All of that would be really helpful.
>> 
>> I think it's sufficient for us to acknowledge that, in either direction, no 
>> spam filter is 100% accurate.  It can be tempting to say "You shouldn't sign 
>> spam, and if you do, you're the problem", but I'm sympathetic to those in 
>> that business who are faced with the reality that they'll never get it 100% 
>> right.  Instead, I think we have to accept that reputable signers will 
>> occasionally be tricked into signing spam, and the goal then is to try to 
>> develop some new signal that can be provided to verifiers to handle those 
>> cases. 
>> 
>> The problem statement document proposed for the WG does spell this out, I 
>> think.  What do you find missing in terms of the details?  Some of the nitty 
>> gritty probably varies from one email provider to the next, for example.
>> 
> It didn't exactly call it out? It called out outsourced outbound filtering I 
> thought, but that's just acknowledging that it exists? Or did I miss 
> something? 
> 
> Maybe what's needed is essentially what you wrote. 
> 
> "while senders intent on keeping a good reputation must filter outbound mail 
> for spam and other abuse, these filters are not 100% effective." 
> 
> Basically saying if you're not filtering outbound mail for abuse, you're part 
> of the problem.
> 
I don’t see how that’s relevant to the discussion here. 

Most of the outbound mail is not detectable as spam (it’s not sent in bulk and 
it is sent to opt-in email addresses). So it won’t catch the 
send-one-message-to-myself case. If we’re looking at linking to spam landing 
sites, it’s trivial for the site to show one thing during the initial send and 
then be a wholly different site when it’s sent by the spammer. 

The issue at hand is: can we tighten up the DKIM protocol to make it more 
resistant to replay attacks? Telling the victims that the problem is they’re 
not doing outbound filtering isn’t helpful, nor does it address the problem. 
Expecting the spammer to do outbound filtering doesn’t seem to be a useful 
pathway. If we could convince spammers to outbound filter their spam we’d have 
solved the problem.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

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






___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim