Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Deutschmann]

On Sun, 25 Dec 2022, you wrote:
>> It's easy to sort wanted mail between forwards/mailing-lists and normal
>> narrow-casted mail.  Spam can masquerade as either; but if possible a
>> spammer would want to look like narrow-casted mail as that is the only
>> kind that could be expected to arrive from a stranger.  To use this
>> exploit, they must give that up.
>>
> If you're talking about replay, I don't understand "must".  The replay
> attack under discussion works fine if it's unicast.

The spammer wants it to *look* unicast, not actually be unicast.  That
means the From: and To: align with MAIL FROM: and RCPT TO:, and that the
single From: address passes all available forgery checks.

The To: header is covered by DKIM, hence the spammer *has* to use a
generic To: that can be correct for at most a single intended victim.

While in theory he could do the trick once for each victim, that's silly
as it means one pass through the singer-victim's smarthost *per* spam
victim. He's giving up the advantage of blinding his signer-victim's
Abuse Desk to the true "fan-out" of his e-mail, which is the only reason
to consider this hack.

 Michael Deutschmann 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sat, Dec 24, 2022 at 9:12 PM Michael Deutschmann 
wrote:

> On Mon, 12 Dec 2022, you wrote:
> > > Blind-carbon-copy is already a sign of spam.
> >
> > Except when it's not, like this very mailing list.
>
> Only if you don't whitelist *all* forwarders you set up and mailing lists
> you have joined first, overriding the Bcc filter on a match.
>

I've always expected that requiring users to register and deregister every
mailing list they join or depart would be interpreted as tedious and a
disincentive, resulting in complaints (and thus support costs or lost
customers) when they forget or get it wrong.  It seems like a tactic that
won't succeed at scale.


> It's easy to sort wanted mail between forwards/mailing-lists and normal
> narrow-casted mail.  Spam can masquerade as either; but if possible a
> spammer would want to look like narrow-casted mail as that is the only
> kind that could be expected to arrive from a stranger.  To use this
> exploit, they must give that up.
>

If you're talking about replay, I don't understand "must".  The replay
attack under discussion works fine if it's unicast.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Deutschmann]

On Mon, 12 Dec 2022, you wrote:
> > Blind-carbon-copy is already a sign of spam.
>
> Except when it's not, like this very mailing list.

Only if you don't whitelist *all* forwarders you set up and mailing lists
you have joined first, overriding the Bcc filter on a match.

This does mean Bcc-blocking is an anti-spam trick that most ISPs are
absolutely incapable of using because they do not know their users well.
But it's not the first anti-spam technique to have this problem.

DCC also requires mailing list whitelisting.

So does a recieverside SPF implementation that actually has an effect on
deliverabilty, is correct, and not Baka.  (It's Baka to give any attention
to a Pass without an explicit whitelist of the sender, it is incorrect to
give any attention to a Fail when you don't have a complete forwarder
whitelist.)

It's easy to sort wanted mail between forwards/mailing-lists and normal
narrow-casted mail.  Spam can masquerade as either; but if possible a
spammer would want to look like narrow-casted mail as that is the only
kind that could be expected to arrive from a stranger.  To use this
exploit, they must give that up.


The way I look at it, up to now there have been two main approaches to
spamming, and this trick may add a third.

1. First, the old-school chickenboner tactics where you forge everything
you can get away with, and often try to exploit systems you don't own to
conceal your true ISP.

2. Second, the approach that tries to exploit Baka recieverside
deployments by actually buying a domain and pretending to be a
newly-minted vanity domain sending narrow-casted mail with perfect
SPF/DKIM/alignment credentials.  The mail still is broadcast, but in one
transaction per victim so it's not obvious to an automated system.

3. Finally, the new trick.  It also lets you exploit the Baka, but locks
you in to pretending to be a mailing list.

All along, it looks to me that #2 is still pareto superior to #3 for the
bad guys.

Although one thing that might explain the fuss; maybe the point of sealing
this hole is that the big e-mail providers would like to agree to
whitelist each other in a top-down fashion without user input, rather than
bottom-up whitelisting of one email address at a time by user request.

If a provider was silly enough to make such an arrangement, then they
could be vulnerable to #3 alone, because vanity domains (both friendly and
spammer) aren't part of the cartel.

 Michael Deutschmann 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/16/22 5:42 PM, Evan Burke wrote:


On Fri, Dec 16, 2022 at 3:29 PM Grant Taylor 
 wrote:



Perhaps it's my ignorance, but I don't see us approaching, much less
getting better than 99.9% accuracy.  And let's be honest, in any
other
field, 99.9% accuracy is really good accuracy.


To clarify: my point was not "99% is not good enough". My point was - 
99% effective ESP defenses in normal scenarios end up completely 
ineffective for replay scenarios, IF you measure based on volumes of 
spam sent. When a single message turns into 100 million replays, 
attackers can justify spending a lot of time and effort to get that 1 
message out.


At this point, I have to ask what you think this wg can do about it. All 
of the solutions I can think about are completely out of scope of IETF. 
If you're trying to get amplification to make receivers do something 
you're probably going to be disappointed because IETF is very 
experienced at pushing on string to no effect.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Fri, Dec 16, 2022 at 3:29 PM Grant Taylor  wrote:

>
> Perhaps it's my ignorance, but I don't see us approaching, much less
> getting better than 99.9% accuracy.  And let's be honest, in any other
> field, 99.9% accuracy is really good accuracy.
>

To clarify: my point was not "99% is not good enough". My point was - 99%
effective ESP defenses in normal scenarios end up completely ineffective
for replay scenarios, IF you measure based on volumes of spam sent. When a
single message turns into 100 million replays, attackers can justify
spending a lot of time and effort to get that 1 message out.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Grant Taylor]

On 12/16/22 12:36 PM, Evan Burke wrote:
As pointed out in another response, the amplification factor of replays 
means that signup anti-spam systems which are 99% effective are not good 
enough; even manual review is imperfect at scale. All it takes is a 
single malicious account to get through review, and you can have 
millions of replays happening.


If possible, please add some numbers to the conversation.

Does anyone have any idea how many millions of messages Google / Yahoo / 
Microsoft (individually or combined) send per say?


To me, it turns into a numbers game.  Even if we get less than 0.1% 
slipping through, that's still a LOT of messages slipping through. 
1,000,000,000 messages with 99.9% accuracy is still 1,000,000 unwanted 
messages.


Perhaps it's my ignorance, but I don't see us approaching, much less 
getting better than 99.9% accuracy.  And let's be honest, in any other 
field, 99.9% accuracy is really good accuracy.


I do see more and more email being sent.

So if we can't realistically improve accuracy, and the number of 
messages sent a day continues to grow, the number of unwanted messages 
is going to continue to grow.






--
Grant. . . .
unix || die



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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/16/22 3:10 PM, Evan Burke wrote:


I ask because I would assume that a proper DKIM signature
including the
To: header would mean that the message could only be replayed to the
same recipient and pass DKIM validation.  --  There is the separation
between the envelope RCPT and the To: / CC: headers.


The separation between RCPT TO and To: (or CC:) is exactly what's 
being exploited here. To: is present, the signature covers it and is 
valid, but To: does not match the RCPT TO address. Just like BCC delivery.


But the message-id is common across all of the transactions, and it's 
normally signed (MUST ?). So you could certainly detect that it's 
essentially a big bcc.


Mike

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

(Sorry, forgot to reply to the list on my previous message. Grant's quotes
include it in full.)

On Fri, Dec 16, 2022 at 1:57 PM Grant Taylor  wrote:

> On 12/16/22 12:50 PM, Evan Burke wrote:
> > Yes, but the other issue is there's no reliable real-time reporting or
> > monitoring mechanism to tell you your domain is getting replayed*.
>
> It doesn't seem like the lack of real-time reporting is isolated to
> DKIM.  The lack of real-time reporting seems like a larger issue that
> far supersedes anything that DKIM can do.
>
> > So you wait for end recipients to send you spam complaints, sometimes
> > a day or two later, or you use ISP provided tools which are available
> > with 1 day delay, and that's quite a bit too long when an attacker
> > can send on the order of 50-100 million per hour.
>
> I know that replay spam is an issue.  But I don't understand the
> mechanics of it.  Do the messages not include a To: header?  Or is it
> something like "undisclosed recipients"?
>
> I ask because I would assume that a proper DKIM signature including the
> To: header would mean that the message could only be replayed to the
> same recipient and pass DKIM validation.  --  There is the separation
> between the envelope RCPT and the To: / CC: headers.
>

The separation between RCPT TO and To: (or CC:) is exactly what's being
exploited here. To: is present, the signature covers it and is valid, but
To: does not match the RCPT TO address. Just like BCC delivery.



> > * With the exception of DKIM-based complaint feedback loops. As far as
> > I'm aware, replay spam volume has been many orders of magnitude higher
> > to domains which *don't* offer those. I suspect that's intentional.
>
> Probably.
>
>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Wed, Dec 14, 2022 at 3:54 PM Jim Fenton  wrote:

