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

[Roland Turner]

On 14/11/22 08:41, Scott Kitterman wrote:


On November 12, 2022 6:46:13 PM UTC, Wei Chuang 
 wrote:

>
>Received headers are generally not DKIM signed and spammers have
>stripped/probably modified them.  Another problem is that while a human can
>interpret the domain names, IP and other information present there in the
>headers, the non-standard naming and format variations means that it's not
>suitable as a machine readable signal in my opinion.

I don't think there's any point in pursuing solutions that require a human to 
read/understand anything about header fields.

Having reviewed the proposals again, it seems like anything that actively makes 
replays harder without adding additional indirect mail flow failures amounts to 
a plan to document the flow of the email to provide additional signal for 
receivers to understand what's been replayed versus what's a normal indirect 
flow.


Side thought: it occurs to me that any solution that relates to 
understanding the path is already addressed by a trivial extension to 
ARC, in particular that its headers are sufficiently uniform to be 
machine-readable, contain the information required to understand 
important information about the path (although not the Received: 
headers), and are cryptographically attestable. The required extension 
would simply be for forwarders performing non-DKIM-damaging forwarding 
to also perform ARC-sealing in order to present reliable information 
about the path to receivers. Putting forwarders in the position of 
benefiting from implementing ARC (or suffering more from not doing so) 
is not ideal but (a) the number who do so at scale is small and getting 
smaller, and (b) it doesn't create any dilemmas (vs. e.g. deciding 
whether to modify messages in a way which breaks DKIM). This doesn't 
need a WG; forwarders are free to do it and receivers are free to rely 
on it today.




I'm inclined to think that instead of specifying specific drafts to consider, 
the charter should point to the problem statement draft instead.


+1


I get the desire to limit the scope, but limiting the outcomes is the 
wrong way to do it.



- Roland


___
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 14/11/22 08:26, Scott Kitterman wrote:


Is compatibility with DKIM sufficient for  the charter or should there be
broader language about compatibility with existing email architecture?  I'm
inclined to say "Yes", but I'm unsure about wording.


+1



Similarly, at least one of them could lead to normal indirect mail flows being
identified as replay attacks.  Is something specific needed about being
compatible with existing email deployments more generally (beyond DKIM
deployment compatibility) needed?  Once agian, I'd say "Yes", but am not sure
how to word it.


+1


- Roland


___
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 13/11/22 03:05, Wei Chuang wrote:

On Fri, Nov 11, 2022 at 11:17 PM Roland Turner 
 wrote:



 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.

See the dispatch slides here 
 for 
operational experience and impact for at least Gmail and Fastmail (the 
presenters).  See the introduction.


Thanks, but that deck appears to contain no information about 
operational experience or impact for either organisation, it merely 
describes the attack and surveys the proposed improvements to defences. 
Also, while Bron's role at Fastmail is clear, your own involvement with 
Google's receiving of email is not: are you in fact part of Google's 
email abuse control function?


(I do not wish to belittle you, however the difference between 
involvement by someone who has spent years of their life solving this 
problem for real at scale and involvement by an interested engineer who 
merely happens to work for the same organisation is immense. Most of the 
fruitless debate on this problem over the last 20 years has been by 
people who are not responsible for defending large numbers of mailboxes 
pursuing merely plausible theories.)



Gmail saw DKIM replay ramp up in late 2021 and early 2022 but the 
impact has been reduced recently perhaps due to the mitigations the 
industry has put in place.


Right. What I'm suggesting is that undertaking work in an IETF WG is not 
wise if the people implementing those mitigations are not actively involved.




That said, the problem in the specification still remains.


That's not enough reason to charter work on it in an IETF WG. There has 
to be some reasonable chance of the work improving the situation. 
Without direct involvement by practitioners at the decision-making end 
of message transfer, I'd suggest that this is most unlikely.



I am not aware of any tools to help with the problem, hence the 
request to Dispatch to do this work.


I'd suggest that that, by itself, may be enough reason *not* to proceed.


 I (and the authors of the other drafts) believe that DKIM replay can 
