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

[Laura Atkins]

Snipping a bunch. 

> On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
> 
>>> 
>>> 
>>> 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 don’t understand this.

> 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’s One Message - sent to an address that has given permission to receive that 
message. What I hear you saying is tha ESPs that allow single messages sent to 
opt-in addresses deserve to have their domain reputation abused. Is this a 
correct summary of your argument? 

If it is, I guess we are at a standoff because I don’t think ESPs who are 
mostly doing the right thing (ie, letting folks send opt-in messages) deserve 
to have their reputation trashed by senders who are actually unwelcome (and 
know they’re unwelcome) on the ESPs platform. 

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

Isn’t that what the whole working group is exploring? Can we address this in 
any meaningful manner? You seem to want to have the discussion before we 
charter it, rather thn 

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

The senders are doing their work. They are not permitting the mail to go 
through their systems. They’re only sending opt-in mail through their systems. T

> 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 was around for the open relay discussions and I don’t see the parallels. 

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

What abuse problem has “the market” ever solved? Abuse (and other community 
problems) are solved by people taking action. Not by some magic wand of 
capitalism choosing ’the right’ answer. 

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

But are you representativ

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

[Steve Atkins]

> On 11 Nov 2022, at 09:23, Laura Atkins  wrote:
> 
>> 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.
> 
> They took responsibility for the single opt-in message that was sent through 
> their system. I’m not sure they have any responsibility for the million 
> copies of the message the recipient sends through a different infrastructure. 
> Unless you’re saying that DKIM signatures should only be assigned to mail 
> that has been manually reviewed by the infrastructure host?

Manual review wouldn’t help.

A single email advertising something sent to a single recipient who has 
consented to receive it isn’t problematic, and it looks pretty much like every 
legitimate customer of the ESP.

That same mail, byte-for-byte identical, sent through non-ESP infrastructure to 
a million non-consenting recipients is a problem. And it’s not one that, 
currently, the ESP can do that much to mitigate (there are things they do to 
attempt to, such as breaking redirector links and so on, but that’s not that 
effective and it’s after the incident).

It’s not a new concern - I remember sitting in a Yahoo conference room 
discussing exactly this issue before DomainKeys was launched - but as mailbox 
providers pay more attention to DKIM-keyed reputation of mail streams it’s one 
that’s actively being abused.

The onus is probably on the receivers to mitigate the several related problems, 
as they’re the only responsible party that’s in a position to do so (they’re 
the only ones other than the spammer who sees the email, and they’re the ones 
who are relying on DKIM identified mail streams to help deliver wanted mail and 
reject unwanted mail for their customers). I’m sure that ESPs would be happy to 
make changes that would assist them in doing that, of course.

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

[Alessandro Vesely]

On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:

On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:

[...]

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 was around for the open relay discussions and I don’t see the parallels.



I do.

Going to a mailbox provider (MP[*]), obtain an email address, and send a 
message from it is paralleled to going to an open relay and send a message 
through it.  The only differences are (1) the From: domain is constrained by 
the MP, and (2) the MP requires me to interact with their web server in order 
to setup an address.  They both seem negligible to me.


The MP limits the volume of messages that a user can send out.  However, by 
signing even one message, it takes the responsibility for its content.  After 
all, DKIM was designed to allow discernment based on domain name rather than IP 
address.  No surprise that someone can abuse a domain name through different IP 
addresses.  A hasty and imprudent signature could easily cause risks.


Now, why does the MP take responsibility for unknown content?

If we extend the open relays parallel, we'd forecast that allowing anonymous 
users to freely setup (hundreds of) email addresses has to come to an end.  Do 
MPs know the people they provide email services to?  If they do, they can 
afford the risk to put their reputation in their hands.


IOW, the simple solution is that free MPs send messages unsigned except for 
people they trust.



Best
Ale
--

[*] Previous messages use ESP, which I tend to associate to operators like 
Mailchimp, say, rather than Gmail.  I had a hard time trying to understand why 
ESPs would let folks send a single opt-in message...   Is it me?






