Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Barry Leiba]

We could add a sentence or two that says we’re seeing increasing spam
campaigns that use DKIM replay to get their spam sent out, taking advantage
of — and subsequently damaging — the reputation of the domain that signed
the original message.  Do you think that would be useful?

More detail than that doesn’t belong in the charter.  I would expect to put
more detail in the Introduction section of the document we come up with.

The “compatibility” part of the charter, and the discussions of what the
ultimate solution will be, will be what handles the “not breaking email
architecture” and minimizing damage to legitimate email flows.  I don’t
think more of that detail needs to be in the charter either, but if you
disagree please suggest specific text you’d like to see.

Barry

On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman  wrote:

> I think having a precised understanding of the problem that the charter is
> meant to address is important.  I am having a hard time finding a
> technical
> distinction between a "replay attack" and the, by design, nature of DKIM's
> independence from transport details.
>
> I have not read all the drafts, but the ones I have looked at seem to want
> to
> tie some aspect of a DKIM signature to something in the envelope.  I think
> that would be a 5321/5322 layering violation that would make such
> proposals
> difficult for protocol based systems to implement.
>
> I think there needs to be something about not breaking the architecture of
> email in the charter based on what I've read so far, but I don't think I
> have
> a fine enough understanding of the problem yet to propose words.
>
> Understanding and bounding the problem is, I think, an essential
> prerequisite
> to the charter.  We've seen efforts fail before due to a lack of consensus
> on
> the exact problem (DBOUND comes immediately to mind).
>
> Even if there's no report, I think we should make sure we understand the
> problem first.
>
> Would someone who's pushing for a solution please describe what's being
> done
> that's technically distinguishable from something like traditional email
> forwarding (e.g. using may alumni.example.edu address and then
> alumni.example.edu forwards it to my current "real" address).  By design,
> DKIM
> has no problem with this behavior, so I'd like to understand how to
> distinguish good from bad in this space.
>
> Scott K
>
> On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote:
> > Is this relevant to the charter?  Do you doubt the attacks
> > sufficiently that you would want to object to chartering a working
> > group to address the issue?
> >
> > Barry
> >
> > On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely  wrote:
> > > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:
> > > > [...]
> > > >
> > > > Current proposals include the following drafts:
> > > >   - draft-bradshaw-envelope-validation-extension-dkim
> > > >   - draft-chuang-replay-resistant-arc
> > > >   - draft-gondwana-email-mailpath
> > > >   - draft-kucherawy-dkim-anti-replay
> > > >
> > > > The working group will start by considering those proposals; other
> > > > proposals remain welcome.
> > >
> > > Isn't there a report on relevant replay attacks?  All the above I-D say
> > > that replay attacks are a problem.  Bron adds that the attack was
> widely
> > > seen in early 2022.  However, there's not a panoramic view of the
> > > problem, mentioning volume, scope, targets and such.
> > >
> > > I know replay attacks are possible, but I never saw one.
> > >
> > >
> > > Best
> > > Ale
> > > --
> > >
> > >
> > >
> > >
> > > ___
> > > 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] DKIM reply mitigations: re-opening the DKIM working group

[Scott Kitterman]

I agree that we don't want too much detail in the charter about the technical 
nature of the problem, but I would like to understand it in more detail in 
order to better assess the appropriateness of what is there.

If a domain is signing spam and their reputation suffers as a result, isn't 
that the system working as designed?

I would like to understand what is the technical characteristic of these 
messages that is distinct from the non-bad ones.  As far as I can tell (and 
this isn't the first time I've run across these discussions), there isn't  one. 
 
If that's the case, then I don't think there's an actual technical solution to 
this problem.

Once work is chartered in the IETF, it tends to get a certain momentum toward 
producing a result.  Before agreeing that we have a charter to solve a 
problem, I'd like to understand we have a problem that can be solved, even 
though that requires a bit of discussion at a more detailed level than what 
eventually goes in the charter.

Leaving aside algorithms and processes for a moment, could someone describe 
how an technically proficient human would examine one of these messages and 
determine they are "bad"?

I'll think about what else needs to be there from a compatibility perspective.  
I need to re-read the drafts and think about it first.