be detected via some of the characteristics that the spammers exploit 
(see concepts I posted earlier around Nov 11, 2022, 2:18 PM) but the 
current email authentication protocols don't look for that.


As the discussion is currently about whether to undertake the work I've 
resisted critiquing the proposals directly, but as part of establishing 
whether there's a "there" there, I'd point out that all but one of those 
things is either redundant (vs. say ARC), unacceptably harmful (we use 
DKIM *in the first place* to facilitate forwarding outside of the 
domain-registrant/sender's control), or both. The exception is a 
standardised mechanism to allow a sender/signer to indicate the 
[approximate] number of intended recipients, with which receivers might 
make fact-based decisions about when to recognise an instance of this 
particular attack, but without the active involvement of large receivers 
this is still academic, just as SPF -all, DomainKeys o=~, and ADSP 
discardable were.


Perhaps a different tack: if you're not part of Google's email abuse 
control function, are you able to recruit people who are?


- Roland

___
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 13/11/22 21:06, Jim Fenton wrote:

On Nov 12, 2022, at 8:32 AM, Roland Turner 
 wrote:



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


I would give my opinion, but that’s off-topic for discussions of the 
replay problem.



Fair enough, but I understand that the current topic is discussion of 
a/the forum for work on that problem[1], rather than discussion of the 
problem itself. My intention was not to relitigate DMARC, but to 
understand what bearing that particular protocol's development path has 
on the present forum discussion. If you feel that you're able to cast 
light on that question, then I'd suggest that it's well within scope.



- Roland

1: whether to reactivate this WG, with or without a charter, with or 
without a BoF, etc.


___
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 November 12, 2022 6:46:13 PM UTC, Wei Chuang 
 wrote:
>On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman 
>wrote:
>
>> 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
>> > <
>> https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim
>> > -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?
>>
>
>A way of bridging this, particularly for approach 3, is to use legacy
>authentication in addition to the replay resistant technique.  Use the
>replay resistant technique when available in preference to DKIM for DMARC
>and reputation systems, but have it available to fall back to.  A follow on
>consideration then is why would anyone adopt the new replay resistant
>technique.  Presumably there would be deliverability incentives for senders
>and forwarders to adopt the replay resistant technique (due to the negative
>reputation effects DKIM replay has) and for receivers to avoid
>escalations.  In any case, I think the above categorization is pretty
>reasonable.
>
>
>> > > 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 h

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

[Scott Kitterman]

On Friday, November 11, 2022 12:27:38 PM EST Scott Kitterman wrote:
> 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:
...
> > > 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.

OK.  I've re-read the drafts with an eye to what we might want to consider for 
the charter (I have comments/feedback on all of them, but I'll save that for 
later).

Three of the four proposed solutions (as I read them) require capturing the 
contents of SMTP comments in some variant of a DKIM like signature.  As I've 
mentioned before, I think this class of solution is architecturally 
challenging at best.  Since MTAs may have their own rules about address 
rewriting, I don't think a 5322 oriented process such as DKIM signing can be 
assumed to know specifics of 5321 identities.  As a result, you would have to 
defer these new signature types and do them between RCPT TO and DATA.

As I read the proposed charter, this is fine since the only backwards 
compatibility that's required is with DKIM:

> Because of DKIM’s broad deployment, compatibility with existing
> deployments will be a critical factor, and it is unlikely that proposals
> that lack compatibility will proceed to publication.

Is compatibility with DKIM sufficient for  the charter or should there be 
broader language about compatibility with existing email architecture?  I'm 
inclined to say "Yes", but I'm unsure about wording.  

Similarly, at least one of them could lead to normal indirect mail flows being 
identified as replay attacks.  Is something specific needed about being 
compatible with existing email deployments more generally (beyond DKIM 
deployment compatibility) needed?  Once agian, I'd say "Yes", but am not sure 
how to word it.

Do these make sense?  Does anyone have specific suggestions?

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]

