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

[Wei Chuang]

Hi all,
I've posted an updated version of the draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
more clear.  It builds a case that spammers are exploiting DKIM through
replay, identifies conflicting scenarios, and outlines a solution space.

-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.


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] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.




Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim 
about it is wrong (DKIM can already sign a previous auth-res), and 3) 
this is the DKIM wg and it holds no power to make changes in it anyway.


When we finally get some chairs, we should make it explicitly out of scope.

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

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

[Wei Chuang]

On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
>
> Again, drop the reference to ARC. it is: 1) Experimental, 2) the claim
> about it is wrong (DKIM can already sign a previous auth-res), and 3) this
> is the DKIM wg and it holds no power to make changes in it anyway.
>
I disagree.  ARC is a tool to help support modern Indirect Mail Flows, and
I believe belongs in the solution space to be explored.  The large section
in that draft is explicitly to make the point that we need to support those
Indirect Mail Flows when we come up with a solution for DKIM Replay.
Please come up with a workable proposal preferably in I-D form to support
Indirect Mail Flows and prevent DKIM replay.

-Wei

> When we finally get some chairs, we should make it explicitly out of scope.
>
> Mike
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

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

[Michael Thomas]

On 2/10/23 11:35 AM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 11:09 AM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.



Again, drop the reference to ARC. it is: 1) Experimental, 2) the
claim about it is wrong (DKIM can already sign a previous
auth-res), and 3) this is the DKIM wg and it holds no power to
make changes in it anyway.

I disagree.  ARC is a tool to help support modern Indirect Mail 
Flows, and I believe belongs in the solution space to be explored.  
The large section in that draft is explicitly to make the point that 
we need to support those Indirect Mail Flows when we come up with a 
solution for DKIM Replay.  Please come up with a workable proposal 
preferably in I-D form to support Indirect Mail Flows and prevent DKIM 
replay.


I will do no such thing. I've already made it plain here and elsewhere 
that I don't think there is a solution to the mailing list problem, and 
trust me there is probably nobody else who has tried more. That's why I 
wrote this:


https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html

And regardless of whether I'm wrong and there is a ultimate solution, 
ARC most certainly is not that solution. It's not doing anything that 
DKIM can't already do and the "seal" mechanism is extremely suspect as 
to what it's actually providing. Thank goodness it was just an experiment.


But as I said, this is the DKIM working group. If DMARC wants to update 
ARC after this iteration of this wg concludes, they are more than 
entitled take that work up.


Mike, would that I had known about ARC before it hit the streets.

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

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

[Dave Crocker]

On 2/10/2023 11:35 AM, Wei Chuang wrote:
ARC is a tool to help support modern Indirect Mail Flows, and I 
believe belongs in the solution space to be explored. 


Since ARC uses the same technology as DKIM and uses it in pretty much 
the same was, my understanding is that it, too, has the potential for 
replay.  Having a reference to this fact makes sense to me.


It doesn't need more than a mention, at this point, I believe, which 
makes the current quick, reference exactly the right text, IMO.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

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

[Evan Burke]

On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:

> On 2/10/2023 11:35 AM, Wei Chuang wrote:
> > ARC is a tool to help support modern Indirect Mail Flows, and I
> > believe belongs in the solution space to be explored.
>
> Since ARC uses the same technology as DKIM and uses it in pretty much
> the same was, my understanding is that it, too, has the potential for
> replay.  Having a reference to this fact makes sense to me.
>
> It doesn't need more than a mention, at this point, I believe, which
> makes the current quick, reference exactly the right text, IMO.
>

+1

I realize there are some mixed opinions on ARC, but it's actively used on
several of the world's largest email systems - some of the same ones where
DKIM replay attacks are focused - so it's worth consideration as part of
the solution space. It may not end up being a viable option, but now isn't
the time to write it off.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Dave Crocker]

On 2/10/2023 12:05 PM, Evan Burke wrote:
I realize there are some mixed opinions on ARC, but it's actively used 
on several of the world's largest email systems -


The problem document is not an exercise in politics but an exploration 
of technical and operational issues.


Whether one or another technology is wonderful or the devil's work 
should be entirely out of scope, IMO.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.




| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me how they 
would manage to do that. The header fields signed are under control of 
the signer, not the original author. How do the attackers coax the 
provider's signer into not signing certain fields?


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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| In addition to being DKIM authenticated via the spoofed DKIM signature