>
> I’m not an ESP, of course, but it seems like they need to do more vetting
> of new customers (like perhaps manually reviewing their mailings) until
> they are convinced those new customers are good actors. I realize this is
> an expensive thing to do, but the ESPs are, after all, loaning their good
> email reputation to their customers and they need to protect that. Because
> of relays, this needs to be done even if those customers appear to be
> sending to a relatively small list of recipients.
>

As pointed out in another response, the amplification factor of replays
means that signup anti-spam systems which are 99% effective are not good
enough; even manual review is imperfect at scale. All it takes is a single
malicious account to get through review, and you can have millions of
replays happening.

Responding more generally to some of the other questions about the
structure of these messages/attacks, and why various proposed detection
methods aren't useful:

- SPF? They just change the MFROM, that can't be signed; no mechanism
exists that enforces DKIM d= and MFROM domain alignment, and a significant
amount of legitimate mail does not align between those two domains, so
that's not a useful reputation identifier.
- DMARC? Attacker controls the From domain, or uses a shared domain with no
DMARC record or with a p=none record.
- DNSBLs? Most DNSBLs don't have spamtrap representation at large consumer
mailbox providers, so they're blind to this spam.
- Limited ipv4 space? You can find a lot of non-sequential, clean enough
IPs if you spend time and effort on it. (And they do.)
- Large sets of RCPT TOs? Attackers replay messages individually instead,
just like legitimate high volume email delivery systems.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Grant Taylor]

On 12/14/22 7:21 PM, Evan Burke wrote:
Generally: x= is automatic and will usually be faster, and requires no 
engineering effort to build out the key management service, and no 
ongoing operational/maintenance/infrastructure costs.


I did say "possibly a LOT, more complex".


Looks like a lot of complexity for little to no benefit over x=.


My understanding of part of the thread is that attackers are re-playing 
messages during the validity time covered by x= and that there is desire 
for a solution to overcome that.


I sort of loosely equate what I'm talking about to that of a CRL wherein 
it's possible to revoke / invalidate a TLS certificate before the "Not 
Valid After" date & time passes.


So it sounds like from the two "operational (overhead)" comments that 
the idea might provide an answer to the question -- as I understand it 
-- though some people may choose that the overhead is not worth using 
this answer.




--
Grant. . . .
unix || die



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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Thu 15/Dec/2022 00:46:42 +0100 Jim Fenton wrote:

On 13 Dec 2022, at 17:00, Michael Thomas wrote:


Which brings up a question: even though they pass on DKIM they should fail on 
SPF, right? For transactional email that seems like a big old red flag, right?


Some people use receive-side forwarders (e.g., college alumni addresses) to 
have a consistent email address if they change ISP. That will, completely 
legitimately, cause SPF failures on transactional email.



ale@pcale:~$ dig +short member.fsf.org txt
"v=spf1 ip4:0.0.0.0/1 ip4:128.0.0.0/1 ip6:0::/1 ip6:8000::/1 +all"


Best
Ale
--




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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 15 Dec 2022, at 00:46, Grant Taylor 
>  wrote:
> 
> On 12/14/22 11:10 AM, Evan Burke wrote:
>> It doesn't. Most of the accounts are caught before sending. All it takes is 
>> one to slip through the anti-spam detections and then go send millions of 
>> replay spam messages or more - even if that account is shut down quickly 
>> after sending.
> 
> What would happen if the ESPs DKIM implementation got, possibly a LOT, more 
> complex in that key pairs used to sign outgoing email from clients with keys 
> specific to each client?
> 
> That way if ~> when the ESP needed to cancel a client's service, the ESP 
> could also withdraw the client's public key in the ESP's zone(s) thereby 
> breaking the DKIM signature by rendering it unvalidatable.  I'd think that 
> this would largely comedown to a TTL issue on the DKIM's public key record in 
> DNS and implementation complexity.
> 
> What am I failing to take into account?

Operational overhead. 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Wed, Dec 14, 2022 at 4:47 PM Grant Taylor  wrote:

>
> That way if ~> when the ESP needed to cancel a client's service, the ESP
> could also withdraw the client's public key in the ESP's zone(s) thereby
> breaking the DKIM signature by rendering it unvalidatable.  I'd think
> that this would largely comedown to a TTL issue on the DKIM's public key
> record in DNS and implementation complexity.
>
> What am I failing to take into account?
>

Generally: x= is automatic and will usually be faster, and requires no
engineering effort to build out the key management service, and no ongoing
operational/maintenance/infrastructure costs. Looks like a lot of
complexity for little to no benefit over x=.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Grant Taylor]

On 12/14/22 11:10 AM, Evan Burke wrote:
It doesn't. Most of the accounts are caught before sending. All it takes 
is one to slip through the anti-spam detections and then go send 
millions of replay spam messages or more - even if that account is shut 
down quickly after sending.


What would happen if the ESPs DKIM implementation got, possibly a LOT, 
more complex in that key pairs used to sign outgoing email from clients 
with keys specific to each client?


That way if ~> when the ESP needed to cancel a client's service, the ESP 
could also withdraw the client's public key in the ESP's zone(s) thereby 
breaking the DKIM signature by rendering it unvalidatable.  I'd think 
that this would largely comedown to a TTL issue on the DKIM's public key 
record in DNS and implementation complexity.


What am I failing to take into account?



--
Grant. . . .
unix || die



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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

On 13 Dec 2022, at 9:06, Evan Burke wrote:

> On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:
>
>> Is there anything that you can say about the types of domains whose
>> reputations are suffering as a result of replay attacks? Are they, for
>> example, small consumer mailbox providers, email sending providers, or
>> services that for some reason allow third parties to send (presumably
>> transactional) email through their servers?
>>
>
> Predominantly ESPs, but really anyone with substantial sending volume and
> good reputation on the d= domain. ESPs seem to be the primary target
> because they tend to have the highest sending volume, so the attacker can
> send more replays before reputation and deliverability degrade.

I’m not an ESP, of course, but it seems like they need to do more vetting of 
new customers (like perhaps manually reviewing their mailings) until they are 
convinced those new customers are good actors. I realize this is an expensive 
thing to do, but the ESPs are, after all, loaning their good email reputation 
to their customers and they need to protect that. Because of relays, this needs 
to be done even if those customers appear to be sending to a relatively small 
list of recipients.

I am less sympathetic to this problem if it is primarily the result of 
insufficient diligence on the part of ESPs.

-Jim

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/14/22 3:46 PM, Jim Fenton wrote:

On 13 Dec 2022, at 17:00, Michael Thomas wrote:


Which brings up a question: even though they pass on DKIM they should fail on 
SPF, right? For transactional email that seems like a big old red flag, right?

Some people use receive-side forwarders (e.g., college alumni addresses) to 
have a consistent email address if they change ISP. That will, completely 
legitimately, cause SPF failures on transactional email.

There are tons of other options these days. But I really wasn't talking 
about that part. It's what happens before it gets forwarded. If it 
arrives in a giant bcc where SPF fail and the domain normally passes, 
that seems like a red flag.


Mike

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

On 13 Dec 2022, at 17:00, Michael Thomas wrote:

> Which brings up a question: even though they pass on DKIM they should fail on 
> SPF, right? For transactional email that seems like a big old red flag, right?

Some people use receive-side forwarders (e.g., college alumni addresses) to 
have a consistent email address if they change ISP. That will, completely 
legitimately, cause SPF failures on transactional email.

-Jim

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/14/22 3:06 PM, Murray S. Kucherawy wrote:

On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas  wrote:

On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:


This tactic appears to me to have three problems: (1) negative
reputations are of little value to receivers, because attackers
can easily shed them; (2) if I have to remember everything with a
negative reputation for some undetermined period of time, I now
have a resource problem; (3) I can just not sign my mail, because
maybe no reputation is better than a negative one.


I don't understand #1. As in they can move to another service? Or
what?

Right.  IP address gets a bad reputation?  Move to another one.  
Domain blocklisted?  Register another one. etc.  Any bad reputation is 
trivially exchanged for a neutral one.  That leaves us in a world 
where only positive reputations are meaningful, and presumably once 
you have one you'll work to protect it.


Unless they're running ipv6, that's getting harder and harder to do, of 
course. And don't DNSBL's also blacklist subnets too? That's certainly 
not optimal for whoever is hosting them. ipv4 space costs money these days.



As for 3, it's pretty easy to cons up a new domain with fresh
neutral reputation and still enjoy the supposed benefit of mail
being signed for awhile. If you factor SPF in though it probably
gets harder because now you need not only a new domain, but the
underlying network connectivity to avoid detection.

Yep, but if a receiver values DKIM more than SPF, for instance, then 
maybe they're willing to forgive that lack of support.  Maybe the 
forwarding problem bugs you enough that you're forced into such a 
position, for instance.


 Which brings up a question: even though they pass on DKIM they
should fail on SPF, right? For transactional email that seems like
a big old red flag, right?

Yes, but that doesn't work for all applications or flows.  It depends 
on what tolerances work for your use case and your users.