On November 13, 2022 9:07:21 PM UTC, Jim Fenton  wrote:
>On 9 Nov 2022, at 13:08, Barry Leiba wrote:
>
>> Murray is looking at re-opening the DKIM working group, chartering it
>> to work on replay mitigation.
>
>IIRC the result from Monday’s dispatch session was to go ahead and charter the 
>working group without a BOF. It seems to me that the discussion on this thread 
>in the last few days points to the need for a BOF prior to chartering.
>
>Given that IETF 115 just ended, it probably ought to be an interim BOF before 
>IETF 116.


I'd suggest waiting a bit to see how this discussion goes before deciding we 
need additional process.

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

[Jim Fenton]

On 9 Nov 2022, at 13:08, Barry Leiba wrote:

> Murray is looking at re-opening the DKIM working group, chartering it
> to work on replay mitigation.

IIRC the result from Monday’s dispatch session was to go ahead and charter the 
working group without a BOF. It seems to me that the discussion on this thread 
in the last few days points to the need for a BOF prior to chartering.

Given that IETF 115 just ended, it probably ought to be an interim BOF before 
IETF 116.

-Jim

___
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 Sat 12/Nov/2022 19:46:13 +0100 Wei Chuang wrote:

On Fri, Nov 11, 2022 at 9:31 PM Scott Kitterman  wrote:

On Friday, November 11, 2022 5:18:57 PM EST Wei Chuang wrote:
> On Thu, Nov 10, 2022 at 4:42 AM Scott Kitterman  wrote:


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



Yes, it is.



The slides
https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions
at Dispatch and the problem statement draft
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem
help describe the DKIM replay problem.



Thanks!

I think Section 2, *Mail Flow Scenarios* lacks the case of secondary MXes, 
especially if they are provided by a different ADMD.


For a nit, *ESP Bulk Sender* has to be promoted to section title.



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.


That's the easiest thing to do.  Correctly listed as #1.


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.


2 and 3 look the same to me.  We need to change something in the standards, and 
that would require to adjust the wording in the proposed charter, where it says:


compatibility with existing deployments will be a critical factor,
and it is unlikely that proposals that lack compatibility will
proceed to publication.


A way of bridging this, particularly for approach 3, is to use legacy 
authentication in addition to the replay resistant technique.  Use the 
replay resistant technique when available in preference to DKIM for DMARC 
and reputation systems, but have it available to fall back to.  A follow on 
consideration then is why would anyone adopt the new replay resistant 
technique.  Presumably there would be deliverability incentives for senders 
and forwarders to adopt the replay resistant technique (due to the negative 
reputation effects DKIM replay has) and for receivers to avoid escalations. 
In any case, I think the above categorization is pretty reasonable.


The two proposed replay resistant cryptographic domain based protocols that 
leverage ARC seem to be difficult to implement or a mailing list with thousands 
final recipients or a multi-hop forwarding.



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.


We cannot rely on spammers' habits.

I'd rather note that recipients not in To:/Cc:, when legal, require prior 
arrangement.  Bcc:, depending on use cases, requires either an explicit or an 
implicit agreement.  Admins set up secondary MXes and inbound filtering 
services.  Users subscribe to mailing lists ans newsletters, and request 
forwarding (when used for email portability).  In addition, in the latter 
cases, messages to the final recipient have a single envelope recipient.  That 
feature can be used to setup per-user whitelists, to be updated concurrently 
with the subscription/ forwarding setup.



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

[Jim Fenton]

> On Nov 12, 2022, at 8:32 AM, Roland Turner 
>  wrote:
> 
> 
>> 
>> 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].
> 
I would give my opinion, but that’s off-topic for discussions of the replay 
problem.

-Jim

___
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 11 Nov 2022, at 15:19, 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.

I would be interested in hearing what a mainstream mailbox provider has to say 
about the issue - is it actually an operational problem for them, how much of 
it they see, if they believe any changes could help them mitigate it - before 
expending much effort.

I’ve heard concern from some ESPs that DKIM replays will impact their domain 
reputation and delivery rates, but no confirmation from mailbox providers that 
it does (and if it does, whether that’s a protocol level problem or just 
something that should be tweaked in their reputation tracking).

Cheers,
  Steve

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