I'm pretty sure that spoofed is wrong here? It's the originating 
domain's signature signed by their signers, still right? That's not 
spoofing.


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

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

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
> -Wei
>
> PS Many, many thanks goes to Dave Crocker for his editorial advice.
>
> ___
> Ietf-dkim mailing 
> listIetf-dkim@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-dkim
>
>
> | In addition to being DKIM authenticated via the spoofed DKIM signature
>
>
> I'm pretty sure that spoofed is wrong here? It's the originating domain's
> signature signed by their signers, still right? That's not spoofing.
>
To be honest I was wondering about that word choice myself.  I can change
that in the next rev.

-Wei


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


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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| When large amounts of spam are received by the mailbox provider, the
| operator’s filtering engine will eventually react by dropping the
| reputation of the original DKIM signer.

I think this needs some amount of justification. It's really easy to 
hand wave this and it's certainly a common assumption, but it's not a 
given. What exactly does "dropping the reputation" actually mean in 
practice? Does it mean for certain senders, certain classes of senders, 
the whole sending domain? How are such drops weighted? What are 
plausible metrics the receiver might use? One mailbox sending a lot of 
spam but otherwise the sending domain seems to be behaving well, seems 
pretty relevant to the topic.


This is especially true if a BCP gets written here. The problem 
statement should be as specific as it can be about why it's hard for 
receivers to overcome this problem. If there's a lot of proprietary 
stuff that can't be talked about, then it's pretty impossible to put 
together a BCP since we collectively have no idea what those practices are.


I think this really goes to the heart of what's going on here.

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

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

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
>
> | taking advantage of the flexibility in DKIM to
> | selectively sign headers, the spammer may intentionally leave out
> | certain headers such as To:, and Subject: that can be added in later
> | without damaging the existing DKIM signature.
>
>
> I think this needs to be explained. It isn't obvious to me how they would
> manage to do that. The header fields signed are under control of the
> signer, not the original author. How do the attackers coax the provider's
> signer into not signing certain fields?
>
By leaving them out.  Many DKIM signers, having observed this
vulnerability, have started oversigning headers to prevent that.

 -Wei

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


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

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

[Michael Thomas]

On 2/10/23 1:47 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:33 PM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.

-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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



| In addition to being DKIM authenticated via the spoofed DKIM signature

I'm pretty sure that spoofed is wrong here? It's the originating
domain's signature signed by their signers, still right? That's
not spoofing.

To be honest I was wondering about that word choice myself.  I can 
change that in the next rev.



Ok, thanks. It had me really confused.

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

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

[Michael Thomas]

On 2/10/23 1:48 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:29 PM Michael Thomas  wrote:


On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the
draft-chuang-dkim-replay-problem-01

draft.  It cleans up a lot from the -00 rough draft state so
hopefully it's more clear.  It builds a case that spammers are
exploiting DKIM through replay, identifies conflicting scenarios,
and outlines a solution space.



| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me how
they would manage to do that. The header fields signed are under
control of the signer, not the original author. How do the
attackers coax the provider's signer into not signing certain fields?

By leaving them out.  Many DKIM signers, having observed this 
vulnerability, have started oversigning headers to prevent that.


I think the draft should flesh this out a bit more. I mean, are they 
just doing a bcc without a To: address? Are there other mechanisms? Is 
that suspicious or is it a legit behavior? I don't think I've seen a 
message without a To: address (or at least a legit one).


(again, this will be important to inform possible BCP things, and in the 
case of To: and Subject: to possibly making them required to be signed 
in a protocol change. certainly that might be an interesting discussion)


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

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

[Evan Burke]

On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas  wrote:

> | taking advantage of the flexibility in DKIM to
>> | selectively sign headers, the spammer may intentionally leave out
>> | certain headers such as To:, and Subject: that can be added in later
>> | without damaging the existing DKIM signature.
>>
>>
>> I think this needs to be explained. It isn't obvious to me how they would
>> manage to do that. The header fields signed are under control of the
>> signer, not the original author. How do the attackers coax the provider's
>> signer into not signing certain fields?
>>
> By leaving them out.  Many DKIM signers, having observed this
> vulnerability, have started oversigning headers to prevent that.
>
> I think the draft should flesh this out a bit more. I mean, are they just
> doing a bcc without a To: address? Are there other mechanisms? Is that
> suspicious or is it a legit behavior? I don't think I've seen a message
> without a To: address (or at least a legit one).
>