It seems to me that the attack is a pretty narrow use case. That is, 
spam disguised as marketing email. That seems like a use case that SPF 
covers well. And it would be really suspicious to have a mile long set 
of RCPT-TO's for that kind of use case where SPF fails, right? And I'm 
not sure why they would prefer one or the other -- they are just inputs 
to a larger data set. But if something with good reputation that 
normally passes SPF too starts sending mail where SPF fails, that's like 
a red flag, right? Again the ESP use case should be pretty predictable.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 5:00 PM Michael Thomas  wrote:

> On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:
>
>
> This tactic appears to me to have three problems: (1) negative reputations
> are of little value to receivers, because attackers can easily shed them;
> (2) if I have to remember everything with a negative reputation for some
> undetermined period of time, I now have a resource problem; (3) I can just
> not sign my mail, because maybe no reputation is better than a negative one.
>
> I don't understand #1. As in they can move to another service? Or what?
>
Right.  IP address gets a bad reputation?  Move to another one.  Domain
blocklisted?  Register another one.  etc.  Any bad reputation is trivially
exchanged for a neutral one.  That leaves us in a world where only positive
reputations are meaningful, and presumably once you have one you'll work to
protect it.

> As for 3, it's pretty easy to cons up a new domain with fresh neutral
> reputation and still enjoy the supposed benefit of mail being signed for
> awhile. If you factor SPF in though it probably gets harder because now you
> need not only a new domain, but the underlying network connectivity to
> avoid detection.
>
Yep, but if a receiver values DKIM more than SPF, for instance, then maybe
they're willing to forgive that lack of support.  Maybe the forwarding
problem bugs you enough that you're forced into such a position, for
instance.

>  Which brings up a question: even though they pass on DKIM they should
> fail on SPF, right? For transactional email that seems like a big old red
> flag, right?
>
Yes, but that doesn't work for all applications or flows.  It depends on
what tolerances work for your use case and your users.

> In both cases you need to keep track of both as somebody with a bad rep
> might get better and one with a good rep might get worse, right? That is,
> this isn't static. Preferential of course is pretty subjective. I suspect
> that most of these filters operate much like spamassassin which gives
> weights to various factors, so good and bad are both useful.
>

Sure but on my email, I would like you to have only positive signal, to the
extent I can control that.  Or, at least, as little negative signal as
possible.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Wed, Dec 14, 2022 at 2:10 AM Alessandro Vesely  wrote:

> Would someone please explain this trick to me, who never contacted an ESP?
>
>  From what I heard, I imagine someone opens new account at Mailchimp, say,
> creates a campaign and sends a test message to herself, which she will
> later
> replay.  How come it works every time?
>

It doesn't. Most of the accounts are caught before sending. All it takes is
one to slip through the anti-spam detections and then go send millions of
replay spam messages or more - even if that account is shut down quickly
after sending.

This means there are incentives for attackers to put a lot of time and
effort into getting that one account successfully created, even if that
means a lot of failed attempts in the process.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Tue 13/Dec/2022 18:06:55 +0100 Evan Burke wrote:

On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:


Is there anything that you can say about the types of domains whose
reputations are suffering as a result of replay attacks? Are they, for
example, small consumer mailbox providers, email sending providers, or
services that for some reason allow third parties to send (presumably
transactional) email through their servers?


Predominantly ESPs, but really anyone with substantial sending volume and
good reputation on the d= domain. ESPs seem to be the primary target
because they tend to have the highest sending volume, so the attacker can
send more replays before reputation and deliverability degrade.



Would someone please explain this trick to me, who never contacted an ESP?

From what I heard, I imagine someone opens new account at Mailchimp, say, 
creates a campaign and sends a test message to herself, which she will later 
replay.  How come it works every time?



Best
Ale
--







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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/13/22 6:35 AM, Murray S. Kucherawy wrote:


This tactic appears to me to have three problems: (1) negative 
reputations are of little value to receivers, because attackers can 
easily shed them; (2) if I have to remember everything with a negative 
reputation for some undetermined period of time, I now have a resource 
problem; (3) I can just not sign my mail, because maybe no reputation 
is better than a negative one.


I don't understand #1. As in they can move to another service? Or what?

As for 3, it's pretty easy to cons up a new domain with fresh neutral 
reputation and still enjoy the supposed benefit of mail being signed for 
awhile. If you factor SPF in though it probably gets harder because now 
you need not only a new domain, but the underlying network connectivity 
to avoid detection.


Which brings up a question: even though they pass on DKIM they should 
fail on SPF, right? For transactional email that seems like a big old 
red flag, right?




In contrast, positive reputations are far fewer in number, far more 
valuable to collect and protect, and very likely last a lot longer.  
Giving preferential treatment to a domain that earns a positive 
reputation seems like a much better approach.


In both cases you need to keep track of both as somebody with a bad rep 
might get better and one with a good rep might get worse, right? That 
is, this isn't static. Preferential of course is pretty subjective. I 
suspect that most of these filters operate much like spamassassin which 
gives weights to various factors, so good and bad are both useful.


Mike

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/13/22 9:06 AM, Evan Burke wrote:



On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:

This is interesting and surprised me a bit. I had expected that
the senders of the messages being replayed were the large consumer
mailbox providers, because it would be easy for spammers to hide
in a large crowd and because the reputation of the large mailbox
providers is (I expect) fairly bullet-proof just because of their
size.


I can't speak to whether large consumer mailbox providers' signatures 
are getting replayed, but with the scale of replay spam we're talking 
about - on the order of billions per day, at its peak - that's 
probably enough to make a difference in reputation for even the 
largest MBPs.


So if they are sending billions of piece of spam within minutes, say, of 
getting a piece of mail signed, I don't know what this working group can 
do about this. Signatures definitionally need to be valid in transport 
time. And the notion that MDA's stripping the signature doesn't work 
either since they'll just send to one that doesn't.


I've always been really skeptical about calling these things "replays" 
because that is a perfectly valid use of email. The only difference 
between legitimate and illegitimate is the content which IETF can't 
address. There may well be mitigation but that seems well out of the 
scope of a standards body like IETF (MAAGW otoh, might be a good venue).


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Tue, Dec 13, 2022 at 8:45 AM Jim Fenton  wrote:

> This is interesting and surprised me a bit. I had expected that the
> senders of the messages being replayed were the large consumer mailbox
> providers, because it would be easy for spammers to hide in a large crowd
> and because the reputation of the large mailbox providers is (I expect)
> fairly bullet-proof just because of their size.


I can't speak to whether large consumer mailbox providers' signatures are
getting replayed, but with the scale of replay spam we're talking about -
on the order of billions per day, at its peak - that's probably enough to
make a difference in reputation for even the largest MBPs.


> Is there anything that you can say about the types of domains whose
> reputations are suffering as a result of replay attacks? Are they, for
> example, small consumer mailbox providers, email sending providers, or
> services that for some reason allow third parties to send (presumably
> transactional) email through their servers?
>

Predominantly ESPs, but really anyone with substantial sending volume and
good reputation on the d= domain. ESPs seem to be the primary target
because they tend to have the highest sending volume, so the attacker can
send more replays before reputation and deliverability degrade.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

On 12 Dec 2022, at 12:11, Evan Burke wrote:

> These attacks were very narrowly targeted; the vast majority of DKIM replay
> spam this year has been sent to just a few of the largest consumer mailbox
> providers. In that context, lack of awareness of the problem is a poor
> argument against trying to solve it.

This is interesting and surprised me a bit. I had expected that the senders of 
the messages being replayed were the large consumer mailbox providers, because 
it would be easy for spammers to hide in a large crowd and because the 
reputation of the large mailbox providers is (I expect) fairly bullet-proof 
just because of their size.

Is there anything that you can say about the types of domains whose reputations 
are suffering as a result of replay attacks? Are they, for example, small 
consumer mailbox providers, email sending providers, or services that for some 
reason allow third parties to send (presumably transactional) email through 
their servers?

-Jim

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Tue, Dec 13, 2022 at 2:54 AM Alessandro Vesely  wrote:

> Perhaps they could devise better methods than asking _accountable? (Y/N)_
> on a
> questionnaire.  Linking to bank accounts is an example.
>

Would you link a free email account to your bank account for any reason?  I
don't think I would.  I'll go somewhere else.

A discernment possibility is to sign differently.  RFC 6376 specified an
> Agent
> or User Identifier tag, i=, as a finer grained identity.  One having
> i=bullshit...@example.com would still be a valid DKIM signature.
> Alternatively, could use subdomains, d=bullshit.example.com.  How long
> would it
> take receivers to learn it?
>

This tactic appears to me to have three problems: (1) negative reputations
are of little value to receivers, because attackers can easily shed them;
(2) if I have to remember everything with a negative reputation for some
undetermined period of time, I now have a resource problem; (3) I can just
not sign my mail, because maybe no reputation is better than a negative one.

In contrast, positive reputations are far fewer in number, far more
valuable to collect and protect, and very likely last a lot longer.  Giving
preferential treatment to a domain that earns a positive reputation seems
like a much better approach.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Mon 12/Dec/2022 15:50:44 +0100 Laura Atkins wrote:

On 12 Dec 2022, at 14:34, Murray S. Kucherawy  wrote:

On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely mailto:ves...@tana.it>> wrote:
The alternative is to say: Well, if you can't make at least one of those 
two quantities bulletproof, then don't sign your mail.  That, though, 
sounds a lot to me like tossing DKIM in the bin.