___
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 11 Nov 2022, at 11:33, Alessandro Vesely  wrote:
> 
> On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:
>>> On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
>>> [...]
>>> 
>>> 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 was around for the open relay discussions and I don’t see the parallels.
> 
> 
> I do.
> 
> Going to a mailbox provider (MP[*]), obtain an email address, and send a 
> message from it is paralleled to going to an open relay and send a message 
> through it.  The only differences are (1) the From: domain is constrained by 
> the MP, and (2) the MP requires me to interact with their web server in order 
> to setup an address.  They both seem negligible to me.
> 
> The MP limits the volume of messages that a user can send out.  However, by 
> signing even one message, it takes the responsibility for its content.  

This appears to be the disconnect. The MP takes responsibility for the 
*MESSAGE* - that message, sent to that user. 

> After all, DKIM was designed to allow discernment based on domain name rather 
> than IP address.  No surprise that someone can abuse a domain name through 
> different IP addresses.  A hasty and imprudent signature could easily cause 
> risks.
> 
> Now, why does the MP take responsibility for unknown content?

They don’t. They take responsibility for the message. 

> If we extend the open relays parallel, we'd forecast that allowing anonymous 
> users to freely setup (hundreds of) email addresses has to come to an end.  
> Do MPs know the people they provide email services to?  If they do, they can 
> afford the risk to put their reputation in their hands.
> 
> IOW, the simple solution is that free MPs send messages unsigned except for 
> people they trust.

Just so I’m clear what you’re suggesting, what I’m hearing you say is that from 
Google, Yahoo, and Microsoft should be sent without a DKIM signature in the 
absence of some proof of identity for the sender?

> [*] Previous messages use ESP, which I tend to associate to operators like 
> Mailchimp, say, rather than Gmail.  I had a hard time trying to understand 
> why ESPs would let folks send a single opt-in message...   Is it me?

Why wouldn’t they? I sent myself a test message to make sure it was right 
before triggering the send to a larger list (and, BTW, Mailchimp actually 
limits the number of tests you can do). It’s basic QA. 

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

[Alessandro Vesely]

On Fri 11/Nov/2022 12:42:26 +0100 Laura Atkins wrote:

On 11 Nov 2022, at 11:33, Alessandro Vesely  wrote:
On Fri 11/Nov/2022 10:23:44 +0100 Laura Atkins wrote:

On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
[...]

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 was around for the open relay discussions and I don’t see the parallels.


I do.

Going to a mailbox provider (MP[*]), obtain an email address, and send a 
message from it is paralleled to going to an open relay and send a message 
through it.  The only differences are (1) the From: domain is constrained by 
the MP, and (2) the MP requires me to interact with their web server in order 
to setup an address.  They both seem negligible to me.

The MP limits the volume of messages that a user can send out.  However, by signing even one message, it takes the responsibility for its content.  


This appears to be the disconnect. The MP takes responsibility for the 
*MESSAGE* - that message, sent to that user.



Indeed, identifying the message transport is the functionality we're thinking 
to retrofit into DKIM.




After all, DKIM was designed to allow discernment based on domain name rather 
than IP address.  No surprise that someone can abuse a domain name through 
different IP addresses.  A hasty and imprudent signature could easily cause 
risks.

Now, why does the MP take responsibility for unknown content?


They don’t. They take responsibility for the message.



Actually, they do.  They might have thought to control message transport, while 
in fact their control terminates when the message leaves their premises.




If we extend the open relays parallel, we'd forecast that allowing anonymous 
users to freely setup (hundreds of) email addresses has to come to an end.  Do 
MPs know the people they provide email services to?  If they do, they can 
afford the risk to put their reputation in their hands.

IOW, the simple solution is that free MPs send messages unsigned except for 
people they trust.


Just so I’m clear what you’re suggesting, what I’m hearing you say is that from 
Google, Yahoo, and Microsoft should be sent without a DKIM signature in the 
absence of some proof of identity for the sender?



Well, I don't dare suggesting it, because I'm unaware of the business model 
that free mailbox providers have in mind.  I know some (non-free) MPs know 
their users personally.  For them, signing shouldn't be a problem, because 
traitorous users would be expunged and never accepted again.  That way, the 
user/ provider relationship works both ways.  Are there reports of replay 
attacks by known users?


Anyway, yes, you understand me right.  I'm not suggesting, I'm forecasting.