I more frequently saw replay attackers adding a second set of certain
headers to the message during replay. As long as the original header was
still present and matched the signature hash, the signature was intact.
Regardless, oversigning solves both cases.

(again, this will be important to inform possible BCP things, and in the
> case of To: and Subject: to possibly making them required to be signed in a
> protocol change. certainly that might be an interesting discussion)
>

The M3AAWG BCP will cover recommended header signing/oversigning policies.
I'll make sure that's shared here when it's published.
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Wei Chuang]

On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas  wrote:

>
> On 2/10/23 10:23 AM, Wei Chuang wrote:
>
> Hi all,
> I've posted an updated version of the draft-chuang-dkim-replay-problem-01
> 
> draft.  It cleans up a lot from the -00 rough draft state so hopefully it's
> more clear.  It builds a case that spammers are exploiting DKIM through
> replay, identifies conflicting scenarios, and outlines a solution space.
>
> -Wei
>
> PS Many, many thanks goes to Dave Crocker for his editorial advice.
>
> ___
> Ietf-dkim mailing 
> listIetf-dkim@ietf.orghttps://www.ietf.org/mailman/listinfo/ietf-dkim
>
>
> | When large amounts of spam are received by the mailbox provider, the
> | operator’s filtering engine will eventually react by dropping the
> | reputation of the original DKIM signer.
>
>
> I think this needs some amount of justification. It's really easy to hand
> wave this and it's certainly a common assumption, but it's not a given.
> What exactly does "dropping the reputation" actually mean in practice? Does
> it mean for certain senders, certain classes of senders, the whole sending
> domain? How are such drops weighted? What are plausible metrics the
> receiver might use? One mailbox sending a lot of spam but otherwise the
> sending domain seems to be behaving well, seems pretty relevant to the
> topic.
>
> This is especially true if a BCP gets written here. The problem statement
> should be as specific as it can be about why it's hard for receivers to
> overcome this problem. If there's a lot of proprietary stuff that can't be
> talked about, then it's pretty impossible to put together a BCP since we
> collectively have no idea what those practices are.
>
> I think this really goes to the heart of what's going on here.
>
> Mike
>
> Agreed there is a certain amount of hand waviness and things have to be
described abstractly as various black boxes in the system due to their
proprietary nature.  But I think it is necessary to mention them to
motivate the deliverability aspect of the problem i.e. why it is impacted,
to provide some intuition for the problem space.  Similarly how DKIM replay
impacts the utility of email to the end users.  I think we would agree that
there is a preference for a deterministic DKIM replay solution and avoid
reputation systems where possible.

-Wei


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


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

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

[Dave Crocker]

On 2/10/2023 1:47 PM, Wei Chuang wrote:


| In addition to being DKIM authenticated via the spoofed DKIM signature


...
To be honest I was wondering about that word choice myself. I can 
change that in the next rev.



There is a long-standing misuse of the term spoof, in the anti-abuse 
community.  This is in spite of constant efforts to correct the 
(mis)practice.


So, when someone authorized to use an address, then its use is not spoofing.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


Another thing that should probably be discussed is outbound spam 
filtering. At a high level, this is really about the sender sending 
spam. But email afaik is silent on whether senders or receivers should 
filter for spam (and if there is, it would be good to reference it). 
Sender filtering is especially pertinent and may well have clues of how 
a sender can mitigate it. A breakdown of how spammers defeat that 
outbound filtering would be really useful. For example, is the spam 
intended for mailboxes on the sending domain (eg, gmail)? Or do they go 
through a two stage process where they first get the spam through the 
sender, and then test it on the intended receiving domains? All of that 
would be really helpful.


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

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

[Michael Thomas]

On 2/10/23 2:11 PM, Wei Chuang wrote:



On Fri, Feb 10, 2023 at 1:48 PM Michael Thomas  wrote:

| When large amounts of spam are received by the mailbox provider,
the

| operator’s filtering engine will eventually react by dropping the
| reputation of the original DKIM signer.