Scott K

On Thursday, November 10, 2022 5:35:08 AM EST Barry Leiba wrote:
> We could add a sentence or two that says we’re seeing increasing spam
> campaigns that use DKIM replay to get their spam sent out, taking advantage
> of — and subsequently damaging — the reputation of the domain that signed
> the original message.  Do you think that would be useful?
> 
> More detail than that doesn’t belong in the charter.  I would expect to put
> more detail in the Introduction section of the document we come up with.
> 
> The “compatibility” part of the charter, and the discussions of what the
> ultimate solution will be, will be what handles the “not breaking email
> architecture” and minimizing damage to legitimate email flows.  I don’t
> think more of that detail needs to be in the charter either, but if you
> disagree please suggest specific text you’d like to see.
> 
> Barry
> 
> On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman  wrote:
> > I think having a precised understanding of the problem that the charter is
> > meant to address is important.  I am having a hard time finding a
> > technical
> > distinction between a "replay attack" and the, by design, nature of DKIM's
> > independence from transport details.
> > 
> > I have not read all the drafts, but the ones I have looked at seem to want
> > to
> > tie some aspect of a DKIM signature to something in the envelope.  I think
> > that would be a 5321/5322 layering violation that would make such
> > proposals
> > difficult for protocol based systems to implement.
> > 
> > I think there needs to be something about not breaking the architecture of
> > email in the charter based on what I've read so far, but I don't think I
> > have
> > a fine enough understanding of the problem yet to propose words.
> > 
> > Understanding and bounding the problem is, I think, an essential
> > prerequisite
> > to the charter.  We've seen efforts fail before due to a lack of consensus
> > on
> > the exact problem (DBOUND comes immediately to mind).
> > 
> > Even if there's no report, I think we should make sure we understand the
> > problem first.
> > 
> > Would someone who's pushing for a solution please describe what's being
> > done
> > that's technically distinguishable from something like traditional email
> > forwarding (e.g. using may alumni.example.edu address and then
> > alumni.example.edu forwards it to my current "real" address).  By design,
> > DKIM
> > has no problem with this behavior, so I'd like to understand how to
> > distinguish good from bad in this space.
> > 
> > Scott K
> > 
> > On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote:
> > > Is this relevant to the charter?  Do you doubt the attacks
> > > sufficiently that you would want to object to chartering a working
> > > group to address the issue?
> > > 
> > > Barry
> > > 
> > > On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely  wrote:
> > > > On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba wrote:
> > > > > [...]
> > > > > 
> > > > > Current proposals include the following drafts:
> > > > >   - draft-bradshaw-envelope-validation-extension-dkim
> > > > >   - draft-chuang-replay-resistant-arc
> > > > >   - draft-gondwana-email-mailpath
> > > > >   - draft-kucherawy-dkim-anti-replay
> > > > > 
> > > > > The working group will start by considering those proposals; other
> > > > > proposals remain welcome.
> > > > 
> > > > Isn't there a report on relevant replay attacks?  All the above I-D
> > > > say
> > > > that replay attacks are a problem.  Bron adds that the attack was
> > 
> > widely
> > 
> > > > seen in early 2022.  However, there's not a panoramic view of the
> > > > problem, mentioning volume, scop

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman 
wrote:

> I agree that we don't want too much detail in the charter about the
> technical
> nature of the problem, but I would like to understand it in more detail in
> order to better assess the appropriateness of what is there.
>
> If a domain is signing spam and their reputation suffers as a result,
> isn't
> that the system working as designed?
>

For cases of very large operators, like Gmail, their reputation doesn't
suffer to the extent that their mail becomes untrusted.  The abuser thus
has a very long runway before something like that could start to happen.


> I would like to understand what is the technical characteristic of these
> messages that is distinct from the non-bad ones.  As far as I can tell
> (and
> this isn't the first time I've run across these discussions), there isn't
> one.
> If that's the case, then I don't think there's an actual technical
> solution to
> this problem.
>

It may or may not be possible to reduce it to a technical characteristic.
However, the attack amounts to a Trojan horse whose distribution is enabled
or increased by DKIM; who's to say malware can't be sent this way?  In my
view, that makes it something worth attention.