[*] Previous messages use ESP, which I tend to associate to operators like 
Mailchimp, say, rather than Gmail.  I had a hard time trying to understand why 
ESPs would let folks send a single opt-in message...   Is it me?


Why wouldn’t they? I sent myself a test message to make sure it was right 
before triggering the send to a larger list (and, BTW, Mailchimp actually 
limits the number of tests you can do). It’s basic QA.



Were you really talking about ESPs?  I thought ESPs identify their (paying) 
customers.  If I replay Mailchimp signature they could sue me, couldn't they?


That's one of the reasons I asked for some kind of report.  I /imagine/ replay 
attacks go through free MPs signatures, because it looks like the easiest way.



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

[Laura Atkins]

> On 11 Nov 2022, at 13:06, Alessandro Vesely  wrote:
> 
>>> [*] Previous messages use ESP, which I tend to associate to operators like 
>>> Mailchimp, say, rather than Gmail.  I had a hard time trying to understand 
>>> why ESPs would let folks send a single opt-in message...   Is it me?
>> Why wouldn’t they? I sent myself a test message to make sure it was right 
>> before triggering the send to a larger list (and, BTW, Mailchimp actually 
>> limits the number of tests you can do). It’s basic QA.
> 
> 
> Were you really talking about ESPs?  

Yes. I was. 

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

[Murray S. Kucherawy]

On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 
wrote:

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

That's part of at least one of the proposals on deck.  But that same
proposal talks about adding to the signal available to the receiver, not
changing or removing it.


> 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's not always a commercial ESP.  The identified attack works today if you
are a private user using a public mailbox service provider.


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

Repeating what I said above, I think there are some ideas on the table that
seek to provide incremental information for receivers to use in these
cases.  The disruption should be minimal, unless the receivers broadly get
it wrong.


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

I think that clearly this approach could work.  It's not a massive leap to
conclude that senders shouldn't sign spam, but it's also well established
that spam filters are not perfect.  All an attacker needs to do is identify
some pattern the filters don't detect, and get that signed, and this attack
works despite the best efforts of the sender.

More concerning to me: The IETF has previously taken the position that the
market will figure out spam and phishing, and therefore consideration of
protocol solutions should be deflected.  DMARC was the result.   I feel
that we leave this to the market, and that industry, at our own peril.  I
think we should give this a serious look before rejecting it outright.

-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 Fri, Nov 11, 2022 at 11:42 AM Laura Atkins 
wrote:

>
> The MP limits the volume of messages that a user can send out.  However,
> by signing even one message, it takes the responsibility for its content.
>
>
> This appears to be the disconnect. The MP takes responsibility for the
> *MESSAGE* - that message, sent to that user.
>

I think you've hit on possibly the most interesting part of this: In RFC
6376, we said "You're taking some responsibility for this message... and
oh, by the way, it could get replayed, and your claimed responsibility
extends to that case as well".  I don't know that we underscored the latter
very much then or since.

So to me, part of this hinges on whether we feel we need to remedy that, or
be comfortable pointing at 6376 and telling people to read it again,
properly this time, and seeing if the industry is OK with that.

-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

[Barry Leiba]

Indeed...
The issue here is this:

1. I get a (free) account on free-email.com.
2. I send myself email from my account to my account.  Of course,
free-email signs it, because it's sent from me to me: why would it
not?
3. I take that signed message and cart it over somewhere else, sending
it out to 10,000,000 recipients through somewhere else's
infrastructure.  It's legitimately signed by free-email.com.
4. Of course, it fails SPF validation.  But DKIM verifies and is
aligned to spam...@free-email.com, because there you go.

That's the attack.  It's happening all the time.  If between 1 and 2
we could use x= to cause the signature to time out, we'd be OK.
The trouble is that we have to make x= broad enough to deal with
legitimate delays.  And during that legitimate time, it's trivial for
a spammer to send out millions of spam messages.  Crap.  So x= doesn't
help.

We have to look at other options.  We thought of this when we designed
DKIM, but couldn't come up with anything that would work.  We have new
experience since then, and we want to look at alternatives, and decide
whether priorities have changed, use cases, have changed, and so on.

It's entirely possible that we still can't fix it without breaking use
cases that we're not willing to break.  But we have to try.

Barry