On the opposite, if Gmail restricted signing to accountable users only, its 
signatures would gain value.  If they started doing so it would soon be 
noticed, and signatures would acquire a meaning in delivery decisions.


Is the cost of imposing a program that vets every user comparable to that of 
the damage caused by this attack vector?  My impression is that it is not.


I’m not aware of Gmail being a significant victim here - although it’s possible 
they are.



I'm not aware of their taking any significant measure (after the effort, a few 
years ago, to reorganize all the different accounts on their different 
platforms.)  Yes, security has a cost.  Why are banks insisting on 2fA?



Endowing signatures with a significant value increases the overall value of 
DKIM.


Presumably they already have significant value.  That's why this attack works 
already.


They’re an identity of a known sender that invests time and resources into 
building and managing their reputation. Google? Maybe not. But the email 
service providers who do a lot to keep the spammers off their network are a 
common victim. These spammers know that they get better delivery if their mail 
is signed by the email service provider. The email service provider’s detectors 
and defenses are enough to stop the spammer from being able to send through the 
ESP. So the spammer sends one email to an account they own and takes a 
reputation they’ve already been told they shouldn’t be using.



I guess you refer to the same incident you touched on a few threads ago.  Did 
it happen more than once to the same ESP?  To more ESPs?  Cannot (did not) they 
configure their DKIM filter to not sign for untrusted prospects?




A DKIM signature is an identity. That identity has a reputation. Attacks that 
borrow the identity belonging to senders with good reputation benefit from that 
reputation. It’s not about any DKIM signature. It’s not about a random DKIM 
signature. It’s about a known entity. Even if Gmail only signed mail from 
accountable users, there is still the possibility of spammers posing as 
accountable users.



Perhaps they could devise better methods than asking _accountable? (Y/N)_ on a 
questionnaire.  Linking to bank accounts is an example.


A discernment possibility is to sign differently.  RFC 6376 specified an Agent 
or User Identifier tag, i=, as a finer grained identity.  One having 
i=bullshit...@example.com would still be a valid DKIM signature. 
Alternatively, could use subdomains, d=bullshit.example.com.  How long would it 
take receivers to learn it?




The whole idea of a DKIM replay attack is that this is mail that cannot be 
directly sent through the infrastructure of the domain owner. That, itself, 
implies the domain owners are doing quite a bit to stop the spam from coming 
out of their network. If they weren’t doing a good job then replay attacks 
wouldn’t be happening - the mail would just be sent over that network directly.

Asking for the domain owners to “stop sending spam” when the whole replay 
process indicates they are stopping spam out of the networks they control seems 
a bit of a non-starter to me.



The securing activity you describe certainly has non-negligible costs.  Then 
why do we abhor the cost of classifying users?


Most likely, DMARC was branded as a requirement for email security and DKIM 
came as a consequence, without worrying too much about what is being signed. 
Replay attacks found the weak point of that paradigm.  Don't allow guests into 
secured areas of your premises.



Best
Ale
--






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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 1:31 AM, Laura Atkins wrote:




On 11 Dec 2022, at 21:41, Michael Thomas  wrote:
Sure. I guess the question is how much effort would spammers be 
willing to expend before trying some other tactics?


Quite a bit, actually. I remember sitting in a 17th floor conference 
room on market street with a particular sending organization that 
explained to me their business model was to have a boiler room full of 
people iterating through content and trying to deliver it to their own 
mailbox at hotmail.com . When they found text that 
got through, they sent that until the filters caught up, then moved 
onto the next piece of content. They started this at 5pm pacific time 
and would spam all night. They did this every day.  That was 2007 or 
so (said company was sued into oblivion by the FTC not long after that 
conference room meeting).
Doesn't that stink to high heaven as abuse at hotmail? At least the 
sender can take action directly rather than hoping somebody downstream 
will.


The amount of energy spammers expend to bypass filters is significant. 
That includes bypassing port25 blocks. For instance, I’m aware of a 
company using BGP routing tricks to host their outbound spam cannons 
on major cloud providers (that block port25 by default). The IPs are 
treated as throwaway and they burn and turn them when they get too 
blocked.


Can we even quantize what the value of, say, a signed gmail piece of 
email is?  I think that's a basic question that needs to be answered 
before we declare this a problem. I for one am all ears as "DKIM 
gives you better deliverability" has always been a sort of squishy 
statement.


This is one of those questions that is, IMO, unanswerable for a lot of 
reasons. The biggest of which is: the value to whom?
Well, I assume that spammers value some domains over others, so they 
probably have some metric. But it's a tradeoff of how much boiler room 
you need vs. the reputation of the signer they're trying to coattail and 
their efforts to not send spam to keep it.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 12:11 PM, Evan Burke wrote:


On Mon, Dec 12, 2022 at 11:21 AM Michael Thomas  wrote:

On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:

But I want to return to my previous point of whether
reputation is even quantifiable, and whether somebody has
actually gone out and researched it. We can say that this is
a problem in theory, but do we have any data to back it up? I
kinda think that should be table stakes before talking about
rechartering.


The industry appears to think it's a factor. This work comes to
us from M3AAWG where there's a critical mass that believes
reputation abuse of this nature is real.  Though I agree it would
be helpful to have metrics to describe it more precisely, it's my
perception that there's enough momentum here to back chartering.


So I take it they haven't quantified it either? This strikes me as
highly susceptible to using anecdotal evidence as proof. I'm not
saying they are wrong, I just would like to see actual evidence.
That's especially true if the end result is telling receivers they
should do something that they have no stake in.


I suspect that most of the organizations affected aren't positioned to 
share the internal metrics that showed impact, but I can tell you from 
experience the effects can be quite dramatic, and I've spoken to more 
than a few people - also with direct experience - who would say the same.


These attacks were very narrowly targeted; the vast majority of DKIM 
replay spam this year has been sent to just a few of the largest 
consumer mailbox providers. In that context, lack of awareness of the 
problem is a poor argument against trying to solve it.



If the solution to the problem results in taking away functionality 
available for 15 years as some are recommending, I'd say that the onus 
is on the people making the claims to actually back it up. From my 
perspective this is all just hearsay. I think the larger community is 
entitled to something more than that before doing anything.


I have good reason to be suspicious. That Google was one of the major 
proponents of ARC which was supposedly to deal with the mailing list 
problem but all boiled down to reputation that could already be done 
with plain old DKIM suggests that reputation remains an unsolved 
problem. Maybe it is just one side of the company not knowing what the 
other side knows, but I find that rather unlikely. So there is a 
contradiction somewhere here from where I sit.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Evan Burke]

On Mon, Dec 12, 2022 at 11:21 AM Michael Thomas  wrote:

> On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:
>
> On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:
>
>> But I want to return to my previous point of whether reputation is even
>> quantifiable, and whether somebody has actually gone out and researched it.
>> We can say that this is a problem in theory, but do we have any data to
>> back it up? I kinda think that should be table stakes before talking about
>> rechartering.
>>
>
> The industry appears to think it's a factor.  This work comes to us from
> M3AAWG where there's a critical mass that believes reputation abuse of this
> nature is real.  Though I agree it would be helpful to have metrics to
> describe it more precisely, it's my perception that there's enough momentum
> here to back chartering.
>
> So I take it they haven't quantified it either? This strikes me as highly
> susceptible to using anecdotal evidence as proof. I'm not saying they are
> wrong, I just would like to see actual evidence. That's especially true if
> the end result is telling receivers they should do something that they have
> no stake in.
>

I suspect that most of the organizations affected aren't positioned to
share the internal metrics that showed impact, but I can tell you from
experience the effects can be quite dramatic, and I've spoken to more than
a few people - also with direct experience - who would say the same.

These attacks were very narrowly targeted; the vast majority of DKIM replay
spam this year has been sent to just a few of the largest consumer mailbox
providers. In that context, lack of awareness of the problem is a poor
argument against trying to solve it.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/12/22 6:57 AM, Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:

But I want to return to my previous point of whether reputation is
even quantifiable, and whether somebody has actually gone out and
researched it. We can say that this is a problem in theory, but do
we have any data to back it up? I kinda think that should be table
stakes before talking about rechartering.


The industry appears to think it's a factor.  This work comes to us 
from M3AAWG where there's a critical mass that believes reputation 
abuse of this nature is real.  Though I agree it would be helpful to 
have metrics to describe it more precisely, it's my perception that 
there's enough momentum here to back chartering.



So I take it they haven't quantified it either? This strikes me as 
highly susceptible to using anecdotal evidence as proof. I'm not saying 
they are wrong, I just would like to see actual evidence. That's 
especially true if the end result is telling receivers they should do 
something that they have no stake in.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Al Iverson]

On Sun, Dec 11, 2022 at 4:46 PM Michael Deutschmann  wrote:
>
> On Sun, 11 Dec 2022, Murray S. Kucherawy wrote:
> > Then from that other account I can spray it to as many recipients as I
> > want so long as the only thing I change is the envelope.
>
> Since the ISP is doing the signing, you can't stop them from using a
> signature that protects the To: and Cc: from modification, and in practice
> everyone already does that.  That means the bonus messages you get to
> send via the hack will have mismatched 822 and 821 recipients, equivalent
> to a blind-carbon-copy.
>
> Blind-carbon-copy is already a sign of spam.