Once work is chartered in the IETF, it tends to get a certain momentum
> toward
> producing a result.  Before agreeing that we have a charter to solve a
> problem, I'd like to understand we have a problem that can be solved, even
> though that requires a bit of discussion at a more detailed level than
> what
> eventually goes in the charter.
>

I think of the charter as the contract between the working group and the
IESG that constrains what it will produce.  The questions you're asking
here tend to be the things we ask in the discussion around the charter,
particularly during a BoF session to discuss working group formation, but
not necessarily what goes in the charter directly.

So I think your question is a legitimate one, but I'm not sure what text
the charter ought to contain in order to address it directly.


> Leaving aside algorithms and processes for a moment, could someone
> describe
> how an technically proficient human would examine one of these messages
> and
> determine they are "bad"?
>

The message itself is usually indistinguishable between its first instance
(when it's signed) and its second (when it's replayed).  The envelope,
however, has to vary; that's a key property of the attack.  One possible
solution is to come up with a scheme that factors that part of the envelope
into DKIM's operation; another is to pack useful metadata into the message,
independent of DKIM, so a downstream receiver stands a chance of telling
the difference between a first instance and a replayed instance.  Which of
those two approaches should be used, and the exact mechanism of doing so,
would be the output(s) of this working group.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Laura Atkins]

> On 10 Nov 2022, at 12:42, Scott Kitterman  wrote:
> 
> I agree that we don't want too much detail in the charter about the technical 
> nature of the problem, but I would like to understand it in more detail in 
> order to better assess the appropriateness of what is there.
> 
> If a domain is signing spam and their reputation suffers as a result, isn't 
> that the system working as designed?

No. Because the domain signing the spam is not the domain sending the spam. 
What’s happening is that people are sending a single message through a system, 
getting it signed with a different domain’s DKIM key and then taking that 
message to a third party platform (or botnet) and sending it out. 

In many cases, the reason the mail isn’t going out through the signing domain 
is because the signing domain’s anti-spam heuristics are good enough that the 
sender couldn’t maintain an account there long enough to send out any volume of 
email. That’s why the domain has a good reputation - because they block spam 
off their network. This is a way to steal the good reputation from the good 
ESP. 

> I would like to understand what is the technical characteristic of these 
> messages that is distinct from the non-bad ones.  As far as I can tell (and 
> this isn't the first time I've run across these discussions), there isn't  
> one.  
> If that's the case, then I don't think there's an actual technical solution 
> to 
> this problem.
> 
> Once work is chartered in the IETF, it tends to get a certain momentum toward 
> producing a result.  Before agreeing that we have a charter to solve a 
> problem, I'd like to understand we have a problem that can be solved, even 
> though that requires a bit of discussion at a more detailed level than what 
> eventually goes in the charter.

> Leaving aside algorithms and processes for a moment, could someone describe 
> how an technically proficient human would examine one of these messages and 
> determine they are "bad"?

There are a couple of characteristics that stand out. 

1) They’re coming through infrastructure distinct from the infrastructure that 
normally sends those signed messages out. So, someone will open up a trial 
account at a ESP, send one message with the spam content they want to 
themselves and get the ESPs signature on it. Then they’ll take that message and 
send it out through a different sending system that does not change any of the 
signatures. 

2) The messages often have two different To: lines

laura 