On Fri, Nov 11, 2022 at 3:19 PM Murray S. Kucherawy  wrote:
>
> On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins  wrote:
>>
>>
>> The MP limits the volume of messages that a user can send out.  However, by 
>> signing even one message, it takes the responsibility for its content.
>>
>>
>> This appears to be the disconnect. The MP takes responsibility for the 
>> *MESSAGE* - that message, sent to that user.
>
>
> I think you've hit on possibly the most interesting part of this: In RFC 
> 6376, we said "You're taking some responsibility for this message... and oh, 
> by the way, it could get replayed, and your claimed responsibility extends to 
> that case as well".  I don't know that we underscored the latter very much 
> then or since.
>
> So to me, part of this hinges on whether we feel we need to remedy that, or 
> be comfortable pointing at 6376 and telling people to read it again, properly 
> this time, and seeing if the industry is OK with that.
>
> -MSK
> ___
> 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]

On Friday, November 11, 2022 4:23:44 AM EST Laura Atkins wrote:
> Snipping a bunch.
> 
> > On 11 Nov 2022, at 05:04, Scott Kitterman  wrote:
> >>> 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 don’t understand this.

Typically for email forwarding the forwarder doesn't change the To:/Cc: in the 
message body.  They relay the message to the appropriate Rcpt To:.  As a 
result, for these indirect mail flows To:/Cc: will never match Rcpt To: at 
delivery.

> > 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’s One Message - sent to an address that has given permission to receive
> that message. What I hear you saying is tha ESPs that allow single messages
> sent to opt-in addresses deserve to have their domain reputation abused. Is
> this a correct summary of your argument?
> 
> If it is, I guess we are at a standoff because I don’t think ESPs who are
> mostly doing the right thing (ie, letting folks send opt-in messages)
> deserve to have their reputation trashed by senders who are actually
> unwelcome (and know they’re unwelcome) on the ESPs platform.

Your phrasing is harsher than I would put it, but not really wrong.  The 
problem is that there's no way to distinguish this case from many legitimate 
cases.  ESPs are probably going to need to step up their efforts to know their 
customers or push them to use their own domains (which aren't that hard to 
get).

> > 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.
> 
> Isn’t that what the whole working group is exploring? Can we address this in
> any meaningful manner? You seem to want to have the discussion before we
> charter it, rather thn

Yes.  I think before we charter work to solve a problem, we should understand 
the problem well enough to determine that there is a technically tractable 
problem to solve.  I'm increasingly convinced there is not.

> > 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.
> The senders are doing their work. They are not permitting the mail to go
> through their systems. They’re only sending opt-in mail through their
> systems. T

The definition of "doing their work" may need to be expanded.

> > 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 was around for the open relay discussions and I do

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

[Scott Kitterman]

On Friday, November 11, 2022 10:09:52 AM EST Murray S. Kucherawy wrote:
> On Fri, Nov 11, 2022 at 5:05 AM Scott Kitterman 
> 
> wrote:
> > > 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.
> 
> That's part of at least one of the proposals on deck.  But that same
> proposal talks about adding to the signal available to the receiver, not
> changing or removing it.
> 
> > 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's not always a commercial ESP.  The identified attack works today if you
> are a private user using a public mailbox service provider.
> 
> > 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.
> 
> Repeating what I said above, I think there are some ideas on the table that
> seek to provide incremental information for receivers to use in these
> cases.  The disruption should be minimal, unless the receivers broadly get
> it wrong.

The challenge is if that added information also applies equally to legitimate 
mail, it's merely an attractive nuisance we'd be better off not creating.

> > 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.
> 
> I think that clearly this approach could work.  It's not a massive leap to
> conclude that senders shouldn't sign spam, but it's also well established
> that spam filters are not perfect.  All an attacker needs to do is identify
> some pattern the filters don't detect, and get that signed, and this attack
> works despite the best efforts of the sender.
> 
> More concerning to me: The IETF has previously taken the position that the
> market will figure out spam and phishing, and therefore consideration of
> protocol solutions should be deflected.  DMARC was the result.   I feel
> that we leave this to the market, and that industry, at our own peril.  I
> think we should give this a serious look before rejecting it outright.

