Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Murray S. Kucherawy
On Tue, Aug 29, 2023 at 8:11 PM Dave Crocker  wrote:

> On 8/29/2023 7:46 PM, Grant Taylor wrote:
> > On 8/29/23 9:02 PM, Dave Crocker wrote:
> >
> > Why not re-use the existing DKIM solution, just with a different
> > domain / set of keys?
>
> Because it does not provide the affirmative information that I am
> postulating/guessing the originating platform can supply.
>

I have to agree.  It's compelling to consider that a high-trust domain
might flag something for my extra consideration.  This could be done
per-message, rather than per-key, which was Grant's counterproposal; the
equivalent is to generate a selector per message, which appears at least on
the surface to suffer problems of scale.

Rather than doing it in a header field, though, could it be done simply
with a new tag?

> Let a domain establish a bad reputation.  Especially if it's being
> > used for sending messages that are considered to be questionable.
>
> Establishing a reputation takes time.  The likely behavior of a bad
> actor is within a very short time-frame.
>
> And it is a single account, not the entire domain, that is the problem.
>

Or even a single message.

And I've never understood why people get enamored of the idea of relying on
bad reputations to spot bad actors.  A bad actor who thinks it has
attracted a negative reputation need only move to a new name in an
otherwise gigantic public namespace (domain name or IP address) to start
over from zero.


> > Just use different domains / keys to indicate different things.
> >
> > No new standards.  No new code.  No new config.
>
> And no new information.  Hence, current mechanisms only, which are not
> all that successful for this problem.
>

This also presumes that operators currently develop reputation based on
(d=, s=) pairs.  Is that so?  I thought it was mostly just the d= that
matters.

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


Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Steve Atkins


Sent from my iPhone

> On 30 Aug 2023, at 03:38, Grant Taylor 
>  wrote:
> 
> On 8/29/23 3:15 PM, Steve Atkins wrote:
>> Any attempt by senders to filter outbound emails based solely on content is 
>> going to have a lot of false negatives and positives, wherever you decide to 
>> draw the line.
> 
> I find the idea of using different, probably less stringent, filtering on 
> outbound than on inbound to be hypocritical.

You have much more data for inbound email, and access to a much wider range of 
reactions. That’s not “hypocritical”.

The only information a sender has that a receiver doesn’t is a broader view of 
who the recipients of messages being sent are - and that’s exactly the 
information that DKIM replay hides from the sender.

> 
> I find it tantamount to someone saying they only accept the most pristine 
> message while sending less pristine, and sometimes really tarnished, email.
> 
> Sure, there are some differences, e.g. lack of user preferences.
> 
> Why the asymmetry?
> 
> Why not apply the same filtering for outbound messages as applied to inbound 
> messages?

Because they’re quite different environments. 

> 
>> Inbound content-based filtering is much easier to get right - not least 
>> because the fallback is “just deliver it to the spam folder” - and we’re not 
>> great at that.
> 
> I guess I'm coming from a different place.  I always was more worried about 
> what I send and not upsetting the rest of the Internet than I am about what I 
> accept in.

That’s not the issue. It’s much easier to filter inbound mail accurately than 
it is outbound mail. And we’re not great at filtering inbound mail.

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


Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Dave Crocker

On 8/29/2023 7:46 PM, Grant Taylor wrote:

On 8/29/23 9:02 PM, Dave Crocker wrote:

Why not re-use the existing DKIM solution, just with a different 
domain / set of keys?


Because it does not provide the affirmative information that I am 
postulating/guessing the originating platform can supply.





Let a domain establish a bad reputation.  Especially if it's being 
used for sending messages that are considered to be questionable.


Establishing a reputation takes time.  The likely behavior of a bad 
actor is within a very short time-frame.


And it is a single account, not the entire domain, that is the problem.




Plumbing historically has had clean water and waste water. 


The behavior of spammers is not as discrete or as stable as your example 
requires.




    3. Receiving hosts can take this as a flag for extra caution. The
    damn thing still gets to victim platforms, but those platform have a
    bit more information to factor in.


I feel like this falls back to a priming problem of who sends the flag 
because not enough people are checking for it and not enough people 
will check for it because not enough people are sending it.  What's 
more is that this is going to be viewed as some as tantamount to 
$SO_AND_SO is sending $SPAM, see they even tag it as such.