Except when it's not, like this very mailing list.

Cheers,
Al Iverson

-- 

Al Iverson / Deliverability blogging at www.spamresource.com
Subscribe to the weekly newsletter at wombatmail.com/sr.cgi
DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time)

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 2:43 PM Michael Thomas  wrote:

> But I want to return to my previous point of whether reputation is even
> quantifiable, and whether somebody has actually gone out and researched it.
> We can say that this is a problem in theory, but do we have any data to
> back it up? I kinda think that should be table stakes before talking about
> rechartering.
>

The industry appears to think it's a factor.  This work comes to us from
M3AAWG where there's a critical mass that believes reputation abuse of this
nature is real.  Though I agree it would be helpful to have metrics to
describe it more precisely, it's my perception that there's enough momentum
here to back chartering.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 12 Dec 2022, at 14:34, Murray S. Kucherawy  wrote:
> 
> On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely  > wrote:
> > The alternative is to say: Well, if you can't make at least one of those
> > two quantities bulletproof, then don't sign your mail.  That, though,
> > sounds a lot to me like tossing DKIM in the bin.
> 
> On the opposite, if Gmail restricted signing to accountable users only, its 
> signatures would gain value.  If they started doing so it would soon be 
> noticed, and signatures would acquire a meaning in delivery decisions.
>  
> Is the cost of imposing a program that vets every user comparable to that of 
> the damage caused by this attack vector?  My impression is that it is not.

I’m not aware of Gmail being a significant victim here - although it’s possible 
they are. 

> Endowing signatures with a significant value increases the overall value of 
> DKIM.
> 
> Presumably they already have significant value.  That's why this attack works 
> already.

They’re an identity of a known sender that invests time and resources into 
building and managing their reputation. Google? Maybe not. But the email 
service providers who do a lot to keep the spammers off their network are a 
common victim. These spammers know that they get better delivery if their mail 
is signed by the email service provider. The email service provider’s detectors 
and defenses are enough to stop the spammer from being able to send through the 
ESP. So the spammer sends one email to an account they own and takes a 
reputation they’ve already been told they shouldn’t be using. 

A DKIM signature is an identity. That identity has a reputation. Attacks that 
borrow the identity belonging to senders with good reputation benefit from that 
reputation. It’s not about any DKIM signature. It’s not about a random DKIM 
signature. It’s about a known entity. Even if Gmail only signed mail from 
accountable users, there is still the possibility of spammers posing as 
accountable users. 

The whole idea of a DKIM replay attack is that this is mail that cannot be 
directly sent through the infrastructure of the domain owner. That, itself, 
implies the domain owners are doing quite a bit to stop the spam from coming 
out of their network. If they weren’t doing a good job then replay attacks 
wouldn’t be happening - the mail would just be sent over that network directly. 

Asking for the domain owners to “stop sending spam” when the whole replay 
process indicates they are stopping spam out of the networks they control seems 
a bit of a non-starter to me. 

> The question is whether we should proclaim that the bar needs to be even 
> higher, maybe even an all-or-nothing proposition.  I'm suggesting that's not 
> a good idea.

Agreed. 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Mon, Dec 12, 2022 at 1:13 AM Alessandro Vesely  wrote:

> > The alternative is to say: Well, if you can't make at least one of those
> > two quantities bulletproof, then don't sign your mail.  That, though,
> > sounds a lot to me like tossing DKIM in the bin.
>
> On the opposite, if Gmail restricted signing to accountable users only,
> its
> signatures would gain value.  If they started doing so it would soon be
> noticed, and signatures would acquire a meaning in delivery decisions.
>

Is the cost of imposing a program that vets every user comparable to that
of the damage caused by this attack vector?  My impression is that it is
not.

Endowing signatures with a significant value increases the overall value of
> DKIM.
>

Presumably they already have significant value.  That's why this attack
works already.

The question is whether we should proclaim that the bar needs to be even
higher, maybe even an all-or-nothing proposition.  I'm suggesting that's
not a good idea.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 11 Dec 2022, at 21:41, Michael Thomas  wrote:
> 
> 
> 
> On 12/11/22 1:16 PM, Murray S. Kucherawy wrote:
>> On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas > > wrote:
>>  
>>> As for resolution: the first obvious one is to not send spam in the first 
>>> place. That is the root of the problem. The second is that Bcc's can be 
>>> treated with more suspicion. Neither of these needs the working group to do 
>>> anything.
>>> 
>>> 
>>> I think this is easier said than done.  In the example I gave, "don't send 
>>> spam in the first place" reduces to "make sure your users are 100% 
>>> trustworthy or that your outbound spam filters are 100% accurate", which 
>>> strikes me as an impossible bar to meet.
>> I'm going to assume that the attackers will need to iterate to find a piece 
>> of mail that passes their filters. That is signal right there that abuse is 
>> likely. Perhaps an exponential backoff could be employed when outbound spam 
>> is detected. Sort of like a 4xx "try later".
>> 
>> That's easy to evade: Come from a rotating pool of IP addresses, using a new 
>> free account each time.
> Sure. I guess the question is how much effort would spammers be willing to 
> expend before trying some other tactics?

Quite a bit, actually. I remember sitting in a 17th floor conference room on 
market street with a particular sending organization that explained to me their 
business model was to have a boiler room full of people iterating through 
content and trying to deliver it to their own mailbox at hotmail.com 
. When they found text that got through, they sent that 
until the filters caught up, then moved onto the next piece of content. They 
started this at 5pm pacific time and would spam all night. They did this every 
day.  That was 2007 or so (said company was sued into oblivion by the FTC not 
long after that conference room meeting). 

The amount of energy spammers expend to bypass filters is significant. That 
includes bypassing port25 blocks. For instance, I’m aware of a company using 
BGP routing tricks to host their outbound spam cannons on major cloud providers 
(that block port25 by default). The IPs are treated as throwaway and they burn 
and turn them when they get too blocked. 

> Can we even quantize what the value of, say, a signed gmail piece of email 
> is?  I think that's a basic question that needs to be answered before we 
> declare this a problem. I for one am all ears as "DKIM gives you better 
> deliverability" has always been a sort of squishy statement. 

This is one of those questions that is, IMO, unanswerable for a lot of reasons. 
The biggest of which is: the value to whom? 

>> 
>> But the BCC aspect is interesting too. Don't providers already view things 
>> with massive rcpt-to (bcc's) suspiciously? hat's easy to evade: Send a spam 
>> message to yourself only.  That has the signature.  Now capture that from 
>> your inbox and replay it from a different server to any number of 
>> recipients, using any number of envelopes, to your heart's content.  Won't 
>> pass SPF, but it passes DKIM.  If the receiver values DKIM more, or only 
>> cares if one passes, you win
>> 
> No, I mean that the if number of RCPT-TO's is large, it's suspicious. Even if 
> they do individual SMTP transactions it will have the same (signed) 
> Message-Id so that's not evadeable either in theory. 
> 
Interesting thought. 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Laura Atkins]

> On 11 Dec 2022, at 20:52, Murray S. Kucherawy  wrote:
> 
> On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas  > wrote:
> Re: stripping signatures, all the attacker needs to do is either send it to a 
> service that doesn't strip signatures or use their own MTA. Trivially 
> avoidable, and a Maginot Line of epic narrowness. 
> 
> Right, I think this is an aspect of that proposal that warrants further 
> debate.  I think the argument is compelling, but it's clearly not bulletproof.
>  
> As for resolution: the first obvious one is to not send spam in the first 
> place. That is the root of the problem. The second is that Bcc's can be 
> treated with more suspicion. Neither of these needs the working group to do 
> anything.
> 
> I think this is easier said than done.  In the example I gave, "don't send 
> spam in the first place" reduces to "make sure your users are 100% 
> trustworthy or that your outbound spam filters are 100% accurate", which 
> strikes me as an impossible bar to meet.

Also, in the case of replay attacks, we’re redefining spam to a point of 
uselessness. Spam is mail that users didn’t ask to receive. But the initial 
message that’s being signed is an opt-in message. The sender knows the 
recipient address wants the message. We’ve spent 25 years trying to block spam, 
I’m not sure that this is even a solveable problem. Even if you made COI the 
default and could only send mail with an actual confirmation message in hand, 
that’s a trivially jumpable hoop for the spammer to negotiate. 

> The alternative is to say: Well, if you can't make at least one of those two 
> quantities bulletproof, then don't sign your mail.  That, though, sounds a 
> lot to me like tossing DKIM in the bin

Agreed. 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Alessandro Vesely]

On Sun 11/Dec/2022 21:52:46 +0100 Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas  wrote:


As for resolution: the first obvious one is to not send spam in the first
place. That is the root of the problem. The second is that Bcc's can be
treated with more suspicion. Neither of these needs the working group to do
anything.


I think this is easier said than done.  In the example I gave, "don't send
spam in the first place" reduces to "make sure your users are 100%
trustworthy or that your outbound spam filters are 100% accurate", which
strikes me as an impossible bar to meet.