I agree with this.  The challenge is finding a technically tractable way to 
distinguish this problematic case from normal usage.  I still owe the authors 
of the proposed solutions a more detailed study of the proposals, which I 
won't have bandwidth to do until at least Sunday.

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

[Scott Kitterman]

OK.  Let's alter your scenario slightly.

In step 2, instead of sending to yourself, you send it to an email list which 
(as we have been begging them to do for 15 years) does not make any changes in 
the message to invalidate that DKIM signature.

So in step 3, the message goes to X thousands (probably not millions, so the 
scale is slightly less) of recipients through somewhere else's infrastructure.  
It's legitimately signed by free-email.com.

Step 4 is identical.

How do we distinguish your scenario from this version at a technical level?

Scott K

On Friday, November 11, 2022 11:46:13 AM EST Barry Leiba wrote:
> Indeed...
> The issue here is this:
> 
> 1. I get a (free) account on free-email.com.
> 2. I send myself email from my account to my account.  Of course,
> free-email signs it, because it's sent from me to me: why would it
> not?
> 3. I take that signed message and cart it over somewhere else, sending
> it out to 10,000,000 recipients through somewhere else's
> infrastructure.  It's legitimately signed by free-email.com.
> 4. Of course, it fails SPF validation.  But DKIM verifies and is
> aligned to spam...@free-email.com, because there you go.
> 
> That's the attack.  It's happening all the time.  If between 1 and 2
> we could use x= to cause the signature to time out, we'd be OK.
> The trouble is that we have to make x= broad enough to deal with
> legitimate delays.  And during that legitimate time, it's trivial for
> a spammer to send out millions of spam messages.  Crap.  So x= doesn't
> help.
> 
> We have to look at other options.  We thought of this when we designed
> DKIM, but couldn't come up with anything that would work.  We have new
> experience since then, and we want to look at alternatives, and decide
> whether priorities have changed, use cases, have changed, and so on.
> 
> It's entirely possible that we still can't fix it without breaking use
> cases that we're not willing to break.  But we have to try.
> 
> Barry
> 
> On Fri, Nov 11, 2022 at 3:19 PM Murray S. Kucherawy  
wrote:
> > On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins  
wrote:
> >> The MP limits the volume of messages that a user can send out.  However,
> >> by signing even one message, it takes the responsibility for its
> >> content.
> >> 
> >> 
> >> This appears to be the disconnect. The MP takes responsibility for the
> >> *MESSAGE* - that message, sent to that user.> 
> > I think you've hit on possibly the most interesting part of this: In RFC
> > 6376, we said "You're taking some responsibility for this message... and
> > oh, by the way, it could get replayed, and your claimed responsibility
> > extends to that case as well".  I don't know that we underscored the
> > latter very much then or since.
> > 
> > So to me, part of this hinges on whether we feel we need to remedy that,
> > or be comfortable pointing at 6376 and telling people to read it again,
> > properly this time, and seeing if the industry is OK with that.
> > 
> > -MSK
> > ___
> > 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

[Wei Chuang]

Sorry I'm late to this thread.

On Thu, Nov 10, 2022 at 4:42 AM 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?
>
> 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.
>

The slides

at Dispatch and the problem statement draft
 help
describe the DKIM replay problem.

There are some things that we could target at a technical level.  We
probably would look for characteristics in the typical attack flow i.e.
After having a spammy message signed, the spammer typically copies a
message from the inbox, and then broadcasts it with a high degree of
amplification.  We could look for

   - Messages that are sent to recipients that are not intended by the
   original sender or the forwarder
   - Messages may be viewed as traversing a path defined by the original
   sender and forwarder.   Messages taken from that intended path could be
   replay
   - A variation is: messages that are taken from the inbox and then resent
   - Count the signatures seen and filter by count

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

What I've seen is that the Received header shows the delivery of the
message to the initial recipient, followed by a new set of Received headers
that shows that the message has been resent.  Sometimes the spammer leaves
behind other clues like duplicate headers like multiple Date, Message-id or
Subject headers.

-Wei


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

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

[Wei Chuang]

On Fri, Nov 11, 2022 at 9:33 AM Scott Kitterman 
wrote:

> OK.  Let's alter your scenario slightly.
>
> In step 2, instead of sending to yourself, you send it to an email list
> which
> (as we have been begging them to do for 15 years) does not make any
> changes in
> the message to invalidate that DKIM signature.
>
> So in step 3, the message goes to X thousands (probably not millions, so
> the
> scale is slightly less) of recipients through somewhere else's
> infrastructure.
> It's legitimately signed by free-email.com.
>
> Step 4 is identical.
>
> How do we distinguish your scenario from this version at a technical level?
>

Agreed that ambiguity is the heart of the problem.  With the current
authentication methods DKIM or SPF, we can't tell the benign scenario from
the malicious one.  As noted in the reply to your earlier question from Nov
10, 2022, there are some conceptual "tells" that can distinguish benign
from malicious senders.  In terms of specifications that try to distinguish
those "tells", there were drafts presented at M3AAWG 56, and also posted to
dispatch :

   -

   draft-chuang-replay-resistant-arc
   
   -

   
   draft-gondwana-email-mailpath
   
   -


   

   draft-bradshaw-envelope-validation-extension-dkim
   

   -


   
   draft-kucherawy-dkim-anti-replay
   
   Messages
   

-Wei


>
> Scott K
>
> On Friday, November 11, 2022 11:46:13 AM EST Barry Leiba wrote:
> > Indeed...
> > The issue here is this:
> >
> > 1. I get a (free) account on free-email.com.
> > 2. I send myself email from my account to my account.  Of course,
> > free-email signs it, because it's sent from me to me: why would it
> > not?
> > 3. I take that signed message and cart it over somewhere else, sending
> > it out to 10,000,000 recipients through somewhere else's
> > infrastructure.  It's legitimately signed by free-email.com.
> > 4. Of course, it fails SPF validation.  But DKIM verifies and is
> > aligned to spam...@free-email.com, because there you go.
> >
> > That's the attack.  It's happening all the time.  If between 1 and 2
> > we could use x= to cause the signature to time out, we'd be OK.
> > The trouble is that we have to make x= broad enough to deal with
> > legitimate delays.  And during that legitimate time, it's trivial for
> > a spammer to send out millions of spam messages.  Crap.  So x= doesn't
> > help.
> >
> > We have to look at other options.  We thought of this when we designed
> > DKIM, but couldn't come up with anything that would work.  We have new
> > experience since then, and we want to look at alternatives, and decide
> > whether priorities have changed, use cases, have changed, and so on.
> >
> > It's entirely possible that we still can't fix it without breaking use
> > cases that we're not willing to break.  But we have to try.
> >
> > Barry
> >
> > On Fri, Nov 11, 2022 at 3:19 PM Murray S. Kucherawy 
>
> wrote:
> > > On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins 
>
> wrote:
> > >> The MP limits the volume of messages that a user can send out.
> However,
> > >> by signing even one message, it takes the responsibility for its
> > >> content.
> > >>
> > >>
> > >> This appears to be the disconnect. The MP takes responsibility for the
> > >> *MESSAGE* - that message, sent to that user.>
> > > I think you've hit on possibly the most interesting part of this: In
> RFC
> > > 6376, we said "You're taking some responsibility for this message...
> and
> > > oh, by the way, it could get replayed, and your claimed responsibility
> > > extends to that case as well".  I don't know that we underscored the
> > > latter very much then or since.
> > >
> > > So to me, part of this hinges on whether we feel we need to remedy
> that,
> > > or be comfortable pointing at 6376 and telling people to read it again,
> > > properly this time, and seeing if the industry is OK with that.
> > >
> > > -MSK
> > > ___
> > > 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-d

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

[Scott Kitterman]

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> Sorry I'm late to this thread.
> 
> On Thu, Nov 10, 2022 at 4:42 AM 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?
> > 
> > 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.
> 
> The slides
>  -replay-problem-and-possible-solutions> at Dispatch and the problem
> statement draft
>  help
> describe the DKIM replay problem.

I think this draft is very useful.  I think it supports my contention that 
this problem is not technically distinguishable from legitimate mail flows.