> 
> I'll think about what else needs to be there from a compatibility 
> perspective.  
> I need to re-read the drafts and think about it first.
> 
> Scott K
> 
> On Thursday, November 10, 2022 5:35:08 AM EST Barry Leiba wrote:
>> We could add a sentence or two that says we’re seeing increasing spam
>> campaigns that use DKIM replay to get their spam sent out, taking advantage
>> of — and subsequently damaging — the reputation of the domain that signed
>> the original message.  Do you think that would be useful?
>> 
>> More detail than that doesn’t belong in the charter.  I would expect to put
>> more detail in the Introduction section of the document we come up with.
>> 
>> The “compatibility” part of the charter, and the discussions of what the
>> ultimate solution will be, will be what handles the “not breaking email
>> architecture” and minimizing damage to legitimate email flows.  I don’t
>> think more of that detail needs to be in the charter either, but if you
>> disagree please suggest specific text you’d like to see.
>> 
>> Barry
>> 
>> On Wed, Nov 9, 2022 at 7:56 PM Scott Kitterman  wrote:
>>> I think having a precised understanding of the problem that the charter is
>>> meant to address is important.  I am having a hard time finding a
>>> technical
>>> distinction between a "replay attack" and the, by design, nature of DKIM's
>>> independence from transport details.
>>> 
>>> I have not read all the drafts, but the ones I have looked at seem to want
>>> to
>>> tie some aspect of a DKIM signature to something in the envelope.  I think
>>> that would be a 5321/5322 layering violation that would make such
>>> proposals
>>> difficult for protocol based systems to implement.
>>> 
>>> I think there needs to be something about not breaking the architecture of
>>> email in the charter based on what I've read so far, but I don't think I
>>> have
>>> a fine enough understanding of the problem yet to propose words.
>>> 
>>> Understanding and bounding the problem is, I think, an essential
>>> prerequisite
>>> to the charter.  We've seen efforts fail before due to a lack of consensus
>>> on
>>> the exact problem (DBOUND comes immediately to mind).
>>> 
>>> Even if there's no report, I think we should make sure we understand the
>>> problem first.
>>> 
>>> Would someone who's pushing for a solution please describe what's being
>>> done
>>> that's technically distinguishable from something like traditional email
>>> forwarding (e.g. using may alumni.example.e

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins 
wrote:

> In many cases, the reason the mail isn’t going out through the signing
> domain is because the signing domain’s anti-spam heuristics are good enough
> that the sender couldn’t maintain an account there long enough to send out
> any volume of email. That’s why the domain has a good reputation - because
> they block spam off their network. This is a way to steal the good
> reputation from the good ESP.
>

Interesting.  Almost seems like "SPF against the signing domain" could be a
win, except for all the usual forwarding concerns.

2) The messages often have two different To: lines
>

This violates RFC 5322, so it would be easy to filter these out, except
that we would need to know how common and tolerated this is today among
legitimate messages.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Laura Atkins]

> On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
> 
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins  > wrote:
> In many cases, the reason the mail isn’t going out through the signing domain 
> is because the signing domain’s anti-spam heuristics are good enough that the 
> sender couldn’t maintain an account there long enough to send out any volume 
> of email. That’s why the domain has a good reputation - because they block 
> spam off their network. This is a way to steal the good reputation from the 
> good ESP. 
> 
> Interesting.  Almost seems like "SPF against the signing domain" could be a 
> win, except for all the usual forwarding concerns.

I think a lot of it is being blocked and the receiving orgs are aware it’s 
happening and the replays are not contributing that much to the actual 
reputation of the originating domain. Certainly, what I’m hearing from the 
folks who are being used as the signer for the replay is they’re not seeing a 
whole lot of impact on delivery and reputation. 

> 2) The messages often have two different To: lines
> 
> This violates RFC 5322, so it would be easy to filter these out, except that 
> we would need to know how common and tolerated this is today among legitimate 
> messages.

Yup. I believe replay attacks are one of the things driving the current 
increase in ’this message violates the RFCs, fix your stuff and try again 
later’ rejections by the big mailbox providers. 

-- 
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] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

[offlist]

On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins 
wrote:

>
> On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
>
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins 
> wrote:
>
>> In many cases, the reason the mail isn’t going out through the signing
>> domain is because the signing domain’s anti-spam heuristics are good enough
>> that the sender couldn’t maintain an account there long enough to send out
>> any volume of email. That’s why the domain has a good reputation - because
>> they block spam off their network. This is a way to steal the good
>> reputation from the good ESP.
>>
>
> Interesting.  Almost seems like "SPF against the signing domain" could be
> a win, except for all the usual forwarding concerns.
>
>
> I think a lot of it is being blocked and the receiving orgs are aware it’s
> happening and the replays are not contributing that much to the actual
> reputation of the originating domain. Certainly, what I’m hearing from the
> folks who are being used as the signer for the replay is they’re not seeing
> a whole lot of impact on delivery and reputation.
>

