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] Setting a stage for detection

[Dave Crocker]

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


So, well, umm I was merely tossing off an idea and have no idea what 
the fine-grained details of either its specification or its handling 
sequences should be.


Certainly pursuit of any proposal in this space needs to worry about 
real-world handling sequences, such as going through multiple mediators 
and the different ways mediators can preserve or break things.


For example, one version of this is "what happens when  there are 
multiple signatures from different domains?" While I've heard some 
discussion of real-world treatment of such cases, I haven't heard enough 
to know what is normal or, for that matter, useful.


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

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

[Murray S. Kucherawy]

On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker  wrote:

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

Interesting.

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

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

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

[Murray S. Kucherawy]

On Sun, Feb 12, 2023 at 1:21 PM Dave Crocker  wrote:

> One of the continuing problems with anti-abuse discussions is that
> discussion always goes to detecting bad actors.  While of course there need
> to be discussions about them, the problem is that there seem to be no
> discussions about good actors.
>
> DKIM and a mechanism such as I'm proposing gives the receiver a noise-free
> message flow to evaluate.  It can be used for finding bad actors, of
> course, but I think its primary benefit is in finding good actors.
>
I think this is a strong point.  One of the things that's stuck with me
since we were working on what became RFC 4871 is the notion that you only
really know anything when DKIM succeeds.  (But then, of course, you need to
be cautious about over-interpreting exactly what it's telling you.)  You
can't conclude anything from a failure because there are so many legitimate
failure modes.

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

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

[Dave Crocker]

On 2/12/2023 12:48 PM, Wei Chuang wrote:


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?


One of the continuing problems with anti-abuse discussions is that 
discussion always goes to detecting bad actors.  While of course there 
need to be discussions about them, the problem is that there seem to be 
no discussions about good actors.


DKIM and a mechanism such as I'm proposing gives the receiver a 
noise-free message flow to evaluate.  It can be used for finding bad 
actors, of course, but I think its primary benefit is in finding good 
actors.


With that said, now to comment on your bad actor line of consideration:

A message arrives that has the address disparity which raises concern.  
And it does not have the signed flag noting who created the disparity.


Today and forever, this could be a message from a good actor or a bad 
actor.  It will take conservative heuristics to handle, but ultimately 
the handling would be pretty much the same as today. The mechanism I've 
suggested does not make things worse for this scenario...


Except that some fraction of traffic is now trying to help the 
analysis.  If the mechanism becomes used by the primary domain names 
that are being abused, that means that the absence of the mechanism from 
a message means it is more likely the message is problematic.  But only 
"more likely".



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.


I don't really understand what you are describing.  Senders always know 
the domain they are sending to. And I don't know what it means for a 
receiver to 'verify' that they are the intended recipient, since domain 
getting mail was intended (by someone) to get it.


Further, 'intention' is distributed, given Mediators.

I also don't know what draft by Levine you are referring to.

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

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

[Wei Chuang]

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.

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
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Setting a stage for detection

[Dave Crocker]

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.


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?

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