> There are some things that we could target at a technical level.  We
> probably would look for characteristics in the typical attack flow i.e.
> After having a spammy message signed, the spammer typically copies a
> message from the inbox, and then broadcasts it with a high degree of
> amplification.  We could look for
> 
>- Messages that are sent to recipients that are not intended by the
>original sender or the forwarder
>- Messages may be viewed as traversing a path defined by the original
>sender and forwarder.   Messages taken from that intended path could be
>replay
>- A variation is: messages that are taken from the inbox and then resent
>- Count the signatures seen and filter by count

I think that between the draft and the discussion so far there are a few 
classes of potential solutions:

1.  Signers have taken responsibility for the message when they signed it, so 
they get to live with the consequences of having done so (for this purpose, I 
think the "message" is the signed content of the message).  No standards 
action or changes required to DKIM, except maybe modernizing header field 
signing/over-signing recommendations to make replay at least a little more 
difficult.

2.  Introduce changes that break existing indirect mail flows.  Standards 
actions needed.  Senders and receivers both need to make changes.  Standards 
actions needed.  If we go down this path, would it be more honest just to 
declare indirect mail flows obsolete/deprecated (based on the prevalence of 
>From re-writing on mailing lists, common practice may be headed this way 
already due to DMARC).

3.  Changes that modify expectations for legitimate indirect mail flows that 
illegitimate indirect mail flows such as replay attacks will have difficulty 
copying.  These require changes by senders, indirect mail processors (e.g. 
mailing list providers and forwarders), and receivers.  Unlikely to be 
effective until widely implemented.

Are there more?
 
> > 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"?
> 
> What I've seen is that the Received header shows the delivery of the
> message to the initial recipient, followed by a new set of Received headers
> that shows that the message has been resent.  Sometimes the spammer leaves
> behind other clues like duplicate headers like multiple Date, Message-id or
> Subject headers.

None of these other clues need anything from DKIM to detect, although over 
signing such fields may help (no RFC is needed for this, senders can just do 
it, if it's useful).

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

[Roland Turner]

On 12/11/22 00:46, Barry Leiba wrote:


2. I send myself email from my account to my account.  Of course,
free-email signs it, because it's sent from me to me: why would it
not?
3. I take that signed message and cart it over somewhere else, sending
it out to 10,000,000 recipients through somewhere else's
infrastructure.  It's legitimately signed by free-email.com.


Straw-manning a possible mechanism: a DKIM signer is able to include 
information about the number of recipients that it intended to take 
responsibility for the message to be sent to[1]. A large receiver who's 
seeing orders of magnitude more copies knows that something is wrong[2]. 
Smaller receivers can't do much but probably aren't the major concern. A 
privacy concern for email sent by individuals arises because disclosing 
that there were any BCCs might be problematic, but this can be resolved 
by indicating e.g. "10 or fewer" rather than providing exact numbers, 
and the threshold in use can be selected by the signer to best deal with 
local conditions.


I have two concerns about the WG proposal:

1. Unless one or more of the larger receivers (a) has a useful tool to
   help with this problem, and (b) is willing to share operational
   experience, then we risk creating yet another lengthy, academic
   exercise (remember ADSP?). I'd suggest that this might be enough
   reason by itself not to proceed.
2. How is any possible "break the SMTP/message separation" solution
   handled? Does the possibility of doing so need to be expressed
   explicitly at this point? Does merely doing so induce additional
   bureaucratic hurdles? Does failing to do so tie the WG's hands
   behind its back?

- Roland


1: a field in the signature, a message header included in the signed 
set, etc.


2: whether the signer was lying or some other party is improperly 
amplifying is outside what this mechanism could determine, certainly, 
but it seems like a useful datum


___
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

[Roland Turner]

On 11/11/22 23:09, Murray S. Kucherawy wrote:


More concerning to me: The IETF has previously taken the position that 
the market will figure out spam and phishing, and therefore 
consideration of protocol solutions should be deflected.  DMARC was 
the result.   I feel that we leave this to the market, and that 
industry, at our own peril.  I think we should give this a serious 
look before rejecting it outright.


Are you able to state concisely why DMARC was a harmful outcome, 
assuming that's your intended meaning ("peril")? From my admittedly 
somewhat bystanderish perspective, DMARC looked like a great success, 
particularly after IETF repeatedly failing for more than a decade[1].


- Roland


1: SPF -all, DomainKeys o=~ (IIRC), ADSP discardable

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