The nature of a collaborative mechanism is that, yes, both sides have to 
adopt it.  Adoption takes time.


The upside of the model I'm suggesting is that a) it's pretty cheap, and 
b) it's likely to be useful to a relatively, small set of very, very 
valuable domains. So it does not have to gain widespread adoption on the 
origination side, to be useful.





DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and 
receivers opt in to use them.  Both sides are necessary.  So I'm 
wondering about looking for something the furthers the collaboration.


Or re-use the existing systems that are already in place and being 
used by much of the email community.


Just use different domains / keys to indicate different things.

No new standards.  No new code.  No new config. 


And no new information.  Hence, current mechanisms only, which are not 
all that successful for this problem.



Maybe I'm too salty for the end of a long day, but I feel like this is 
in some ways "nothing new to see here, move along".
That view has been constantly asserted here, by some folk.  Why anyone 
believing that continues to participate in this effort is a mystery.


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] What makes this posting different from the original posting?

2023-08-29 Thread Grant Taylor

On 8/29/23 9:02 PM, Dave Crocker wrote:

A possible way to think about how to approach this:

1. Use the mechanism for messages deemed spammy by the originating
platform, or for new users who do not yet have an established
quality record, or...

2. Add a header field that has semantics along the lines of "Yes I
signed this and yes I sent it, but I'm not happy about it."


Why not re-use the existing DKIM solution, just with a different domain 
/ set of keys?


Let a domain establish a bad reputation.  Especially if it's being used 
for sending messages that are considered to be questionable.


Plumbing historically has had clean water and waste water.  Now -- what 
is called -- grey water is being used in some places in parallel to the 
other two.  There is no false pretense that grey water is new nor waste. 
 Grey water is it's own thing and it is treated as such.



3. Receiving hosts can take this as a flag for extra caution. The
damn thing still gets to victim platforms, but those platform have a
bit more information to factor in.


I feel like this falls back to a priming problem of who sends the flag 
because not enough people are checking for it and not enough people will 
check for it because not enough people are sending it.  What's more is 
that this is going to be viewed as some as tantamount to $SO_AND_SO is 
sending $SPAM, see they even tag it as such.


DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and 
receivers opt in to use them.  Both sides are necessary.  So I'm 
wondering about looking for something the furthers the collaboration.


Or re-use the existing systems that are already in place and being used 
by much of the email community.


Just use different domains / keys to indicate different things.

No new standards.  No new code.  No new config.  Just a new domain / set 
of keys that need to establish a reputation, whatever that is.  That's 
something that already happens day in and day out.


And the attacker can't bypass it, if the signature covers enough (or 
all) of the message.


Maybe I'm too salty for the end of a long day, but I feel like this is 
in some ways "nothing new to see here, move along".




--
Grant. . . .
unix || die

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


Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Grant Taylor

On 8/29/23 3:15 PM, Steve Atkins wrote:
Any attempt by senders to filter outbound emails based solely on 
content is going to have a lot of false negatives and positives, 
wherever you decide to draw the line.


I find the idea of using different, probably less stringent, filtering 
on outbound than on inbound to be hypocritical.


I find it tantamount to someone saying they only accept the most 
pristine message while sending less pristine, and sometimes really 
tarnished, email.


Sure, there are some differences, e.g. lack of user preferences.

Why the asymmetry?

Why not apply the same filtering for outbound messages as applied to 
inbound messages?


Inbound content-based filtering is much easier to get right - not least 
because the fallback is “just deliver it to the spam folder” - 
and we’re not great at that.


I guess I'm coming from a different place.  I always was more worried 
about what I send and not upsetting the rest of the Internet than I am 
about what I accept in.




--
Grant. . . .
unix || die

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


Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Dave Crocker

On 8/29/2023 1:15 PM, Steve Atkins wrote:

Many, many people sign up to receive content that is, by any objective 
content-filtering standard, as spammy as an incredibly spammy thing.

Seriously, people sign up for things you would not believe.

Any attempt by senders to filter outbound emails based solely on content is 
going to have a lot of false negatives and positives, wherever you decide to 
draw the line.


So, what you say makes complete sense, of course.