The alternative is to say: Well, if you can't make at least one of those
two quantities bulletproof, then don't sign your mail.  That, though,
sounds a lot to me like tossing DKIM in the bin.



On the opposite, if Gmail restricted signing to accountable users only, its 
signatures would gain value.  If they started doing so it would soon be 
noticed, and signatures would acquire a meaning in delivery decisions.


Endowing signatures with a significant value increases the overall value of 
DKIM.



Best
Ale
--






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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

(Apologies for top-posting while mobile)

There's ample legitimate use of Bcc or equivalent such that I have trouble
believing the rules you're talking about here can be taken as universally
valid.

Mailing lists or even multi-recipient aliases are additional examples.

And since DKIM is (currently, at least) decoupled from the envelope, I
think we're also taking across layers here.

-MSK

On Sun, Dec 11, 2022, 14:46 Michael Deutschmann  wrote:

> On Sun, 11 Dec 2022, Murray S. Kucherawy wrote:
> > Then from that other account I can spray it to as many recipients as I
> > want so long as the only thing I change is the envelope.
>
> Since the ISP is doing the signing, you can't stop them from using a
> signature that protects the To: and Cc: from modification, and in practice
> everyone already does that.  That means the bonus messages you get to
> send via the hack will have mismatched 822 and 821 recipients, equivalent
> to a blind-carbon-copy.
>
> Blind-carbon-copy is already a sign of spam.  Long ago, it was because the
> bad guys were using open relays, and could spam faster by issuing many
> RCPT TO:s to the relay in one transaction.  (I remember being puzzled
> back then that most of my spam came "To: fri...@public.com" rather than
> my address at the time.).
>
> In modern times, you still see it from "Nigerian" scammers who seem to be
> using real webmail sites and copy-pasting huge address lists into a
> literal Bcc: field.
>
>  Michael Deutschmann 
>
> ___
> 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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/11/22 2:46 PM, Michael Deutschmann wrote:


Blind-carbon-copy is already a sign of spam.  Long ago, it was because the
bad guys were using open relays, and could spam faster by issuing many
RCPT TO:s to the relay in one transaction.  (I remember being puzzled
back then that most of my spam came "To: fri...@public.com" rather than
my address at the time.).

In modern times, you still see it from "Nigerian" scammers who seem to be
using real webmail sites and copy-pasting huge address lists into a
literal Bcc: field.


You'd think that the webmail sites wouldn't like that very much because 
it strains their resources. But of course there is nothing stopping 
people from running their own MTA.


Mike

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Deutschmann]

On Sun, 11 Dec 2022, Murray S. Kucherawy wrote:
> Then from that other account I can spray it to as many recipients as I
> want so long as the only thing I change is the envelope.

Since the ISP is doing the signing, you can't stop them from using a
signature that protects the To: and Cc: from modification, and in practice
everyone already does that.  That means the bonus messages you get to
send via the hack will have mismatched 822 and 821 recipients, equivalent
to a blind-carbon-copy.

Blind-carbon-copy is already a sign of spam.  Long ago, it was because the
bad guys were using open relays, and could spam faster by issuing many
RCPT TO:s to the relay in one transaction.  (I remember being puzzled
back then that most of my spam came "To: fri...@public.com" rather than
my address at the time.).

In modern times, you still see it from "Nigerian" scammers who seem to be
using real webmail sites and copy-pasting huge address lists into a
literal Bcc: field.

 Michael Deutschmann 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/11/22 1:55 PM, Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 1:41 PM Michael Thomas  wrote:




No, I mean that the if number of RCPT-TO's is large, it's
suspicious. Even if they do individual SMTP transactions it will
have the same (signed) Message-Id so that's not evadeable either
in theory.

In the transaction where the signature is applied, there's only one 
envelope recipient.  When I'm executing the attack, I could do one 
envelope per recipient if I'm worried about being detected that way.


If Message-ID isn't covered by the header hash, it can be unique per 
envelope.

The spammer doesn't control what the signer signs, of course.


There was a suggestion that the "bh=" could be required to be unique 
per MX to avoid replays, but that becomes a potentially gigantic hash 
table, so now there's a resource problem imposed on the 
receiver/verifier.  Even if you key it on Message-ID, you have the 
same resource problem.


I dunno, how common is Bcc'ing in real life? I imagine the percentage of 
users knowing about it is pretty low. So it would likely be from other 
things like marketing campaigns which are certainly common, but also 
often is not distinguishable from spam. I don't have any insight into 
what good spam filters do, but large RCPT-TO lists seem like they are a 
good reason to cast doubt a priori. Given that legit messaging often 
ends up in my spam box, it seems plausible they are using it as a signal.


But I want to return to my previous point of whether reputation is even 
quantifiable, and whether somebody has actually gone out and researched 
it. We can say that this is a problem in theory, but do we have any data 
to back it up? I kinda think that should be table stakes before talking 
about rechartering.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:55 PM Murray S. Kucherawy 
wrote:

> In the transaction where the signature is applied, there's only one
> envelope recipient.  When I'm executing the attack, I could do one envelope
> per recipient if I'm worried about being detected that way.
>
> If Message-ID isn't covered by the header hash, it can be unique per
> envelope.
>
> There was a suggestion that the "bh=" could be required to be unique per
> MX to avoid replays, but that becomes a potentially gigantic hash table, so
> now there's a resource problem imposed on the receiver/verifier.  Even if
> you key it on Message-ID, you have the same resource problem.
>

Also, a deduplication defense is only effective if the replay campaign
touches the same MX more than once.  There's still a benefit if I avoid
that; there are zillions of distinct MXes out there, and federation is
probably not common enough to make a dent.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:41 PM Michael Thomas  wrote:

>
> But the BCC aspect is interesting too. Don't providers already view things
>> with massive rcpt-to (bcc's) suspiciously?
>>
> That's easy to evade: Send a spam message to yourself only.  That has the
> signature.  Now capture that from your inbox and replay it from a different
> server to any number of recipients, using any number of envelopes, to your
> heart's content.  Won't pass SPF, but it passes DKIM.  If the receiver
> values DKIM more, or only cares if one passes, you win.
>
> No, I mean that the if number of RCPT-TO's is large, it's suspicious. Even
> if they do individual SMTP transactions it will have the same (signed)
> Message-Id so that's not evadeable either in theory.
>
In the transaction where the signature is applied, there's only one
envelope recipient.  When I'm executing the attack, I could do one envelope
per recipient if I'm worried about being detected that way.

If Message-ID isn't covered by the header hash, it can be unique per
envelope.

There was a suggestion that the "bh=" could be required to be unique per MX
to avoid replays, but that becomes a potentially gigantic hash table, so
now there's a resource problem imposed on the receiver/verifier.  Even if
you key it on Message-ID, you have the same resource problem.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/11/22 1:16 PM, Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas  wrote:



As for resolution: the first obvious one is to not send spam
in the first place. That is the root of the problem. The
second is that Bcc's can be treated with more suspicion.
Neither of these needs the working group to do anything.


I think this is easier said than done.  In the example I gave,
"don't send spam in the first place" reduces to "make sure your
users are 100% trustworthy or that your outbound spam filters are
100% accurate", which strikes me as an impossible bar to meet.


I'm going to assume that the attackers will need to iterate to
find a piece of mail that passes their filters. That is signal
right there that abuse is likely. Perhaps an exponential backoff
could be employed when outbound spam is detected. Sort of like a
4xx "try later".

That's easy to evade: Come from a rotating pool of IP addresses, using 
a new free account each time.
Sure. I guess the question is how much effort would spammers be willing 
to expend before trying some other tactics? Can we even quantize what 
the value of, say, a signed gmail piece of email is? I think that's a 
basic question that needs to be answered before we declare this a 
problem. I for one am all ears as "DKIM gives you better deliverability" 
has always been a sort of squishy statement.


But the BCC aspect is interesting too. Don't providers already
view things with massive rcpt-to (bcc's) suspiciously?

That's easy to evade: Send a spam message to yourself only.  That has 
the signature.  Now capture that from your inbox and replay it from a 
different server to any number of recipients, using any number of 
envelopes, to your heart's content.  Won't pass SPF, but it passes 
DKIM.  If the receiver values DKIM more, or only cares if one passes, 
you win.


No, I mean that the if number of RCPT-TO's is large, it's suspicious. 
Even if they do individual SMTP transactions it will have the same 
(signed) Message-Id so that's not evadeable either in theory.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 1:11 PM Michael Thomas  wrote:

>
>
> As for resolution: the first obvious one is to not send spam in the first
>> place. That is the root of the problem. The second is that Bcc's can be
>> treated with more suspicion. Neither of these needs the working group to do
>> anything.
>>
>
> I think this is easier said than done.  In the example I gave, "don't send
> spam in the first place" reduces to "make sure your users are 100%
> trustworthy or that your outbound spam filters are 100% accurate", which
> strikes me as an impossible bar to meet.
>
> I'm going to assume that the attackers will need to iterate to find a
> piece of mail that passes their filters. That is signal right there that
> abuse is likely. Perhaps an exponential backoff could be employed when
> outbound spam is detected. Sort of like a 4xx "try later".
>
That's easy to evade: Come from a rotating pool of IP addresses, using a
new free account each time.

> But the BCC aspect is interesting too. Don't providers already view things
> with massive rcpt-to (bcc's) suspiciously?
>
That's easy to evade: Send a spam message to yourself only.  That has the
signature.  Now capture that from your inbox and replay it from a different
server to any number of recipients, using any number of envelopes, to your
heart's content.  Won't pass SPF, but it passes DKIM.  If the receiver
values DKIM more, or only cares if one passes, you win.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/11/22 12:52 PM, Murray S. Kucherawy wrote:

On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas  wrote:

Re: stripping signatures, all the attacker needs to do is either
send it to a service that doesn't strip signatures or use their
own MTA. Trivially avoidable, and a Maginot Line of epic narrowness.


Right, I think this is an aspect of that proposal that warrants 
further debate.  I think the argument is compelling, but it's clearly 
not bulletproof.


If all it requires is setting up a free tier VM camping on port 25, it 
is no solution at all.




As for resolution: the first obvious one is to not send spam in
the first place. That is the root of the problem. The second is
that Bcc's can be treated with more suspicion. Neither of these
needs the working group to do anything.


I think this is easier said than done.  In the example I gave, "don't 
send spam in the first place" reduces to "make sure your users are 
100% trustworthy or that your outbound spam filters are 100% 
accurate", which strikes me as an impossible bar to meet.


I'm going to assume that the attackers will need to iterate to find a 
piece of mail that passes their filters. That is signal right there that 
abuse is likely. Perhaps an exponential backoff could be employed when 
outbound spam is detected. Sort of like a 4xx "try later".


But the BCC aspect is interesting too. Don't providers already view 
things with massive rcpt-to (bcc's) suspiciously?


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sun, Dec 11, 2022 at 12:34 PM Michael Thomas  wrote:

> Re: stripping signatures, all the attacker needs to do is either send it
> to a service that doesn't strip signatures or use their own MTA. Trivially
> avoidable, and a Maginot Line of epic narrowness.
>

Right, I think this is an aspect of that proposal that warrants further
debate.  I think the argument is compelling, but it's clearly not
bulletproof.


> As for resolution: the first obvious one is to not send spam in the first
> place. That is the root of the problem. The second is that Bcc's can be
> treated with more suspicion. Neither of these needs the working group to do
> anything.
>

I think this is easier said than done.  In the example I gave, "don't send
spam in the first place" reduces to "make sure your users are 100%
trustworthy or that your outbound spam filters are 100% accurate", which
strikes me as an impossible bar to meet.

The alternative is to say: Well, if you can't make at least one of those
two quantities bulletproof, then don't sign your mail.  That, though,
sounds a lot to me like tossing DKIM in the bin.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Thomas]

On 12/11/22 12:20 PM, Murray S. Kucherawy wrote:


Pop culture references aside, I don't follow this.  If I send a piece 
of spam from this account to another, it will be signed by Gmail 
(assuming their filters pass it).  Then from that other account I can 
spray it to as many recipients as I want so long as the only thing I 
change is the envelope.  The signature remains intact, and its 
delivery to those domains checking such things will be predicated on 
the validity of that signature.  I haven't "lost" my email address; I 
can repeat this attack as many times as I want. And I (via Gmail) have 
a globally good reputation.  This is the concern that I understand is 
being discussed.
Re: stripping signatures, all the attacker needs to do is either send it 
to a service that doesn't strip signatures or use their own MTA. 
Trivially avoidable, and a Maginot Line of epic narrowness.


As for resolution: the first obvious one is to not send spam in the 
first place. That is the root of the problem. The second is that Bcc's 
can be treated with more suspicion. Neither of these needs the working 
group to do anything.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Murray S. Kucherawy]

On Sat, Dec 10, 2022 at 7:42 PM Michael Deutschmann 
wrote:

> It's a bit annoying that after almost two weeks, the only responses in
> this thread have been about this side issue, with my main point
> unaddressed.
>

As I read your original post, it was about DKIM+DMARC being an anti-forgery
tool, not an anti-spam tool.  While that may be true, what's being
discussed is the replay attack involving DKIM irrespective of DMARC.

DKIM's not an anti-forgery tool by itself.  The domain in the "d" tag
doesn't have to be the same as the domain in the From field for a signature
to be valid.  The problem being brought to this community is that replay --
which in 2011 we didn't think would be a big deal -- has apparently become
a problem.  The focus is dealing with this in DKIM, if possible,
irrespective of how it might impact DMARC.

Since the focus of your original post seemed to be at a level above where
DKIM does its work, I thought it was unrelated to the problem being
discussed.


> If your configuration is not Baka, then you have nothing to fear from the
> replay attack.   The replay attack only allows an attacker to pretend to
> *continue* to own an e-mail address they just lost; it never lets them
> impersonate someone who already has a good reputation.
>

Pop culture references aside, I don't follow this.  If I send a piece of
spam from this account to another, it will be signed by Gmail (assuming
their filters pass it).  Then from that other account I can spray it to as
many recipients as I want so long as the only thing I change is the
envelope.  The signature remains intact, and its delivery to those domains
checking such things will be predicated on the validity of that signature.
I haven't "lost" my email address; I can repeat this attack as many times
as I want.  And I (via Gmail) have a globally good reputation.  This is the
concern that I understand is being discussed.

If you are Baka but apply a downscore for blind-carbon-copy of
> equal-or-greater magnitude than your Baka upscore, you are also immune to
> the replay attack.  But you will still be wide open to other spammers.
>

First, if this is the advice verifiers/receivers should be applying, then
it would be a good idea to write it down someplace so it can be found.  I
don't know that this has been done yet.  Has it?

Second, how would one establish "magnitude" given that the final recipient
has no idea what the original envelope looked like?

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Michael Deutschmann]

On Wed, 7 Dec 2022, Neil Anuskiewicz wrote:
> I wish that certain widely used distribution list software could do the
> same.

So you admit that most mailing lists are not compatible with an enforcing
DMARC, so my original point stands.


It's a bit annoying that after almost two weeks, the only responses in
this thread have been about this side issue, with my main point
unaddressed.

I'm going to try to fight the real problem with a coinage, "Baka-DKIM"
(and its cousin "Baka-SPF").   (In case of any Pop Cultural Osmosis
Failure here, "Baka" means fool in Japanese.)

Baka-DKIM is the error of upscoring messages for being DKIM signed
without caring about *what* the email address being attested actually was.
(The avoided "downscore" when DMARC says to enforce signing doesn't count.
Still, when the mail is from a stranger, that case must not be in total
upscored relative to the no-DKIM and no-DMARC case, everything else
equal.)

If your configuration is not Baka, then you have nothing to fear from the
replay attack.   The replay attack only allows an attacker to pretend to
*continue* to own an e-mail address they just lost; it never lets them
impersonate someone who already has a good reputation.

If you are Baka but apply a downscore for blind-carbon-copy of
equal-or-greater magnitude than your Baka upscore, you are also immune to
the replay attack.  But you will still be wide open to other spammers.

 Michael Deutschmann 

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Neil Anuskiewicz]

> On Nov 29, 2022, at 8:25 PM, Jim Fenton  wrote:
> 
> 
> On 29 Nov 2022, at 18:54, Neil Anuskiewicz wrote:
> 
> Unless I’m misunderstanding you’re saying those with an enforcing DMARC 
> policy can’t successfully send to mailing lists. I’m doing it now so I don’t 
> think DMARC has to stay inert if mailing lists. That’s a bit of a 
> generalization.
> 
> _dmarc.marmot-tech.com.   300 IN  TXT "v=DMARC1; p=none; 
> rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com; fo=1"
> No, you don’t have an enforcing DMARC policy. But if you did, you would still 
> be able to successfully send to this mailing list, because IETF mailing lists 
> rewrite the From addresses of messages from enforcing domains.
> 
My domains are all just toys so I’m always playing around but now changed 
marmot-tech.com’s policy back to reject. It bit embarrassing that I said it was 
at reject when it was at none, though. Anyway, yes mailman can handle DMARC as 
well as could be expected. I wish that certain widely used distribution list 
software could do the same. It’s not clear why that wouldn’t be addressed well 
for any DL software. It’s a pain.

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

Of course, ARC replay will also need to be addressed. But that’s a job 
for the DMARC working group.


-Jim

On 30 Nov 2022, at 8:31, Barry Leiba wrote:

No one wants it to be the permanent solution, and ARC is one 
alternative
proposal.  But “From munging”, while ugly and not without 
down-sides, is

something that can be done unilaterally and works.  ARC and related
mechanisms require widespread adoption in order to be effective.

Barry

On Wed, Nov 30, 2022 at 9:03 AM Mark Alley  wrote:


That's a question I've always had on this topic.

Is 5322.FROM an acceptable long-term workaround for DMARC enforced
domains? The community in general seems to be split on 5322.FROM 
munging

and it's use in practice.

On 11/30/2022 12:41 AM, Barry Leiba wrote:

Unless I’m misunderstanding you’re saying those with an
enforcing DMARC policy can’t successfully send to mailing lists.
I’m doing it now so I don’t think DMARC has to stay inert if
mailing lists. That’s a bit of a generalization.

_dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1; p=none;
rua=mailto:dm...@marmot-tech.com; 
ruf=mailto:f...@marmot-tech.com;

fo=1"

No, you don’t have an enforcing DMARC policy. But if you did,
you would still be able to successfully send to this mailing
list, because IETF mailing lists rewrite the From addresses of
messages from enforcing domains.

And for mailing list that don't re-write the From address, the issue
isn't that the sender can't post.  It's that subscribers whose 
domains

enforce a "p=reject" policy will not get the posts, and will
eventually become unsubscribed because of the bounce messages their
domains generate.  Neil wouldn't see the harm: others would.  It's
insidious.

Barry

___
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




___
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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Barry Leiba]

No one wants it to be the permanent solution, and ARC is one alternative
proposal.  But “From munging”, while ugly and not without down-sides, is
something that can be done unilaterally and works.  ARC and related
mechanisms require widespread adoption in order to be effective.

Barry

On Wed, Nov 30, 2022 at 9:03 AM Mark Alley  wrote:

> That's a question I've always had on this topic.
>
> Is 5322.FROM an acceptable long-term workaround for DMARC enforced
> domains? The community in general seems to be split on 5322.FROM munging
> and it's use in practice.
>
> On 11/30/2022 12:41 AM, Barry Leiba wrote:
> >>> Unless I’m misunderstanding you’re saying those with an
> >>> enforcing DMARC policy can’t successfully send to mailing lists.
> >>> I’m doing it now so I don’t think DMARC has to stay inert if
> >>> mailing lists. That’s a bit of a generalization.
> >> _dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1; p=none;
> >> rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com;
> >> fo=1"
> >>
> >> No, you don’t have an enforcing DMARC policy. But if you did,
> >> you would still be able to successfully send to this mailing
> >> list, because IETF mailing lists rewrite the From addresses of
> >> messages from enforcing domains.
> > And for mailing list that don't re-write the From address, the issue
> > isn't that the sender can't post.  It's that subscribers whose domains
> > enforce a "p=reject" policy will not get the posts, and will
> > eventually become unsubscribed because of the bounce messages their
> > domains generate.  Neil wouldn't see the harm: others would.  It's
> > insidious.
> >
> > Barry
> >
> > ___
> > 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
>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Mark Alley]

That's a question I've always had on this topic.

Is 5322.FROM an acceptable long-term workaround for DMARC enforced 
domains? The community in general seems to be split on 5322.FROM munging 
and it's use in practice.


On 11/30/2022 12:41 AM, Barry Leiba wrote:

Unless I’m misunderstanding you’re saying those with an
enforcing DMARC policy can’t successfully send to mailing lists.
I’m doing it now so I don’t think DMARC has to stay inert if
mailing lists. That’s a bit of a generalization.

_dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1; p=none;
rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com;
fo=1"

No, you don’t have an enforcing DMARC policy. But if you did,
you would still be able to successfully send to this mailing
list, because IETF mailing lists rewrite the From addresses of
messages from enforcing domains.

And for mailing list that don't re-write the From address, the issue
isn't that the sender can't post.  It's that subscribers whose domains
enforce a "p=reject" policy will not get the posts, and will
eventually become unsubscribed because of the bounce messages their
domains generate.  Neil wouldn't see the harm: others would.  It's
insidious.

Barry

___
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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Barry Leiba]

>> Unless I’m misunderstanding you’re saying those with an
>> enforcing DMARC policy can’t successfully send to mailing lists.
>> I’m doing it now so I don’t think DMARC has to stay inert if
>> mailing lists. That’s a bit of a generalization.
>
>_dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1; p=none;
>rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com;
>fo=1"
>
> No, you don’t have an enforcing DMARC policy. But if you did,
> you would still be able to successfully send to this mailing
> list, because IETF mailing lists rewrite the From addresses of
> messages from enforcing domains.

And for mailing list that don't re-write the From address, the issue
isn't that the sender can't post.  It's that subscribers whose domains
enforce a "p=reject" policy will not get the posts, and will
eventually become unsubscribed because of the bounce messages their
domains generate.  Neil wouldn't see the harm: others would.  It's
insidious.

Barry

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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Jim Fenton]

On 29 Nov 2022, at 18:54, Neil Anuskiewicz wrote:

Unless I’m misunderstanding you’re saying those with an enforcing 
DMARC policy can’t successfully send to mailing lists. I’m doing 
it now so I don’t think DMARC has to stay inert if mailing lists. 
That’s a bit of a generalization.


```
_dmarc.marmot-tech.com.	300	IN	TXT	"v=DMARC1; p=none; 
rua=mailto:dm...@marmot-tech.com; ruf=mailto:f...@marmot-tech.com; fo=1"

```

No, you don’t have an enforcing DMARC policy. But if you did, you 
would still be able to successfully send to this mailing list, because 
IETF mailing lists rewrite the From addresses of messages from enforcing 
domains.


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

Re: [Ietf-dkim] Misuse of antiforgery protocols

[Neil Anuskiewicz]

> On Nov 27, 2022, at 8:19 PM, Michael Deutschmann  wrote:
> 
> (I've noticed the "rechartering" thread, but I don't think it should
> squelch this since I am speaking meta to the replay exploit, not
> suggesting technical measures.)
> 
> More than a hundred e-mails have streamed through my in-box lately, all
> about a silly exploit in DKIM.  While it is real, I immediately notice
> that it can't really do any damage if the recipient is using DKIM
> *properly*.
> 
> It's important to remember that DKIM/DMARC is an anti-forgery protocol,
> not an anti-spam protocol.
> 
> There are *two* ways an anti-forgery technique can provide useful input
> to an anti-spam system:
> 
> First, if the anti-forgery technique can assert that a message *is*
> forged, and not just failing the test because the alleged sender isn't
> participating, then it is reasonable to ignore any heuristics indicating
> the message is not spam, and fail it.
> 
> Second, if the anti-forgery technique asserts the message is genuine, and
> *YOU* *KNOW* *THE* *RECIPIENT* *TRUSTS* *THAT* *SPECIFIC* *SENDER*, then
> it is reasonable to ignore any heuristics indicating the message is spam,
> and pass it.
> 
> Going further is folly. Without trust in the identity claimed, all
> anti-forgery-system blessings just become Habeas Haikus (anyone remember
> that?).
> 
> Last I looked, DMARC makes no allowance for the mailing list problem;
> either you know none of your users posts to any mailing list or your DMARC
> policy has to be inert.
> 
> Practically, only an address from a public e-mail provider can be "forged"
> by the hack.  And those providers cannot assume they have no users who use
> mailing lists, so (if sane) their DMARC will always be inert.  

Unless I’m misunderstanding you’re saying those with an enforcing DMARC policy 
can’t successfully send to mailing lists. I’m doing it now so I don’t think 
DMARC has to stay inert if mailing lists. That’s a bit of a generalization.

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

[Ietf-dkim] Misuse of antiforgery protocols

[Michael Deutschmann]

(I've noticed the "rechartering" thread, but I don't think it should
squelch this since I am speaking meta to the replay exploit, not
suggesting technical measures.)

More than a hundred e-mails have streamed through my in-box lately, all
about a silly exploit in DKIM.  While it is real, I immediately notice
that it can't really do any damage if the recipient is using DKIM
*properly*.

It's important to remember that DKIM/DMARC is an anti-forgery protocol,
not an anti-spam protocol.

There are *two* ways an anti-forgery technique can provide useful input
to an anti-spam system:

First, if the anti-forgery technique can assert that a message *is*
forged, and not just failing the test because the alleged sender isn't
participating, then it is reasonable to ignore any heuristics indicating
the message is not spam, and fail it.

Second, if the anti-forgery technique asserts the message is genuine, and
*YOU* *KNOW* *THE* *RECIPIENT* *TRUSTS* *THAT* *SPECIFIC* *SENDER*, then
it is reasonable to ignore any heuristics indicating the message is spam,
and pass it.

Going further is folly. Without trust in the identity claimed, all
anti-forgery-system blessings just become Habeas Haikus (anyone remember
that?).

Last I looked, DMARC makes no allowance for the mailing list problem;
either you know none of your users posts to any mailing list or your DMARC
policy has to be inert.

Practically, only an address from a public e-mail provider can be "forged"
by the hack.  And those providers cannot assume they have no users who use
mailing lists, so (if sane) their DMARC will always be inert.  Even if
someone attemped the exploit but accidentally still broke the signature,
the hard-failure case would never apply.

The spammer has to at least momentarily control the address he uses as
From: -- he cannot forge someone his victim trusts (Unless the e-mail
provider is lazy and doesn't check for internal address forgery before
signing, which would be their fault alone).  So the hard-success case will
also never apply on exploit mail.

It's only fools who can't accept the truth that DKIM can only give
anti-spam input for a miniscule proportion of incoming mail, and thus
upscore all signed mail, who have to fear this hack.  And if this hack was
miraculously blocked, they'd still be wide open to more straightforward
spammers.  Ones who pay for their own domain and happily participate in
every antiforgery scheme.

 Michael Deutschmann 

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