I think this needs some amount of justification. It's really easy
to hand wave this and it's certainly a common assumption, but it's
not a given. What exactly does "dropping the reputation" actually
mean in practice? Does it mean for certain senders, certain
classes of senders, the whole sending domain? How are such drops
weighted? What are plausible metrics the receiver might use? One
mailbox sending a lot of spam but otherwise the sending domain
seems to be behaving well, seems pretty relevant to the topic.

This is especially true if a BCP gets written here. The problem
statement should be as specific as it can be about why it's hard
for receivers to overcome this problem. If there's a lot of
proprietary stuff that can't be talked about, then it's pretty
impossible to put together a BCP since we collectively have no
idea what those practices are.

I think this really goes to the heart of what's going on here.

Mike

Agreed there is a certain amount of hand waviness and things have to 
be described abstractly as various black boxes in the system due to 
their proprietary nature.  But I think it is necessary to mention them 
to motivate the deliverability aspect of the problem i.e. why it is 
impacted, to provide some intuition for the problem space. 
Similarly how DKIM replay impacts the utility of email to the end 
users.  I think we would agree that there is a preference for a 
deterministic DKIM replay solution and avoid reputation systems where 
possible.


I understand that Google is not going to tell us exactly how it makes 
its filtering and reputation decisions, but that sort of begs the 
question of whether we can know what is "best" or "common" given that we 
don't know what is "not best" and "not common" out in the industry. 
Obviously if we can observe behavior from the outside (eg, not signing 
To: and Subject:) that's fair game. But a nebulous "lowers the 
reputation" leaves us to just speculate as to what that means. That is 
not a very good place to be in for a standards body.


I think that stake holders are going to have to come to some consensus 
of what they will and won't share. That in turn will inform the wg what 
it can and can't do. If the problem statement remains really vague, that 
means the solution space is going to be further constrained.


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

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

[Michael Thomas]

On 2/10/23 2:10 PM, Evan Burke wrote:



On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas  wrote:


| taking advantage of the flexibility in DKIM to
| selectively sign headers, the spammer may intentionally leave out
| certain headers such as To:, and Subject: that can be added in later
| without damaging the existing DKIM signature.

I think this needs to be explained. It isn't obvious to me
how they would manage to do that. The header fields signed
are under control of the signer, not the original author. How
do the attackers coax the provider's signer into not signing
certain fields?

By leaving them out.  Many DKIM signers, having observed this
vulnerability, have started oversigning headers to prevent that.


I think the draft should flesh this out a bit more. I mean, are
they just doing a bcc without a To: address? Are there other
mechanisms? Is that suspicious or is it a legit behavior? I don't
think I've seen a message without a To: address (or at least a
legit one).


I more frequently saw replay attackers adding a second set of certain 
headers to the message during replay. As long as the original header 
was still present and matched the signature hash, the signature was 
intact. Regardless, oversigning solves both cases.


Then it should be in the problem statement of what they are doing. A 
well documented account of the current cat and mouse game would be 
really helpful. Speculation on where it it may go would be helpful too. 
I'm sure that text would be appreciated too. (if it isn't obvious, this 
draft seems like a good way forward on the problem statement to me).




(again, this will be important to inform possible BCP things, and
in the case of To: and Subject: to possibly making them required
to be signed in a protocol change. certainly that might be an
interesting discussion)

The M3AAWG BCP will cover recommended header signing/oversigning 
policies. I'll make sure that's shared here when it's published.



Any idea when that might drop?

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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:



[]


SPF authentication is possible, but may not be advisable.  The
Originator does this by publishing an SPF policy that covers the
Outbound Filtering Service IPs but this IP sharing weakens
authentication.

Why do you say it weakens it? Isn't it pretty common to import the SPF 
record of ESPs, and in this case outbound filters into the sending 
domain's SPF record?


If it does weaken it, wouldn't that apply to the ESP case too?

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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

| resign for DKIM on behalf of the Originator though the
| Originator increases risk of losing control of their private key.

I'm pretty sure that the best practice here is to just create a 
selector(s) for the ESP's, etc, signing keys. You definitely don't want 
to be handing your private keys out.


That's how gmail hosts and signs for my domain here.

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

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

[Michael Thomas]

On 2/10/23 10:23 AM, Wei Chuang wrote:

Hi all,
I've posted an updated version of the 
draft-chuang-dkim-replay-problem-01 
 