Am I reading this right, i.e., you think this is mostly a non-issue because
it's easy to spot and filter?

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Murray S. Kucherawy]

On Thu, Nov 10, 2022 at 1:24 PM Murray S. Kucherawy 
wrote:

> [offlist]
>
> ...
>

Actually I didn't intend for it to be offlist, sorry for the confusing tag.

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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Laura Atkins]

> On 10 Nov 2022, at 13:24, Murray S. Kucherawy  wrote:
> 
> [offlist]
> 
> On Thu, Nov 10, 2022 at 1:21 PM Laura Atkins  > wrote:
> 
>> On 10 Nov 2022, at 13:17, Murray S. Kucherawy > > wrote:
>> 
>> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins > > wrote:
>> In many cases, the reason the mail isn’t going out through the signing 
>> domain is because the signing domain’s anti-spam heuristics are good enough 
>> that the sender couldn’t maintain an account there long enough to send out 
>> any volume of email. That’s why the domain has a good reputation - because 
>> they block spam off their network. This is a way to steal the good 
>> reputation from the good ESP. 
>> 
>> Interesting.  Almost seems like "SPF against the signing domain" could be a 
>> win, except for all the usual forwarding concerns.
> 
> I think a lot of it is being blocked and the receiving orgs are aware it’s 
> happening and the replays are not contributing that much to the actual 
> reputation of the originating domain. Certainly, what I’m hearing from the 
> folks who are being used as the signer for the replay is they’re not seeing a 
> whole lot of impact on delivery and reputation. 
> 
> Am I reading this right, i.e., you think this is mostly a non-issue because 
> it's easy to spot and filter?

I think it’s not an issue for deliverability for the forged domain. (Remember: 
my opinions are filtered through the deliverability lens). I also think that 
the practical solutions applied by the big filters (using the tuple of SPF 
domain, DKIM domain and  5322.from domain as the identity for the message; 
noting normal patterns of delivery for a particular d=; enforcing RFC 
compliance on the incoming mail) are outpacing any changes to the standard that 
we might have. I don’t know if they have an appetite to implement a new or 
extended standard that is supposed to fix a problem that they have already 
(mostly) solved. 

I think there is space to have the discussion - is this something that needs a 
standard change / update? Are there other things we want to address? But I’m 
also thinking we need to engage with the mailbox providers to get their 
viewpoints on it.

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] DKIM reply mitigations: re-opening the DKIM working group

[Steve Atkins]

> On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
> 
> On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins  > wrote:
> In many cases, the reason the mail isn’t going out through the signing domain 
> is because the signing domain’s anti-spam heuristics are good enough that the 
> sender couldn’t maintain an account there long enough to send out any volume 
> of email. That’s why the domain has a good reputation - because they block 
> spam off their network. This is a way to steal the good reputation from the 
> good ESP. 
> 
> Interesting.  Almost seems like "SPF against the signing domain" could be a 
> win, except for all the usual forwarding concerns.
> 
> 2) The messages often have two different To: lines
> 
> This violates RFC 5322, so it would be easy to filter these out, except that 
> we would need to know how common and tolerated this is today among legitimate 
> messages.


The other (more common?) case is that the original recipient is in the signed 
822.To, while the new recipient is not in the To: or Cc: headers at all. While 
that’s just the same as old-school alias forwarding, and you might not be able 
to spot that on any given single email I’d bet that it’s easy to spot and block 
at a mailbox provider of any size.

A heuristic I’ve suggested previously is “If the recipient’s email address is 
not in the To: or Cc: header then treat the mail as unsigned”.

Cheers,
  Steve


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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Scott Kitterman]