And yet, I suspect that this problem nonetheless requires active 
measures at that point in the handling sequence.


The question, then, is what might help, without causing too much problem.

My immediate thought is an overlay to DKIM.  That is, an added mechanism 
that is protected by the DKIM signature.


A possible way to think about how to approach this:

   1. Use the mechanism for messages deemed spammy by the originating
   platform, or for new users who do not yet have an established
   quality record, or...

   2. Add a header field that has semantics along the lines of "Yes I
   signed this and yes I sent it, but I'm not happy about it."

   3. Receiving hosts can take this as a flag for extra caution. The
   damn thing still gets to victim platforms, but those platform have a
   bit more information to factor in.

DKIM, SPF, et al, are all 'collaborative' mechanisms. Originators and 
receivers opt in to use them.  Both sides are necessary.  So I'm 
wondering about looking for something the furthers the collaboration.


And the attacker can't bypass it, if the signature covers enough (or 
all) of the message.



d/

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] What makes this posting different from the original posting?

2023-08-29 Thread Steve Atkins


Sent from my iPhone

> On 29 Aug 2023, at 20:54, Dave Crocker  wrote:
> 
> On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote:
>> For (1), I presume the outbound site did not make a quality assessment that 
>> identified the message as "likely to be replayed".  Does this reduce to the 
>> "don't sign spam" argument?
> 
> I have no idea what the current levels of outbound filtering are, among major 
> platforms.  If it ain't already very high, yeah, seems like it should be and 
> that this is an added incentive why.

Many, many people sign up to receive content that is, by any objective 
content-filtering standard, as spammy as an incredibly spammy thing.

Seriously, people sign up for things you would not believe.

Any attempt by senders to filter outbound emails based solely on content is 
going to have a lot of false negatives and positives, wherever you decide to 
draw the line.

Inbound content-based filtering is much easier to get right - not least because 
the fallback is “just deliver it to the spam folder” - and we’re not great at 
that.

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


Re: [Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Dave Crocker

On 8/29/2023 12:30 PM, Murray S. Kucherawy wrote:
For (1), I presume the outbound site did not make a quality assessment 
that identified the message as "likely to be replayed".  Does this 
reduce to the "don't sign spam" argument?


I have no idea what the current levels of outbound filtering are, among 
major platforms.  If it ain't already very high, yeah, seems like it 
should be and that this is an added incentive why.


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] What makes this posting different from the original posting?

2023-08-29 Thread Murray S. Kucherawy
On Tue, Aug 29, 2023 at 11:10 AM Dave Crocker  wrote:

> Two thoughts:
>
>1. If the substance of the message should fail a quality assessment,
>why does it pass at the outbound (sending) site?
>2. If the problem is reasonable content, but sent to many unintended
>(or, rather, undeclared) recipients, then the only characteristic of note
>is the fact of multiple transmissions.  So I'd guess it is only a real-time
>network of receivers, working in /very/ close coordination, to detect and
>deal with the attack. (it's not difficult to imagine scattered
>retransmissions, over time, to hide the coordination.  Sort of a spread
>spectrum transmission style...)
>
>
For (1), I presume the outbound site did not make a quality assessment that
identified the message as "likely to be replayed".  Does this reduce to the
"don't sign spam" argument?

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


[Ietf-dkim] What makes this posting different from the original posting?

2023-08-29 Thread Dave Crocker
Not that this is all that new a question, but I think it might be worthy 
of more (and maybe different focus)...


When a message is used in a DKIM Replay Attack:

1. It originates from a domain name having good reputation
2. It passes quality checks from that sending domain
3. It goes to a collaborating receiving site, which presumably means
   that site is not conducting quality assessments
4. It is re-posted, preserving the original DKIM signature, but now
   becomes an attack

Two thoughts:

1. If the substance of the message should fail a quality assessment,
   why does it pass at the outbound (sending) site?
2. If the problem is reasonable content, but sent to many unintended
   (or, rather, undeclared) recipients, then the only characteristic of
   note is the fact of multiple transmissions. So I'd guess it is only
   a real-time network of receivers, working in /very/ close
   coordination, to detect and deal with the attack. (it's not
   difficult to imagine scattered retransmissions, over time, to hide
   the coordination.  Sort of a spread spectrum transmission style...)

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