draft.  It cleans up a lot from the -00 rough draft state so hopefully 
it's more clear.  It builds a case that spammers are exploiting DKIM 
through replay, identifies conflicting scenarios, and outlines a 
solution space.


-Wei

PS Many, many thanks goes to Dave Crocker for his editorial advice.

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


| Transmission through an Inbound Filtering Service

I think it should be made clear that SPF will fail if checked on any 
receiver farther downstream from the MX record. I think that's really 
what's going on here, and has little to do with filtering services, etc.


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

[Ietf-dkim] replay clues

[Michael Thomas]

I've always thought that the likelihood of a protocol level solution for 
this issue is pretty close to zero if not zero. The various proposed 
solutions in the problem draft haven't given me any reason to dissuade 
me of that notion.


That said, I think that we might be able to catalog some clues that 
something is suspicious which taken with many other clues can be used to 
by a receiver to make an ultimate decision of spamminess. A good example 
is the unsigned To: and Subject: lines. Even if it's strictly allowed by 
the spec, that doesn't mean it's not suspect. It could be really useful 
to collect this clues as input signals to a larger preponderance of 
evidence.


Mike

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

Re: [Ietf-dkim] replay clues

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas  wrote:

> I've always thought that the likelihood of a protocol level solution for
> this issue is pretty close to zero if not zero. The various proposed
> solutions in the problem draft haven't given me any reason to dissuade
> me of that notion.
>
> That said, I think that we might be able to catalog some clues that
> something is suspicious which taken with many other clues can be used to
> by a receiver to make an ultimate decision of spamminess. A good example
> is the unsigned To: and Subject: lines. Even if it's strictly allowed by
> the spec, that doesn't mean it's not suspect. It could be really useful
> to collect this clues as input signals to a larger preponderance of
> evidence.
>

Authentication-Results already noted the idea that a signature, even a
valid one, might still be considered not acceptable to the verifier and
reported differently for one reason or another.  An unsigned Subject was
the classic example.

Dealing with this in A-R nicely removes it from being dealt with at the
protocol level, where I would argue this sort of logic doesn't belong.

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

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

[Murray S. Kucherawy]

On Fri, Feb 10, 2023 at 12:06 PM Evan Burke  wrote:

>
> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:
>
>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>> > believe belongs in the solution space to be explored.
>>
>> Since ARC uses the same technology as DKIM and uses it in pretty much
>> the same was, my understanding is that it, too, has the potential for
>> replay.  Having a reference to this fact makes sense to me.
>>
>> It doesn't need more than a mention, at this point, I believe, which
>> makes the current quick, reference exactly the right text, IMO.
>>
>
> +1
>
> I realize there are some mixed opinions on ARC, but it's actively used on
> several of the world's largest email systems - some of the same ones where
> DKIM replay attacks are focused - so it's worth consideration as part of
> the solution space. It may not end up being a viable option, but now isn't
> the time to write it off.
>

Speaking only as a participant:

I also don't think a comment like "ARC has the same problem, for largely
the same reasons" is by itself harmful here.

What I think we should be sure to avoid is expending WG energy trying to
solve this problem in ARC-space.  That, I would argue, is outside the
charter.

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

Re: [Ietf-dkim] replay clues

[Scott Kitterman]

On February 11, 2023 5:23:39 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Fri, Feb 10, 2023 at 8:09 PM Michael Thomas  wrote:
>
>> I've always thought that the likelihood of a protocol level solution for
>> this issue is pretty close to zero if not zero. The various proposed
>> solutions in the problem draft haven't given me any reason to dissuade
>> me of that notion.
>>
>> That said, I think that we might be able to catalog some clues that
>> something is suspicious which taken with many other clues can be used to
>> by a receiver to make an ultimate decision of spamminess. A good example
>> is the unsigned To: and Subject: lines. Even if it's strictly allowed by
>> the spec, that doesn't mean it's not suspect. It could be really useful
>> to collect this clues as input signals to a larger preponderance of
>> evidence.
>>
>
>Authentication-Results already noted the idea that a signature, even a
>valid one, might still be considered not acceptable to the verifier and
>reported differently for one reason or another.  An unsigned Subject was
>the classic example.
>
>Dealing with this in A-R nicely removes it from being dealt with at the
>protocol level, where I would argue this sort of logic doesn't belong.

This is pretty close to the example in RFC 8601, section 2.4 for a 'policy' 
ptype result.

Scott K

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