On Thursday, November 10, 2022 7:54:25 AM EST Murray S. Kucherawy wrote:
> On Thu, Nov 10, 2022 at 12:42 PM Scott Kitterman 
> 
> wrote:
> > I agree that we don't want too much detail in the charter about the
> > technical
> > nature of the problem, but I would like to understand it in more detail in
> > order to better assess the appropriateness of what is there.
> > 
> > If a domain is signing spam and their reputation suffers as a result,
> > isn't
> > that the system working as designed?
> 
> For cases of very large operators, like Gmail, their reputation doesn't
> suffer to the extent that their mail becomes untrusted.  The abuser thus
> has a very long runway before something like that could start to happen.
> 
> > I would like to understand what is the technical characteristic of these
> > messages that is distinct from the non-bad ones.  As far as I can tell
> > (and
> > this isn't the first time I've run across these discussions), there isn't
> > one.
> > If that's the case, then I don't think there's an actual technical
> > solution to
> > this problem.
> 
> It may or may not be possible to reduce it to a technical characteristic.
> However, the attack amounts to a Trojan horse whose distribution is enabled
> or increased by DKIM; who's to say malware can't be sent this way?  In my
> view, that makes it something worth attention.

I agree it's worth attention, but let's make sure we understand the problem 
precisely enough to determine if we've succeeded.

> > Once work is chartered in the IETF, it tends to get a certain momentum 
> > toward
> > producing a result.  Before agreeing that we have a charter to solve a
> > problem, I'd like to understand we have a problem that can be solved, even
> > though that requires a bit of discussion at a more detailed level than
> > what
> > eventually goes in the charter.
> 
> I think of the charter as the contract between the working group and the
> IESG that constrains what it will produce.  The questions you're asking
> here tend to be the things we ask in the discussion around the charter,
> particularly during a BoF session to discuss working group formation, but
> not necessarily what goes in the charter directly.
> 
> So I think your question is a legitimate one, but I'm not sure what text
> the charter ought to contain in order to address it directly.

Thanks.  I think this is a useful discussion and we'll probably know the 
answer to the question by the time we get to the end of it.

> > Leaving aside algorithms and processes for a moment, could someone
> > describe
> > how an technically proficient human would examine one of these messages
> > and
> > determine they are "bad"?
> 
> The message itself is usually indistinguishable between its first instance
> (when it's signed) and its second (when it's replayed).  The envelope,
> however, has to vary; that's a key property of the attack.  One possible
> solution is to come up with a scheme that factors that part of the envelope
> into DKIM's operation; another is to pack useful metadata into the message,
> independent of DKIM, so a downstream receiver stands a chance of telling
> the difference between a first instance and a replayed instance.  Which of
> those two approaches should be used, and the exact mechanism of doing so,
> would be the output(s) of this working group.

This is helpful.

It does highlight the architectural concerns I have.  

First, as in the alumni address example I gave, the envelope varying is a part 
of normal, legitimate email flows.  If we are not careful, we'll recreate all 
the architectural limitations of SPF.  You could, in fact, fairly trivially 
solve this problem in DMARC by creating a new alignment type which requires 
both DKIM and SPF to pass.  That would have interoperability problems, but I 
think anything this group might develop ought to be notably more consistent 
with backward compatibility than that would be.  Not for the charter, but it 
might be a reasonable benchmark to consider for determining if we've 
succeeded.

Second, what you're suggesting as a possible class of solution involves taking 
information from the envelope and including it in the body.  Because the Mail 
From, for example, isn't always known prior to submission, you might end up 
having to modify the body of the message somewhere between the Mail From 
command and Data in the SMTP session.  This seems like a risky mixing of 5321 
and 5322 functions.  I have no idea how I would implement it.

Let me think about what charter suggestions I have based on this.

Thanks,

Scott K



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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Alessandro Vesely]

On Thu 10/Nov/2022 14:32:16 +0100 Steve Atkins wrote:
The other (more common?) case is that the original recipient is in the signed 
822.To, while the new recipient is not in the To: or Cc: headers at all. While 
that’s just the same as old-school alias forwarding, and you might not be able 
to spot that on any given single email I’d bet that it’s easy to spot and block 
at a mailbox provider of any size.


A heuristic I’ve suggested previously is “If the recipient’s email address is 
not in the To: or Cc: header then treat the mail as unsigned”.



Or reject it outright unless the From: is in your address book.

Is it true that Bcc: is only used when there is a well established relationship 
between author and recipient?  For example, I use it to reach my Sent folder, 
and reject messages addressed to my Sent folder if they don't come from me.


OTOH, signing Bcc:s would betray their existence, although it can be done 
without revealing their content.



Best
Ale
--





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

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

[Scott Kitterman]

On Thursday, November 10, 2022 8:32:16 AM EST Steve Atkins wrote:
> > On 10 Nov 2022, at 13:17, Murray S. Kucherawy  wrote:
> > 
> > On Thu, Nov 10, 2022 at 12:54 PM Laura Atkins  > > wrote: In many cases, the reason the
> > mail isn’t going out through the signing domain is because the signing
> > domain’s anti-spam heuristics are good enough that the sender couldn’t
> > maintain an account there long enough to send out any volume of email.
> > That’s why the domain has a good reputation - because they block spam off
> > their network. This is a way to steal the good reputation from the good
> > ESP.
> > 
> > Interesting.  Almost seems like "SPF against the signing domain" could be
> > a win, except for all the usual forwarding concerns.
> > 
> > 2) The messages often have two different To: lines
> > 
> > This violates RFC 5322, so it would be easy to filter these out, except
> > that we would need to know how common and tolerated this is today among
> > legitimate messages.
> The other (more common?) case is that the original recipient is in the
> signed 822.To, while the new recipient is not in the To: or Cc: headers at
> all. While that’s just the same as old-school alias forwarding, and you
> might not be able to spot that on any given single email I’d bet that it’s
> easy to spot and block at a mailbox provider of any size.
> 
> A heuristic I’ve suggested previously is “If the recipient’s email address
> is not in the To: or Cc: header then treat the mail as unsigned”.

Which is a fancy way of making DKIM only work for direct mail flows.

I've been thinking some more about this and mentally I'm swinging back more 
towards the system is working as designed, don't mess with it.

If an ESP is willing to take on a trial customer they know nothing about and 
let them send email leveraging the reputation of the ESP's domain, why is it 
wrong that it suffers when that does not end well.

It is a fundamental precept of DKIM that when a domain signs an email, they 
are taking responsibility for it (See the RFC 6376 introduction and more 
specifically 2.5 and 2.6).  It's further reinforced by a note in 5.1 that 
begins:

>   INFORMATIVE NOTE: A Signer can be implemented as part of any
>   portion of the mail system as deemed appropriate, including an
>   MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
>   Signers should beware of signing (and thereby asserting
>   responsibility for) messages that may be problematic.

I've yet to see any proposed problem that can be resolved without disrupting 
legitimate mail flows or standing the 5321/5322 architectural division on its 
head.  I know it when I see it isn't a sufficient definition.

My more cynical side sees this issue as senders trying to offload more work on 
receivers even though it's work that the sender is explicitly responsible for.

For those that have been around for awhile this reminds me of the now long 
dead controversy about closing open relays.  It's not identical, but I think 
it rhymes.

Back in the mists of the early Internet we didn't have submission services 
because any client could send email via (most) any MTA, so they weren't 
needed.  As you can imagine, spamming was incredibly easy and the community 
gradually came around to the point that you can't just relay email for anyone, 
an MTA should serve authorized users (I oversimplify here).  As this consensus 
was being developed, a substantial number of MTA operators objected.  
Eventually, being an open relay meant no one would take mail from you.

This seems similar.

I can imagine the market solving this.  If there are two ESPs and one is 
careful about who is allowed to send mail signed by their domain and the other 
is not, I suspect that eventually superior reputation will result in superior 
deliverability, which should result in being able to charge more for a premium 
service.

As a receiver, if I have access to a quantitative reputation scoring system 
for IP addresses and domains, I might counter this, in the meantime, by 
looking for mail from IP addresses with statistically significantly worse 
reputation than the reputation of the domain and treat those messages more 
suspiciously.  I don't know that I would spend effort on special signature 
decoding mechanisms that are inherently risky for false positives.

Although not in scope for this discussion, SPF can have similar issues when 
ESPs are not sufficiently careful about what email they let out from their 
servers with their domain in Mail From, so this isn't a DKIM unique issue.

Ultimately, I don't think senders should DKIM sign mail they aren't willing to 
take responsibility for, since that's exactly what a DKIM signature is 
supposed to signify.

Scott K


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