[Ietf-dkim] Re: DKIM with body length

[Wei Chuang]

On Mon, May 20, 2024 at 7:17 PM Murray S. Kucherawy 
wrote:

> On Sun, May 19, 2024 at 9:27 AM Wei Chuang  40google@dmarc.ietf.org> wrote:
>


>
>
Dave Crocker mentioned that there is a pathway to do a narrow update to the
>> RFC6376 as an individual submission.  I agree that it is a good idea as
>> hopefully a narrow update can be done relatively quickly.  I understand
>> that body length "l=" was meant to help DKIM tolerate adding a footer
>> that a mailing list might do and that there is pressure from the DMARC
>> world to think about this.  Perhaps that still can be done except in a
>> better secure way, and that work could be a separate document to permit it
>> time to figure out how to do it.  One idea is to have the forwarder sign
>> with an ARC Message-Signature and would take ownership of the new message.
>> The forwarder would describe the offsets to recover the original body
>> length and some receiver can validate the original DKIM signature.  Those
>> offsets will also describe the forwarder's contribution to the message.
>> There would also be problems around secure footer modification of
>> Content-type header that are unsolved e.g. what to do if Content-type is
>> oversigned.  All this work might be good candidates for the newly chartered
>> Mailmaint WG.
>>
>
> Before we make suggestions about ARC, I would strongly suggest someone try
> that as a solution or mitigation to this problem.  I would not like us to
> publish something that shouts about this being a serious problem but then
> presents untested solution(s).  And frankly, I'd like to see ARC graduate
> out of Experimental status if that's what we want to put forward as a
> solution.
>
> As to MAILMAINT as a venue, we'll have to see whether the community thinks
> this is "big" or "small"; if the former, it should probably get its own WG.
>
>
Just specifically in regards authenticating mailing list modifications:
fair enough that the ideas should be implemented first before any sort of
IETF publication for it.  Still there ought to be a place for informal,
early discussion of ideas on authenticating mailing lists.  For this
proposal, I think there are issues around the intersection of DKIM signing
and Content-type, and in particular, there will be advice such as in the
researcher's blogpost
<https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/> that
calls for "h=" oversigning the Content-type header to help prevent the
delimitter modification as was done.  While understandable, I suspect this
prevents adding a mailing list footer as a new MIME part and perhaps too
restrictive.  Instead would it be reasonable to say there be sufficient
protection if the forwarder takes ownership of appended footers?  If not,
another approach would be to version the Content-type header?  Yet another
approach would be to resign the DKIM signature by the forwarder, but that
hides who the sender is causing UI and spam filtering problems.  Going back
to my original point, would the ietf-dkim list be the right place for this
cross-cutting discussion?  I think there are a few targeted questions that
need some discussion.  (We're interested prototyping but that's at least a
quarter or so away)

-Wei
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: DKIM with body length

[Wei Chuang]

On Mon, May 20, 2024 at 5:29 PM John Levine  wrote:

> It appears that Wei Chuang   said:
> >-=-=-=-=-=-
> >
> >Hi DKIM folks,
> >As many of you know there was a DKIM security vulnerability disclosure
> >Friday around the signature header body length tag "l=". The blog post is
> >here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
> >The authors state that an adversary can append a malicious footer to a
> >message with DKIM w/body length, then rewrite the Content-type header mime
> >delimitter, that will cause the apparent body to be that of the footer but
> >will authenticate as the original DKIM signature.
>
> This exact attack is described on page 41 of RFC 6376:
>
>If the "l=" signature tag is in use (see Section 3.5), the Content-
>Type field is also a candidate for being included as it could be
>replaced in a way that causes completely different content to be
>rendered to the receiving user.
>
> There really is nothing whatsoever new here.
>
> I agree that it would be a good idea to discourage people from using
> the l= tag but first I am trying to talk to the few places that send
> me l= mail and see if I can figure out why they do it.
>
>
As the blog post authors state, the new thing is that folks are using DKIM
with body length "l=" tag.  I too was surprised to see data supporting what
the author wrote, that many many senders are signing DKIM with body
length.  While small in overall traffic volume, they are a diverse group
with many Fortune 500 companies and others with significant infrastructure
responsibilities that send messages with DKIM with body length.  Over the
last 7 days there are 71048 distinct domains that had at least one passing
DKIM signature with body length.  There is a long tail of senders with
just  a few messages of their overall traffic volume which masks their
usage, but many also send the majority of their traffic signed with body
length and thus much more easily found.
-Wei
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] DKIM with body length

[Wei Chuang]

Hi DKIM folks,
As many of you know there was a DKIM security vulnerability disclosure
Friday around the signature header body length tag "l=". The blog post is
here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/
The authors state that an adversary can append a malicious footer to a
message with DKIM w/body length, then rewrite the Content-type header mime
delimitter, that will cause the apparent body to be that of the footer but
will authenticate as the original DKIM signature.  This enables spoofing
the original sender's identity, hence can spoof DMARC and BIMI but with a
malicious message body.  DKIM RFC6376 section 8.2  already
describes this problem, which the authors acknowledge, but according to
them what is new is that there actually is mail traffic with DKIM-Signature
w/body length which includes Fortune 500 companies.

Others have noted that the amount of traffic using DKIM w/body length is
small, and from where I sit in Gmail I would agree.  However I also agree
with the blog post authors based on that same data that many of the
impacted domains are systemically important email senders that really
should be paying attention to the RFC section 8.2 and their email security
much more carefully.  Some of the names are mentioned in the blog post and
that should be sufficient to convince everyone of the risk.  I would argue
that the body length feature in DKIM represents a significant spoofing
hence security risk and that it must be discouraged to the extent
possible.  The standards community can help by deprecating the body length
tag "l=" from the DKIM RFC.

Dave Crocker mentioned that there is a pathway to do a narrow update to the
RFC6376 as an individual submission.  I agree that it is a good idea as
hopefully a narrow update can be done relatively quickly.  I understand
that body length "l=" was meant to help DKIM tolerate adding a footer
that a mailing list might do and that there is pressure from the DMARC
world to think about this.  Perhaps that still can be done except in a
better secure way, and that work could be a separate document to permit it
time to figure out how to do it.  One idea is to have the forwarder sign
with an ARC Message-Signature and would take ownership of the new message.
The forwarder would describe the offsets to recover the original body
length and some receiver can validate the original DKIM signature.  Those
offsets will also describe the forwarder's contribution to the message.
There would also be problems around secure footer modification of
Content-type header that are unsolved e.g. what to do if Content-type is
oversigned.  All this work might be good candidates for the newly chartered
Mailmaint WG.

-Wei
___
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Re: [Ietf-dkim] DKIM Working Group Status Update

[Wei Chuang]

I was there at M3AAWG and concur with the chair's observations.  I should
also note I was part of the group who proposed restarting the DKIM WG at
Dispatch IETF-115.  My hope back then was that solving DKIM replay
systematically could be a starting point for resolving more general email
authentication problems that to me seems to be the root cause of the
unresolved conflict in the DMARCbis WG.  As such I'm saddened if this group
concludes with just documenting a set of best practices to mitigate DKIM
replay, as I don't feel this systematically resolves the authentication
issues such as DKIM replay that I see today.  Just before M3AAWG, I saw
spammers had a campaign that used a combination of DKIM replay plus SPF
upgrade.  Going forward I suspect the spammers will keep using creative
combinations of attacks driven by the Darwinian evolution afforded by the
whack-a-mole approach we're stuck with.

FWIW regarding the idea of replacing ARC.  I'll start by noting that ARC is
a starting point and would argue it's easier to adopt ARC than to replace
it, but if folks have a reasonable proposal, please publish a draft.  If it
helps resolve the general authentication issue, we're interested in
exploring that too.

We plan to publish the DARA results when they become available, whatever
the outcome for this group.  Also we can help with the Replay BCP as well.
-Wei



On Thu, Oct 26, 2023 at 3:48 AM Laura Atkins 
wrote:

>
> Hello, All
>
> To remind folks where the group is, we currently have a problem statement
> that needs to be discussed so we can reach consensus to adopt it. This
> requires participation from members of this list. The current problem
> statement is available at:
> https://datatracker.ietf.org/doc/draft-ietf-dkim-replay-problem/
>
> Per the charter (https://datatracker.ietf.org/wg/dkim/about/) the
> consensus problem statement was due to be filed in the datatracker in
> April. It’s now October and we’ve had no real discussion about the problem
> statement for months. I think it’s fair to say this group has stalled.
> There doesn’t seem to be any real interest in working on this problem.
>
> As much of the initial impetus for the group came out of discussions at a
> M3AAWG meeting, I asked for a session during the most recent meeting
> (October 2023, Brooklyn) to discuss whether or not there was enough
> interest to move the IETF group forward. I asked for, and was granted,
> permission to report back on the session here.
>
> My primary goal for the session was:
>
> Determine if there is a critical mass of people willing to commit to
> moving the working group forward and if so
>
>-
>
>Get firm commitments from individuals about what they can do for the
>process
>
>
>-
>
>Collaboratively develop a plan of action on getting this done
>
>
> If there was not a critical mass of people willing to commit to moving the
> group forward, then I would take that into consideration and work with the
> IETF. Any remaining session time would be focused on what MAAWG could do to
> address the issue.
>
> I started off by asking the group if there was any confusion about what
> the problem was. I then read my definition of a DKIM replay attack to
> ensure we were all on the same page.
>
> “A DKIM replay attack is one where a bad actor sends a single message
> through a high reputation system, gets a DKIM signature to a mailbox they
> control. They then take that message and resend it, unchanged, through a
> system they control that does not add a DKIM signature. This message
> carries the original system’s high reputation d= value and may receive
> better delivery due to that.”
>
> Members in the room added additional reasons for DKIM replay attack:
>
>-
>
>Damage the sender’s reputation
>-
>
>Inflict damage on the sender’s infrastructure (not removing List-Unsub
>headers can generate significant traffic on a sender’s unsubscribe
>infrastructure, for instance)
>-
>
>Use the sender’s reputation to warm up new infrastructure controlled
>by the attacker
>
>
> With most of the room agreeing these were the issues and problems, I asked
> for a show of hands for who was willing to commit to coming to this working
> group and participating. There were approximately 8 hands raised out of a
> room of approximately 50 participants.
>
> It was my opinion 8 people does not constitute a critical mass of people
> to move the working group forward and I said so. The IETF area director,
> who was at the meeting, asked the group if they were happy about only 8
> people making the decisions for them.
>
> There was a discussion about next steps. Individuals working for some
> large providers (both on the sending bulk mail side and on the large
> receiving mail side) indicated they thought the problem was mostly
> mitigated by things they implemented on their end. Other individuals
> discussed potential problems and fixes.
>
> I then called for a rough consensus for a path forward

Re: [Ietf-dkim] What makes this posting different from the original posting?

[Wei Chuang]

On Wed, Aug 30, 2023 at 1:18 AM Laura Atkins 
wrote:

>
>
> On 29 Aug 2023, at 19:07, Dave Crocker  wrote:
>
> Not that this is all that new a question, but I think it might be worthy
> of more (and maybe different focus)...
>
> When a message is used in a DKIM Replay Attack:
>
>1. It originates from a domain name having good reputation
>2. It passes quality checks from that sending domain
>3. It goes to a collaborating receiving site, which presumably means
>that site is not conducting quality assessments
>4. It is re-posted, preserving the original DKIM signature, but now
>becomes an attack
>
> Two thoughts:
>
>1. If the substance of the message should fail a quality assessment,
>why does it pass at the outbound (sending) site?
>
> Spam isn’t really about substance, though, it’s about being unwanted and
> volume. A lot of things outbound folks use to identify spam require volume
> - like ‘is this audience similar to the audience we’ve seen report high
> levels of spam in the past’ or ‘does this send to addresses we know receive
> a lot of spam’ or ‘is this account sending to a lot of bad addresses’.
> There are other checks, like ‘does this email contain a link pointing to a
> hostname on any of these DNSBLs’ - but that’s trivially solved by just
> pulling out a link that isn’t on a DNSBL. The professional spam gangs, who
> are likely behind the attacks, have a deep bench of domains that they pull
> in and out of circulation on a regular basis.
>
> This also doesn’t address the problem that Google mentioned where they saw
> Youtube alerts / welcome messages replayed, possibly as a way to create a
> good IP reputation.
>

+1 to the points above, especially about professional spam gangs that have
the resources to bypass the outbound spam protections.

>
>1. If the problem is reasonable content, but sent to many unintended
>(or, rather, undeclared) recipients, then the only characteristic of note
>is the fact of multiple transmissions.  So I'd guess it is only a real-time
>network of receivers, working in /very/ close coordination, to detect and
>deal with the attack. (it's not difficult to imagine scattered
>retransmissions, over time, to hide the coordination.  Sort of a spread
>spectrum transmission style...)
>
> My understanding is that one of the primary ways to ID a replay is using
> Google postmaster tools and seeing increases in their graphs without a
> corresponding increase in volume from their systems.
>

+1.  Also getting at Dave's point about creating meaningful signals out of
the replay spam amplification, yes, the magnitude and shape might be
helpful.  The Yahoo signature counting certainly represents using
magnitude as a signal and presumably in their distributed system they have
some framework that effectively evaluates these thresholds.  But a caveat,
at a certain threshold, large mailing-lists broadcasts are going to look
similar to spam attacks.  A different tack is the notion of getting
spammers to declare and sign their recipients (DARA).  If they do, then it
provides a forwarding identity to associate with the amplified traffic
pattern.  And if they don't, then block that traffic.

-Wei

laura
>
> --
> The Delivery Expert
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
>
> Delivery hints and commentary: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> 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] Proposals for tolerating mailing list modifications

[Wei Chuang]

I've updated both drafts to identify normative RFC references (outside of
the appendix).  They both include a few more bug fixes

1) Disclose and reverse mailing list transforms -03:
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/03/
2) Replay-resistant-arc draft -09:
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/09/

-Wei

On Mon, Aug 7, 2023 at 7:14 AM Barry Leiba  wrote:

> > I wasn't sure if I-Ds should set up normative references.  Based on the
> comments I'm guessing that I should
> > have.  I can make a pass to fix all that.
>
> Yes, sure they should.  Things that have to be understood in order to
> understand the I-D are normative.  Things that just give additional
> information but aren't necessary reading are informative.
>
> Barry
>
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Wei Chuang]

On Sat, Aug 5, 2023 at 9:15 AM Michael Thomas  wrote:

>
> On 8/5/23 9:05 AM, Murray S. Kucherawy wrote:
>
> On Fri, Aug 4, 2023 at 2:46 PM Michael Thomas  wrote:
>
>> Well, for starters ARC doesn't have broad deployment. But the author
>> doesn't say why ARC is needed or relevant. That is the point here. *All*
>> changes need to be justified including any imported mechanisms. The less
>> rat holes the better. Same with the mailing list modification draft. Why is
>> that even relevant?
>>
>
> With respect to ARC: There's a difference between asking for justification
> and demanding that the discussion be stopped before it even starts.  One of
> those is not okay.
>
> Ok, justify it. Even the author says ARC brings nothing to the table. That
> is not OK. Peddle the ARC agenda in a more appropriate venue.
>
We see a fair amount of important traffic carrying ARC headers, and we use
ARC negative assertions all the time.  It's the positive assertions that
have a trust issue and folks in M3AAWG have a work stream to tackle that.
Moreover the two proposed I-D don't need that trust anyways.

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

Re: [Ietf-dkim] Proposals for tolerating mailing list modifications

[Wei Chuang]

On Fri, Aug 4, 2023 at 11:51 AM Jim Fenton  wrote:

> On 4 Aug 2023, at 11:43, Dave Crocker wrote:
>
> > On 8/4/2023 11:39 AM, Jim Fenton wrote:
> >> concerns about creating a dependency on something experimental
> >
> >
> > I missed the details about a 'dependency'.
> >
> > What is it that would be dependent and what is it it would be dependent
> on?
>
> I was referring to draft-chuang-replay-resistant-arc-07, not what is
> mentioned in the subject line. It refers to RFC 8617 which is experimental,
> although it lists it as an informative rather than a normative reference
> which I think is incorrect.
>

I wasn't sure if I-Ds should set up normative references.  Based on the
comments I'm guessing that I should have.  I can make a pass to fix all
that.

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

Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Wei Chuang]

On Sat, Aug 5, 2023 at 4:51 AM Laura Atkins  wrote:

>
>
> On 5 Aug 2023, at 02:43, Jesse Thompson  wrote:
>
> On Thu, Aug 3, 2023, at 11:08 AM, Laura Atkins wrote:
>
> I agree with this and have been working to recruit folks to come here.
> I’ll also be in Brooklyn and pitching the need for participation in the
> IETF working group from folks in the email space who are seeing issues with
> this.
>
>
> I'll be there and interesting in participating. As an ESP/infrastructure
> provider I can say that we are "having" the issue, but can't say that we
> "seeing" the issue since visibility is only available to anti-spammers, and
> domain owners (who receive DMARC reports).
>
> We don't have visibility either as DKIM replay from an authentication
perspective looks like legitimate traffic.  Of course the content looks
spammy which has a negative impact, and it's hard to differentiate DKIM
replay from day to day variations.


> A big driver of the work is actually Google. As I understand it, they are
> having issues because the replay attackers are successfully stealing
> reputation of otherwise good senders in order to bypass some spam
> filtering. The replay attackers aren’t sending what we commonly think of as
> spam through the signers - as the message is sent to one recipient (not
> bulk) and it is opt-in (that recipient wants and has asked for the mail).
>

Agreed.  For a while DKIM replay was our number one source on increased
escalations, and that was heading towards an unsustainable place.
Fortunately DKIM replay and escalations calmed down quite a bit, perhaps
due to the ecosystem implementing various mitigation techniques.  For
example we've had good success with the duplicate message counting idea
reported at M3AAWG (and mentioned in the problem statement document), as
well as many implementing other techniques.   My worry is that these
techniques don't tackle the issue at the protocol level and several have
thresholds that spammers can exploit.  I suspect they will be back once
their current large-scale campaign with SPF runs its course.

I recall various assertions that the reason why DMARC has been successful
> is primarily because of the Reporting benefits (and I certainly agree with
> this assertion from my background as an enterprise domain owner), while the
> Conformance benefits seem to be more elusive (as evidenced by the
> inconsistent adoption by receivers and the debates around interoperability
> issues with indirect mail streams). Of course, the Authentication benefits
> are provided by DKIM/SPF, and yet DKIM signers have no standard mechanism
> to receive reports of how their signatures are being misused.
>
> If people think that Reporting is the reason why DMARC has been
> successful, then could we conclude that the lack of Reporting to DKIM
> signers is a problem worth addressing?
>
>
> That’s an interesting thought. I’m thinking the next step down - will it
> help minimize the problem for senders? ie, would reporting be fast enough
> that they could revoke a key? What might a report look like?
>

This is an interesting idea.  I'd imagine the sender could look for
elevated unexpected spikes in DKIM authenticated traffic.  It is analogous
to what some of the senders (ESP and MBP) reported they were doing using
the Gmail Postmaster tools to detect suspected DKIM replay.  Postmaster has
traffic graphs with DKIM authentication where they would look for
unexpected spikes.  Moreover they were correlated with a decrease in
reputation which is unfortunately something that DMARC reports won't have.
In any case DMARC reports should provide senders some visibility into
looking for DKIM authenticated traffic spikes.

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

[Ietf-dkim] Updated Replay Resistant ARC draft -07

[Wei Chuang]

Hi all,
I've updated the I-D draft-chuang-replay-resistant-arc

to -07.  That change does the following:
* Move the SeRCi and Relay ID proposals to the appendix
* Change all the examples use DARA
* Clean up the text now that DARA is the only proposal
* Move the "fh=" tag to the ARC-Message-Signature
* Change the language around Forwarded-to to permit multiple recipients
addresses to be specified

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

[Ietf-dkim] Proposals for tolerating mailing list modifications

[Wei Chuang]

Hi all,
I just wanted to mention two proposals for tolerating mailing list
modifications as suggested in person IETF-117.  They both use ARC headers
as infrastructure, but go about tolerating mailing list modifications in
different ways.
1) Disclose and reverse mailing list transforms so that we can authenticate
those messages with the original DKIM signature:
https://datatracker.ietf.org/doc/draft-chuang-mailing-list-modifications/
2) Replay-resistant-arc draft proposes authenticating a sender defined path
from originating sender to receiver.  It also has the sender specify the
intended recipient to prevent replay amplification.  It is insensitive to
message body modifications:
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/
Both approaches do not require trusting results in
ARC-Authentication-Results which has been a concern.  Instead they provide
signatures and values that a third party can independently and objectively
verify.  Discussion of these drafts belong on the DKIM list (
ietf-dkim@ietf.org).  Also just mentioning I've heard there are other
interesting related drafts.
-Wei
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Tolerating Mailing-List Modifications I-D Update

[Wei Chuang]

I've posted a -01 update to draft-chuang-mailing-list-modifications

.

   - Based on ARC RFC8617 (instead of draft-chuang-replay-resistant-arc)
   - Specify mailing-list procedures for rewriting the Subject, From and
   DKIM-Signature headers and for adding a text footer
   - Bunch of bug fixes and clarifications to examples and elsewhere

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

Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

[Wei Chuang]

On Thu, Jul 13, 2023 at 6:09 AM Steffen Nurpmeso  wrote:

> Alessandro Vesely wrote in
>  :
>  |On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote:
>  ...
>  |> Change:
>  |>
>  |> s/^Subject:\s+\(.*\)$/Subject:  [ietf-dkim] \1/
>  |
>  |
>  |This would change:
>  |
>  |Subject: Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D
>  |
>  |to:
>  |
>  |Subject: [ietf-dkim] Re: [Ietf-dkim] Tolerating Mailing-List
> Modifications \
>  |I-D
>
> Unfortunately it seems it becomes the new norm -- on those MLs
> which still place tags (and footers) -- to ignore RFCs and turn
> 'Re: [TAG] bla]' to '[TAG] Re: bla'.  I think, .., could it be
> Mailman 3 which does that.  (Note there still is only one tag, not
> two, as you show.)
> I am about to do something for the MUA i maintain ("have it on my
> TODO") because we deal badly.  (I was already about to email the
> mutt MUA list to ask what they are doing.)  Well i already had to
> implement space normalization after that TAB/SPACE mixup "fun"
> people had a couple of years ago, why not also special-treat a ML
> tag.
> (Of course this US-ASCII-centric Re: thing was counteracted long
> ago, by default we also support other things like wg:, aw: etc,
> and it is hookable.  I see commercially used (and browser-based,
> for sure) software doing things like Re-2:, Re-4: recently, which
> also requires adjustments to be made; i have to ask what software
> is doing that crime, msg-id is DIIE.08220004F734@HOST and the
> local thing then says "david3 by Tobit.Software", maybe i should
> buy myself a Harley-Goliathson, just to be on the safe side, what
> do i know.)
>
> I never understood what DMARC is for.  Don't mind.
> I mean it all fails if ML software simply does its ML thing like
> it did for decades.  If it knows otherwise it can adjust the
> headers fields, which results in that ugly "x via y" mess.
> If SPF / DKIM / ARC would be holistic, and if all parties support
> it, and if MLs would have been in the minds, then maybe ML
> software should add some sort of compressed base64 encoded comma
> separated list of field:body pairs of those headers that were
> modified as part of its business, and a DKIM extension should
> enforce inclusion of that header if present, and ARC should, too,
> (i have to reread those RFCs), and so restoration of data during
> ARC set validation can happen.  Maybe DKIM should gain an instance
> value like ARC has.  (Isn't it strange that DKIM is simply
> unshifted, whereas ARC has an instance value.  It can only be so
> that one of them is wrong, .. and i think ARC is.  No?)
>

If we could do it all over again, I agree we should have asked forwarder to
describe their headers with an ARC instance tag-value.  So the
draft-chuang-mailing-list-modifications in some sense is trying to provide
that capability to a subset of headers likely to be modified by
mailing-lists.  Also we should have been more ambitious with ARC and have
it explicitly be a message authenticator which it isn't today.  ARC today
just provides prior Authentication-Results in a verifiable
way.  draft-chuang-replay-resistant-arc is attempting to extend ARC in two
important ways:

   - It asks that the sender define who it will send the message to and
   will sign for the message to show intent.  This can be verified by a 3rd
   party.  (Levine had ideas along in this direction as well)
   - It asks the sender to specify all recipients and for the receiver to
   verify that the message went to one of those recipients to prevent replay
   amplification.

Notably it isn't absolutist about message modifications like DKIM
signatures, and instead uses ARC's message-signatures, which tolerate
forwarder changes in a controlled way.

-Wei


> What happened to Dave Crocker's idea against replay btw?
> Computing cost cannot be the problem can it.  Especially if
> sendmail" milters, shall this be used regulary for signing
> purposes, really execute once per receiver; why not add a
> per-receiver thing header among these costly actions.
>
> Ciao.
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>
> ___
> 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] Tolerating Mailing-List Modifications I-D

[Wei Chuang]

On Thu, Jul 13, 2023 at 1:29 AM Alessandro Vesely  wrote:

> On Thu 13/Jul/2023 05:33:44 +0200 Grant Taylor wrote:
> > On 7/12/23 9:26 AM, Wei Chuang wrote:
> >
> >> Being able to reverse mailing-list message modifications to repair the
> >> message and enable digital signature verification, would resolve a
> >> significant roadblock for further DMARC deployment.  Potentially it
> would
> >> allow better attribution of which party contributed which content in
> the
> >> message.  I propose some ideas around reversible mailing-list message
> >> modifications in:
> >>
> https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00.
> These modifications are: 1) prepending a description string to the Subject
> header, 2) rewriting the From header, 3) removing the original
> DKIM-Signature and 4) appending a footer to the message body.  (Apologies
> that -00 draft is still in a rough form)
>
>
> (3) removing the original DKIM-Signature should never be done.  If it's
> removed
> there's no way you can verify it.  MLM often rewrite them, which implies
> they
> won't verify unless computed with the relaxed algorithm.
>
>
> > N.B. I've not read draft-chuang-replay-resistant-arc yet.
>
>
> Me neither.
>
>
> > [...]
> > Old:
> >
> > Subject:  This is a test
> >
> > Change:
> >
> > s/^Subject:\s+\(.*\)$/Subject:  [ietf-dkim] \1/
>
>
> This would change:
>
> Subject: Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D
>
> to:
>
> Subject: [ietf-dkim] Re: [Ietf-dkim] Tolerating Mailing-List Modifications
> I-D
>
>
> > I absolutely agree that regular expressions have problems and may open
> up a can
> > of worms.  I'm mostly using them as a place holder for something, maybe
> a
> > dialect of BNF, to describe the change.
> >
> > I would think that such descriptions of 1) what was changed and 2) how
> the
> > change was made would be more flexible than specifying specific things
> supported.
>
>
> Wei's way to describe the change is probably better implemented by a
> post-transformation filter which has the original message available for
> comparison and can add all the Prior- headers.  That's because MLM often
> do
> change unwittingly, for example, from:
>
> Content-Type: text/plain; charset="us-ascii"
>
> to:
>
> Content-Type: text/plain; charset="utf-8"
>
> which is neither necessary nor documented, AFAIK.  It breaks signatures if
> the
> author domain signs Content-Type:.  I'm not clear where is the culprit.
> Over-signing causes other problems as well.
>
>
> Grant's post arrived to me base64 encoded.  I think that's not how it was
> sent.
>   This kind of transformation is easily reversible.  However,
> reconstructing
> quoted-printable is not feasible.
>
>
> For MIME parts, I recall Murray's draft provided for plain single part,
> mimw
> wrapped and mime added.  I never saw adding footers inside multiple parts.
>
>
Agreed.  For messages likely to undergo Content-Type encoding changes such
as base64, I also suspect the best way to support a reversible footer
addition IMHO is to add a new mime-part footer though this might require
adding multiple/mixed or multipart/related if I understand correctly.


>
> Finally, I think there should be some limitations such as the footer being
> text/plain and not longer than a few lines, and subject tag being no
> longer
> than a couple of words.  That would likely protect the original intent of
> the
> message.
>
>
>
Not sure how to express that fairly.  I figured let the content
analysis/spam filter system figure out if excessively long footers of
subject are problematic.

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

Re: [Ietf-dkim] Tolerating Mailing-List Modifications I-D

[Wei Chuang]

On Wed, Jul 12, 2023 at 8:34 PM Grant Taylor  wrote:

> On 7/12/23 9:26 AM, Wei Chuang wrote:
> > Hi folks,
>
> Hi Wei,
>
> > Being able to reverse mailing-list message modifications to repair
> > the message and enable digital signature verification, would resolve
> > a significant roadblock for further DMARC deployment.  Potentially it
> > would allow better attribution of which party contributed which
> > content in the message.  I propose some ideas around reversible
> > mailing-list message modifications in:
> >
> https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00.
>
> >  These modifications are: 1) prepending a description string to the
> > Subject header, 2) rewriting the From header, 3) removing the
> > original DKIM-Signature and 4) appending a footer to the message
> > body.  (Apologies that -00 draft is still in a rough form)
>
> N.B. I've not read draft-chuang-replay-resistant-arc yet.
>
> I have some questions:
>
> 1)  Why limit the supported modifications to the four listed above?
>
> 2)  What if we turned the problem on it's head and instead of recording
> old values along with the new values, instead we record the new values
> and the permutation used to derive the new values.
>
> Consider:
>
> 2 + 3 = 5
>
> to be:
>
> O + C = N
>
> Instead of recording O and N as headers, what if we recorded C and N?
>
> Would recording the Change method -- dare I say -- regular expression --
> for want of a better example for discussion -- make reverting the change
> simpler?
>
> Old:
>
> Subject:  This is a test
>
> Change:
>
> s/^Subject:\s+\(.*\)$/Subject:  [ietf-dkim] \1/
>
> New:
>
> Subject:  [ietf-dkim] This is a test
>
> I would think that it would be possible to mutate the RE to reverse the
> change.  E.g.:
>
> New:
>
> Subject:  [ietf-dkim] This is a test
>
> Change-Back:
>
> s/^Subject:  [ietf-dkim]  \(.*\)/Subject:  \1/
>
> Original:
>
> Subject:  This is a test
>
> I absolutely agree that regular expressions have problems and may open
> up a can of worms.  I'm mostly using them as a place holder for
> something, maybe a dialect of BNF, to describe the change.
>
> I would think that such descriptions of 1) what was changed and 2) how
> the change was made would be more flexible than specifying specific
> things supported.
>
> I'm going to assume that you have thought of this and have a perfectly
> valid reason to not do it that I'm ignorant of.  If you can, please
> enlighten me as to why such delta descriptions might not work.
>
>
>
Murray proposed something like the regular expression matching approach in
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/.  The
matching pattern is very restricted though- match and remove content within
brackets.  My primary concern is that since a receiver has to also worry
about From header and DKIM-Signature header rewriting, just fold in the
Subject header mechanism to reduce the effort on the mailing-list and
receiver.  The second level concern is being able to scalably support
multiple mailing-lists composing their modifications.  A regular expression
might be able to support this, but likely leaves ambiguity that could cause
interop problems.  Murray seems to hint at a sequence number, but I don't
believe that fully described.

-Wei


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

[Ietf-dkim] Tolerating Mailing-List Modifications I-D

[Wei Chuang]

Hi folks,
Being able to reverse mailing-list message modifications to repair the
message and enable digital signature verification, would resolve a
significant roadblock for further DMARC deployment.  Potentially it would
allow better attribution of which party contributed which content in the
message.  I propose some ideas around reversible mailing-list message
modifications in:
https://datatracker.ietf.org/doc/html/draft-chuang-mailing-list-modifications-00.
These modifications are: 1) prepending a description string to the Subject
header, 2) rewriting the From header, 3) removing the original
DKIM-Signature and 4) appending a footer to the message body.  (Apologies
that -00 draft is still in a rough form)

The idea of tolerating mailing-list modification by applying a reversible
transform has been proposed before such as:
https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
The approach in draft-chuang-mailing-list-modifications is to take a
smaller subset of the mailing-list changes in the transform draft but add
more descriptive detail around the changes.  It also builds on top of ARC
to tolerate multiple mailing-lists and uses
draft-chuang-replay-resistant-arc to provide path authentication.

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

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

[Wei Chuang]

On Mon, Jul 3, 2023 at 10:29 AM Hector Santos  wrote:

>
>
> > On Jul 3, 2023, at 10:06 AM, Barry Leiba 
> wrote:
> >
> >> Anyway, discussing whether spf+dkim verification can mitigate DKIM
> replay
> >> belongs to the ietf-dkim list.  (In case, it could also be expressed
> outside
> >> DMARC, for example by an additional DKIM tag.)
> >
> > I do agree with this, yes.
> >
>
> +1
>
> There may be additional integrated protocol considerations for ESMTP, SPF
> and DKIM that may go beyond what DMARCbis is willing to consider.
>
> —
> HLS
>
>
>
+1

We should consider creating some new authentication method resistant to
replay and forwarding attacks, and update DMARC at some future point to
support that as a 3rd authentication method.   Such a technique should also
be tolerant of forwarding potentially over multiple hops, with message
modification.  In the past, at this point John Levine has said in the past
that why not also ask for a pony too.  Yes, understood, this is a lot.

Potentially we can extend the Replay Resistant ARC draft to act as a
message authenticator for this role.  Yes it's complicated, and yes we need
to see if it will work on actual traffic, hence the ongoing prototyping
work on the DARA concept there.  We welcome consideration of other
approaches or feedback for improving DARA.  In that draft there is an idea
to integrate the validation into ESMTP called SeRCi but some months back
when looking at DARA vs SeRCi, we thought DARA would be less burdensome for
us and others to implement.  Assume for a moment that the DARA
experiment works out.  It's our hope is that the proposed "auth=" tag in
DMARCbis ought to be designed in a way that permits future authentication
methods.

As to supporting "spf+dkim" for the proposed DMARCbis "auth=", and other
potentially other authentication policies, let's consider the needs of
different classes of senders.

   - Sender using dedicated MX that doesn't care about mail forwarding- can
   use default DMARC authentication (DKIM or SPF),  or explicitly specify for
   "auth=spf"
   - Sender using shared MX or cares about supporting forwarding- specify
   "auth=dkim"
  - Potentially such a sender may want to support forwarding with
  message modification when possible.  Propose that "auth" allows an OR'ed
  evaluation between authentication methods, and in this scenario specify
  "auth=dara,dkim".  In this model, a receiver that doesn't understand an
  authentication method is allowed to ignore the requested method.
  - High risk sender subject replay and SPF upgrade attack and wants to
   protect its reputation to ensure deliverability- specify "auth=spf+dkim".
   Such a sender sacrifices forwarding for deliverability.
  -   Potentially the high risk sender might want to also specify DARA
  as another option to support forwarding when possible, and that can be
  specified as "auth=dara,spf+dkim"

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

[Ietf-dkim] Email Authentication Examples document

[Wei Chuang]

Hi folks,
I put together a document (pdf attached) that outlines the current state of
email authentication and then motivates by illustrating how DKIM replay
looks.  I follow up with an example of how the DARA technique that we
propose in I-D draft-chuang-replay-resistant-arc
, looks
like with the replay attack.  If folks think this is useful, I can fold
them into the problem statement document draft-chuang-dkim-replay-problem
.
-Wei


Email Authentication Examples (DKIM WG_dmarc.org).pdf
Description: Adobe PDF document
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

[Ietf-dkim] Update of Replay Resistant Authenticated Receiver Chain

[Wei Chuang]

There is a -06 version of I-D draft-chuang-replay-resistant-arc
 now. The
main two changes in this  version are around "DARA", which is one of two
techniques to fight replay, and now support for DKIM.  Regarding the
latter, the originator may optionally support signing only with
DKIM-Signature to cover the common case direct mail flow pattern.
Regarding the former, draft -06 modifies DARA to support a Chain of Custody
algorithm that further helps fight replay.  I'll send out an examples
document that illustrates both changes in a second post.
-Wei
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Wei Chuang]

On Fri, Mar 24, 2023 at 12:02 PM Hector Santos  wrote:

> +1.
>
> ARC is not a solution, but it is a good part of the problem. It’s not hard
> to see how our fall back to defocusing, the de-emphasis of the DKIM Policy
> Model in lieu of Reputation Modeling creating this issue.
>

ARC compounds the reputation problem because it requires additional
reputation computation as well.  However, it does provide a means to more
precisely describe the forwarding path which is something that DKIM was
meant to support but arguably too broadly wrt DKIM replay.  We can use that
described path to detect replay deterministically (alluded to in the
Problem Statement doc in the "basic solution space").


>
> Every issue we have today is nearly 100% because of the lob-sided efforts
> to impose a DKIM Reputation Model on receivers when it was predicted during
> MARID and into early DKIM that if we do this, we will have issues related
> to the "Batteries Required" Syndrome.
>
> - No standard Reputation Protocol
> - No single repository of GOOD vs BAD domains
> - To be somewhat effective, Batteries Requires (paid 3rd party service)
> - Exploiters attacking those without Batteries.
>
> This is why the original DKIM Charter tried really hard to focus on
> Deterministic Protocols rather than Heuristic Protocols based on the Author
> Domain. The original DKIM Charter considered “Reputation Modeling” out of
> scope.
>
> Now it is in scope and we are dealing with issues that can not be solved —
> not without addressing the DKIM Policy Model for 1st and 3rd party signers.
>
> If the group effort is to be able to write a PS for DKIM + Reputation
> Modeling, we should highly note it was all perpetuated by our defocus of
> DKIM Policy Modeling and the lack of will to fix DMARC.
>

I agree with the split between deterministic protocol vs reputation
systems.  I think there's space to make progress on the
deterministic protocol side by authenticating forwarded email more
accurately.

While I suspect this is well out of scope for this WG, FWIW I do agree
there ought to be work done on the reputation side too.  Yes there are a
lot of heuristics there that will resist standardization, but perhaps
there's room to make improvements for initialization.
-Wei


>
>
> —
> HLS
>
> On Mar 24, 2023, at 1:42 PM, Michael Thomas  wrote:
>
>
> On 3/24/23 10:22 AM, Murray S. Kucherawy wrote:
>
>
>
> Fine with me, it's far from a showstopper overall.  I just made the
> suggestion.
>
> This wg should be concerned with DKIM problems, not other wg problems and
> especially for experimental rfc's of dubious value and complete mysteries
> as to what they have to do with their actual charter.
>
> Mike
> ___
> 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
>


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

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Wei Chuang]

A -03 draft is available at
https://www.ietf.org/archive/id/draft-chuang-dkim-replay-problem-03.html.

On Sat, Mar 25, 2023 at 3:18 AM Laura Atkins 
wrote:

>
>
> On 24 Mar 2023, at 16:38, Murray S. Kucherawy  wrote:
>
> Informal comments only here.  I know a merger with Dave's draft is in
> progress, so some of these may not apply by the time you're done.
>
> Section 1.1:
>
> It feels a little presumptuous to assume any DKIM receiver has also built
> out a reputation system, or has access to one.  I guess it might depend on
> what you consider a reputation system though; are there DNSxLs for DKIM
> domains that are open to the public?  I don't think SpamAssassin carries
> with it a set of domains that should be dropped if they carry valid DKIM
> signatures.  Either way, I think the generalization is peculiar.  At a
> minimum, say "some systems develop reputations" etc.
>
>
> Almost all major filtering systems (public, commercial and private) have
> some sort of reputation engine in them and I’m pretty comfortable talking
> about it. However, your point is well taken. I don’t think, too, that the
> domain is the reputation, DKIM is really about identity. So, what if we
> change the language from “reputation” to “Identity”
>
> Reputation is the idea that a filtering system can make an informed
> judgment about whether a particular email is wanted or unwanted based on
> the previous history of mail with a similar identity. What DKIM (and other
> authentication methods) gives us is a durable and verifiable domain
> identity to anchor the reputation. The DKIM replay attack vector is taking
> advantage of that identity by, essentially, stealing the reputation of a
> known good domain.
>
> Maybe we don’t  need to mention reputation at all, even. Can we add
> something like this to section 1.1 in the edited document:
>
> DKIM authentication allows domains to create a durable identity to attach
> to email. Since its initial proposal it has been widely deployed by systems
> sending and receiving email. Receiving services use the DKIM identity as
> part of their inbound mail handling, and make delivery decisions based on
> the DKIM domain. Email sending services sign customer email with the
> customer’s own domain, but many also sign with their own domain.
>

Added.


>
>
> I think I concur with the suggestion that wa should drop discussion of
> ARC.  This WG, or the DMARC WG, can develop an update to ARC based on the
> outcome here if the community chooses to do so, but I don't think it should
> be part of this WG's premise.
>
>
> Agreed.
>

I believe there's some value in mentioning the susceptibility of ARC to the
same type of attack.  I've dropped the reference to DMARC.


>
>
> Section 1.2:
>
> The opening sentence that emphasizes non-use of RFC 2119, amusingly,
> forces you to include a reference to RFC 2119.  I suggest instead: "This
> document is not normative in any way."
>
> "administratively" should be "administrative functions" or similar.
> ("users" and "services" are nouns, so this should be too.)S
>
> The "List-*" header fields are defined in RFC 4021.
>
> In "trace and operational headers", "headers" should be "header fields".
>
> Are we actually defining new Mail Handling Services here, or rather
> declaring special cases of Originators and Relays?  Do they become Authors
> again after they've handled/filtered a message?
>
> Are we sure SPF and DMARC should be in scope for this work?  SPF feels
> irrelevant, and DMARC feels like a layer violation.  If we want to do so,
> we could refer the reader to the RFCs defining those protocols just to make
> them aware of the bits of the ecosystem, but then I would leave them out of
> the rest of the document.
>
>
> I don’t think either should be in scope, honestly. They may end up being
> part of the solution space, but the issue here is the DKIM domain.
>

The belief was that there's value in describing how DKIM and SPF are used
together in email authentication, and in any case the mentions of SPF have
been reduced.  I propose the -03 draft keeping what's there now to see if
it is helpful.  If not, I can remove all mentions.


>
> Section 2:
>
> "headers" should be "header fields"
>
> "customized by" the ultimate recipient?  or should that be "for"?
>
> Involvement of SPF here doesn't seem to be needed either.  We only need to
> tall the DKIM story.
> I think the notion of folders also exceeds DKIM's scope.  That's a
> handling choice post-DKIM.  It's enough to highlight that a false positive
> is procured by the attacker, to the attacker's benefit.
>
>
> +1
>
> Section 3:
>
> Does including SPF in this part of the discussion contribute to the
> problem statement or muddy it?  This is about DKIM, not about spam handling
> in general.
>
>
> I think it muddies it, honestly.
>
> Section 3.1's "DKIM" bullet talks about signature survival, while Section
> 3.2's "DKIM" bullet talks about who does the signing.  This seems
> dissonant, or at least makes them hard to

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

[Wei Chuang]

On Fri, Mar 24, 2023 at 9:38 AM Murray S. Kucherawy 
wrote:

> Informal comments only here.  I know a merger with Dave's draft is in
> progress, so some of these may not apply by the time you're done.
>
> Section 1.1:
>
> It feels a little presumptuous to assume any DKIM receiver has also built
> out a reputation system, or has access to one.  I guess it might depend on
> what you consider a reputation system though; are there DNSxLs for DKIM
> domains that are open to the public?  I don't think SpamAssassin carries
> with it a set of domains that should be dropped if they carry valid DKIM
> signatures.  Either way, I think the generalization is peculiar.  At a
> minimum, say "some systems develop reputations" etc.
>

The problem statement document assumes use of DKIM and reputation systems
for delivery decisions.  I've clarified the claim to take both into
account.


>
> I think I concur with the suggestion that wa should drop discussion of
> ARC.  This WG, or the DMARC WG, can develop an update to ARC based on the
> outcome here if the community chooses to do so, but I don't think it should
> be part of this WG's premise.
>

The claim here is that ARC is vulnerable to replay the same way as DKIM,
noting that ARC is based on DKIM.  The problem statement document doesn't
attempt to do anything further with ARC in the rest of the document.


> Section 1.2:
>
> The opening sentence that emphasizes non-use of RFC 2119, amusingly,
> forces you to include a reference to RFC 2119.  I suggest instead: "This
> document is not normative in any way."
>

Yeah sorry about that.  That's been fixed.


> "administratively" should be "administrative functions" or similar.
> ("users" and "services" are nouns, so this should be too.)
>

I've more explicitly called out that they may have different ADMDs.


> The "List-*" header fields are defined in RFC 4021.
>

Added


>
> In "trace and operational headers", "headers" should be "header fields".
>

Merged version has this.


> Are we actually defining new Mail Handling Services here, or rather
> declaring special cases of Originators and Relays?  Do they become Authors
> again after they've handled/filtered a message?
>

Most are already defined in RFC5598.  This document goes onto refining
Boundary Filter into Inbound and Outbound Filtering Services, and
describing a ESP.


> Are we sure SPF and DMARC should be in scope for this work?  SPF feels
> irrelevant, and DMARC feels like a layer violation.  If we want to do so,
> we could refer the reader to the RFCs defining those protocols just to make
> them aware of the bits of the ecosystem, but then I would leave them out of
> the rest of the document.
>

SPF is noted as an aid to detection of DKIM replay.  DMARC is mentioned to
explain ARC, but we can drop the mention of DMARC.


> Section 2:
>
> "headers" should be "header fields"
>

Done


>
> "customized by" the ultimate recipient?  or should that be "for"?
>

That language has been dropped.


> Involvement of SPF here doesn't seem to be needed either.  We only need to
> tall the DKIM story.
> I think the notion of folders also exceeds DKIM's scope.  That's a
> handling choice post-DKIM.  It's enough to highlight that a false positive
> is procured by the attacker, to the attacker's benefit.
>
> Section 3:
>
> Does including SPF in this part of the discussion contribute to the
> problem statement or muddy it?  This is about DKIM, not about spam handling
> in general.
>
> Section 3.1's "DKIM" bullet talks about signature survival, while Section
> 3.2's "DKIM" bullet talks about who does the signing.  This seems
> dissonant, or at least makes them hard to compare and contrast since they
> talk about different things.
>

This section has been broadly rewritten to take out the bulleted points
that were confusing.


>
> Section 4:
>
> Caching known signatures, a con: adds a potentially expensive database
> component to the receiving service, and will require tinkering to figure
> out what cache duration is appropriate to catch replays while not also
> catching legitimate mail.
>

Added

The "sign for the next hop" proposal could use a language tweak of some
> kind.  I can't quite put my finger on it.  If it's "sign for the next hop"
> at a host level, I have to know that host; today, I just sign and toss it
> in the queue, and my MTA figures out which MX is going to take it, but if I
> have to know which MX that is, I can't sign until connection time;
> milter-based filters at least don't work that way because the integration
> point doesn't allow it.  If it's actually "sign for the next ADMD", that
> problem goes away, but the definition of "ADMD" gets a bit muddy because
> now you have to include in that definition any MX that might be providing
> transparent store-and-forward.
>

Yes it's apt to say sign the name of the intended next ADMD.  Added
hopefully clarifying language.


>
> Section 5 you won't need.
>

Removed


>
> Section 6 can simply say there are no security co

Re: [Ietf-dkim] Problem statement adoption

[Wei Chuang]

+1 I'm working on it.

-wei

On Fri, Mar 24, 2023, 6:45 AM Dave Crocker  wrote:

> On 3/24/2023 6:42 AM, Laura Atkins wrote:
> > We currently have two problem statements to discuss for adoption.
>
> Wei is merging 'mine' into his.  (Note mine was done as a variant of his.)
>
> I believe there will again be only one draft.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

Re: [Ietf-dkim] Welcome to the rechartered working group

[Wei Chuang]

On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins  wrote:

> ...
> One of the panel members has shared the following from what he said at the
> session:
>
> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
> * There may only be a best practices solution, and not a protocol solution.
> * DKIM has since the beginning kept itself completely separate from the
> message transport.  Several of the proposed solutions (including mine) take
> leaps of varying sizes into the realm of DKIM knowing something about the
> transport; the lightweight ones connect the message to the envelope
> somehow, and the more heavyweight ones mean DKIM filters have to learn
> about MXes and whatnot.  We have to be absolutely certain that we want to
> break that wall if we go this way, because once we do, there will be no
> turning back.
>

Agreed for the most part.  While we can get mileage with the existing
RFC6376 based tools such as header oversigning, "x=" expiry, and the other
techniques mentioned, at some point the spammers will adapt.  And as
Michael and the panelist have pointed out, RFC6376 inherently permits DKIM
replay as a feature due to that separation between envelope and message.
The main thing I would quibble with the panelist is the distinct break if
we start validating parts of the envelope or interacting with transport, as
whatever technique to be adopted will have to consider participation by
unaware forwarders i.e. some sort of gradual adoption process likely with
some sort of experiment.  Also I would argue we should break that wall
between the message and the envelope and transport.  From where I sit, I
see mail forwarding bit by bit breaking as spammers use forwarding as a
general technique, and the mitigations put in place using the existing
protocols are insufficient for the challenge.  The evidence is anecdotal
since there aren't great tools to look at this at scale.

-Wei


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

Re: [Ietf-dkim] Welcome to the rechartered working group

[Wei Chuang]

I was one of the M3AAWG 57 SF DKIM replay session organizers that helped
put together the slides, so I can try to summarize some of the things in
the slides.  (I was hit with Covid so couldn't attend in person)  M3AAWG
has a confidentiality policy to permit greater knowledge sharing among
participants so I will be sensitive and respectful of those concerns.  So I
apologize if I leave something out, but it might be because something was
indeed sensitive or I suspect it is, and of course I missed the actual
session, so don't know what was said in person.  The following is a high
level outline of the slides/talk:

   - Introduction and description of DKIM replay noting the False-Negative
   and False Positive effects on reputation systems
   - Description of DKIM Replay detection techniques and effects observed
   by senders and receivers
   - Summary of existing DKIM replay mitigations based on tools available
   in RFC6376
   - DKIM development history wrt DKIM Replay
   - M3AAWG 56 Brooklyn BoF / IETF 115 Dispatch proposals
  - Recipient in the signature proposals/drafts
  - Gather per-hop signatures proposals/drafts
  - Problem statement draft

The session reuses some of the IETF 115 Dispatch DKIM Replay slides i.e.
the introduction and proposals, meaning you can find the content there.

Some interesting points:

   - Several senders described using Gmail Postmaster Tools for detection
   of DKIM replay
  - to look for changes to reputation, user reported spam, and volume
   - Summary of existing DKIM replay mitigations based on tools available
   in RFC6376
  - DKIM header oversigning.  Some discussion on which headers.
  - DKIM timestamp and expiry.  Discussion of expiry durations.
  - Signature counting.  Acknowledged False Positives which needs
  support to mitigate, but the claim is DKIM replay isn't a
problem for that
  receiver i.e. highly successful.
  - Key rotation
   - DKIM replay was considered during development of RFC- hence the "x="
   tag
   - Advice for DKIM WG success?  To encourage folks to participate in the
   mailing list discussion

thanks,
-Wei

On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins  wrote:

> All
>
> The DKIM working group is now active again (thanks Murray!).  The chairs
> wanted to send out a short note to welcome everyone and talk about our next
> steps.
>
> Our first deadline is next month - to get a consensus problem statement
> submitted on the IETF data tracker at
> https://datatracker.ietf.org/group/dkim/
>
> There is a current problem statement at
> https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/.
> Please take a moment to read through it and provide feedback. This chair
> thinks we should not be providing solutions in the problem statement. We
> should be primarily describing what the issue is and why we think the issue
> is with the protocol. We will deal with solutions in the actual document.
>
> There was also a DKIM replay session at the most recent M3AAWG meeting. As
> I understand it, they’re working on a BCP in parallel with the IETF. Many
> folks are active in both groups.
>
> Due to M3AAWG privacy requirements, we are constrained in what we can
> share from the meeting itself. However, if you were here and were on the
> panel or part of the discussions, feel free to share with us some of your
> thoughts on the problem, possible solutions and what your organizations
> have done to address the issue.
>
> One of the panel members has shared the following from what he said at the
> session:
>
> * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay.
> * There may only be a best practices solution, and not a protocol solution.
> * DKIM has since the beginning kept itself completely separate from the
> message transport.  Several of the proposed solutions (including mine) take
> leaps of varying sizes into the realm of DKIM knowing something about the
> transport; the lightweight ones connect the message to the envelope
> somehow, and the more heavyweight ones mean DKIM filters have to learn
> about MXes and whatnot.  We have to be absolutely certain that we want to
> break that wall if we go this way, because once we do, there will be no
> turning back.
>
> There was also a DKIM replay session at the most recent M3AAWG meeting. As
> I understand it, they’re working on a BCP in parallel with the IETF. Many
> folks are active in both groups.
>
> Due to M3AAWG privacy requirements, we are constrained in what we can
> share from the meeting itself. However, if you were here and were on the
> panel or part of the discussions, feel free to share with us some of your
> thoughts on the problem, possible solutions and what your organizations
> have done to address the issue.
>
> We will not meet in Yokohama due to the timing of being rechartered, but
> we are considering a one hour interim in April if there appears to be
> points of discussion.
>
> laura (as chair)
>
> --
> The Delivery Expert

Re: [Ietf-dkim] Fwd: New Version Notification for draft-crocker-dkim-replay-00.txt

[Wei Chuang]

Sorry for the delay.  Top level, I agree that this draft tightens up the
details in a beneficial way, and the working group ought to work off the
crocker version.  I'm happy to also merge this version in my
problem-statement draft also.

My interpretation of the changes, is that the crocker draft removes one of
the redundant DKIM replay definitions found in the introduction.  It also
tightens up the language with respect to RFC5598 and reorders the glossary
section.  There's a new section "Replay technical characteristics" which is
gives our current understanding of what a replayed message would look
like.

On Thu, Mar 9, 2023 at 7:20 AM Dave Crocker  wrote:

> On 3/9/2023 7:04 AM, Tim Wicinski wrote:
>
> it would be useful to the working group if the authors
> could perhaps summarize the differences between them.
>
> As I noted, mine is a revision of Wei's.  (And I have been among the
> contributors to his, for some months.) If adopted, the author list needs to
> reflect that, really, it's the work of that set of authors.
>
> My goal was to tighten the focus, as well as to reduce the tutorial
> content.  It still has a fair amount of foundational introduction, since
> many people don't know all the terms or use them differentially.
>
> For a long time, I'd thought that references to SPF should be removed,
> since this is about DKIM.  As the text on detection of replay developed,
> I've been swayed that limited reference to SPF can be helpful.  But I
> removed reference to DMARC, since I think it adds nothing to detection.
>

I'm good removing DMARC .  Glad you kept the SPF description, and put in
clarifications on why SPF is important in the context of DKIM replay.


> The discussion of possible prevention/mitigation is isolated to the last,
> brief section.  Given that the document is likely to get wide distribution,
> I think it might be helpful to have a small amount of discussion that
> emphasizes that this topic will not be amenable to trivial solution.
>

Also glad that it was kept, as I agree, I think it's important for readers
to understand broad outlines of some of the existing ideas and their issues.
-Wei


> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.netmast:@dcrocker@mastodon.social
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

Re: [Ietf-dkim] Setting a stage for detection

[Wei Chuang]

On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker  wrote:

> Folks,
>
> There appears to be no perfect way to distinguish a Replay attack from a
> legitimate re-posting by an Alias or even a Mailing list (that preserves
> the original DKIM signature.)
>
> The only 'signal' that is valid, also is ambiguous.  The signal is that
> the rfc5321.Mail command has an address that is not in any of the
> rfc5322 address fields.   The ambiguity, of course, is that that's also
> true for Alias.
>
> I'm wondering about designing some assistance by the author's platform
> and the Aliasing platform, to flag what they've done.
>
> Imagine adding a header field like "Separate-Envelope:", possibly
> listing the domain name of the site putting the flag there, and having
> them add a DKIM signature to cover it and the rest of the message.


> This could also be done by a spammer doing Replay, of course. But the
> point is that this added mechanism now creates a noise-free basis for
> evaluating this class of traffic associated with that signed domain.
>

Agreed that reputation systems can play a role when the spammer decides to
participate.

It's not that the receiving filter could not detect the disparity
> between envelope and content addresses. It's that the receiver is
> getting a flag from whomever did it.
>
> If, for example, the domain name is of the originating service, then
> it's clearly not Replay.
>
> If it is from an Aliasing site, the receiver can quickly build up a
> reputation for that site, to aid in determining replay or not.
>
> Thoughts?
>

In this model, let's consider the Receiver's actions.
1. Say the spammer doesn't want to participate in creating a
Separate-Envelope, how would a receiver detect this as Replay?  Is the idea
that Separate-Envelope identifies the Alias or Mailing-lIst?  Is the
verification process that the Receiver notices that the header is missing?
2. You've noted what happens when the spammer participates in generating
Separate-Envelope
3. A non-spammer should have a Separate-Envelope, which will validate.

FWIW a different approach but overlaps this idea is that a sender
identifies the domain they intend to send to.  The receiving system
verifies that they are the intended recipient domain.  I think John Levine
has a draft about this.  I have a draft that expands some of that idea
further.

-Wei


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


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

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

[Wei Chuang]

Consolidating the new points raised and my replies:

On Fri, Feb 10, 2023 Michael Thomas  wrote:

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

Many MBP have outbound and inbound spam filters.  Many domains also use
third party Outbound Filtering Services and Inbound Filtering Services as
mentioned in the Problem Statement draft.

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

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

There will alway be this tension between what is proprietary and what can
be shared so that we collectively work on the problem.  Perhaps the way to
break the impasse is to say let's move away from reputation systems as they
are inherently non-deterministic to some deterministic solution for DKIM
replay.  As an example, a couple of the proposals work on signing MAIL FROM
recipients and verifying the actual recipient against the signed
recipients.   The computed will be consistent when evaluated at different
times unlike reputation systems.

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

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

Fair enough.  Yes that applies there too.

The other two points are observations which I think I largely agree with.

-Wei



On Sat, Feb 11, 2023 at 2:40 PM Michael Thomas  wrote:

>
> On 2/10/23 9:36 PM, Murray S. Kucherawy wrote:
>
> On Fri, Feb 10, 2023 at 12:06 PM Evan Burke  40mailchimp@dmarc.ietf.org> wrote:
>
>>
>> On Fri, Feb 10, 2023 at 11:47 AM Dave Crocker  wrote:
>>
>>> On 2/10/2023 11:35 AM, Wei Chuang wrote:
>>> > ARC is a tool to help support modern Indirect Mail Flows, and I
>>> > believe belongs in the solution space to be explored.
>>>
>>> Since ARC uses the same technology as DKIM and uses it in pretty much
>>> the same was, my understanding is that it, too, has the potential for
>>> replay.  Having a reference to this fact makes sense to me.
>>>
>>> It doesn't need more than a mention, at this point, I believe, which
>>> makes the current quick, reference exactly the right text, IMO.
>>>
>>
>> +1
>>
>> I realize there are some mixed opinions on ARC, but it's actively used on
>> several of the world's largest email systems - some of the same ones where
>> DKIM replay attacks are focused - so it's worth consideration as part of
>> the solution space. It may not end up being a viable option, but now isn't
>> the time to write it off.
>>
>
> Speaking only as a participant:
>
> I also don't think a comment like "ARC has the same problem, for largely
> the same reasons" is by itself harmful here.
>
> What I think we should be sure to avoid is expending WG energy trying to
> solve this problem in ARC-space.  That, I would argue, is outside the
> charter.
>
> I see that they took out a lot of other mentions in this rev, but I have a
> real problem with editorializing that ARC does this or ARC does that which
> is to say the least, controversial. It's really not germane to this wg and
> imo the easiest thing to do is nothing at all wrt ARC.
>
> Mike
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

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

[Wei Chuang]

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

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

-Wei


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


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

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

[Wei Chuang]

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

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

 -Wei

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


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

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

[Wei Chuang]

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

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

-Wei


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


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

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

[Wei Chuang]

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

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

-Wei

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


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

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

[Wei Chuang]

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

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

-Wei

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


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

Re: [Ietf-dkim] Lars Eggert's Block on charter-ietf-dkim-04-05: (with BLOCK and COMMENT)

[Wei Chuang]

On Tue, Jan 31, 2023 at 7:23 PM Murray S. Kucherawy 
wrote:

> On Tue, Jan 31, 2023 at 2:12 PM Michael Thomas  wrote:
>
>> Also: the date on the problem statement seems awfully aggressive. My
>> thinking is that the problem statement should at least discuss (as is
>> mentioned in the charter) how "replays" are completely legitimate uses
>> of DKIM, and thus limit the solution space to not break those uses.
>>
>
> Milestones are negotiable, and the one(s) I used for this are largely dart
> throws.  We can change them to be something more practical once chairs have
> been secured.
>

We can move up discussing the problem statement document if it hinders
chartering.  I've been working on that document and can push out a new
draft soon.
-Wei


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


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

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Thu, Jan 5, 2023 at 10:43 AM Dave Crocker  wrote:

> On 1/5/2023 9:20 AM, Alessandro Vesely wrote:
> > I wouldn't call "replay-resistant DKIM enhancement(s)" the
> > deliverable.  I understand the WG name is DKIM, but two of the
> > proposed drafts don't even mention it.  We may call ARC a "kind of
> > DKIM", but a solution based on it would be better called an ARC
> > enhancement, no?
> >
> > How about "replay-resistant protocol"?
>
> Just to explore this a bit further:
>
> 1. The motivation for the current effort has been exploitation of
> re-posting to exploit a DKIM reputation.
>
> 2. Are there any other kinds of replay scenarios that are an issue now?
> I suspect there aren't.
>

While not exactly ARC replay, we've seen recently that spammers are
exploring munging the ARC headers.  One campaign had them swapping a
complete ARC header set into another message.  In another they added an
incomplete set.  Consequently we're worried about the spammers exploiting
ARC vulnerabilities.

-Wei


> 3. Whatever mechanisms are developed to prevent or mitigate replay,
> their current use will be to deal with a DKIM-related replay problem.
>
> It's likely to be useful for the working group name to relate to a
> specific, real and current problem, even if a technical solution doesn't
> explicitly deal with the technical details of that problem.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Thu, Jan 5, 2023 at 10:06 AM Michael Thomas  wrote:

>
> On 1/5/23 9:20 AM, Alessandro Vesely wrote:
> > On Thu 05/Jan/2023 17:33:36 +0100 Murray S. Kucherawy wrote:
> >> I've added a few proposed milestones with dates
> >
> > I wouldn't call "replay-resistant DKIM enhancement(s)" the
> > deliverable.  I understand the WG name is DKIM, but two of the
> > proposed drafts don't even mention it.  We may call ARC a "kind of
> > DKIM", but a solution based on it would be better called an ARC
> > enhancement, no?
> >
> > How about "replay-resistant protocol"?
> >
> Sorry, ARC is a failed experiment that doesn't deliver what it was
> supposed to deliver.


I disagree that it's a failed experiment.  We're using ARC results for
forwarders who choose to generate them.


> The DKIM wg should have no part of it. It should be
> completely out of scope.
>

I agree with Alessandro's proposed language change that allows for ARC.
Moreover ARC is subject to the same replay issue as DKIM and needs some
sort of fix.

-Wei


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


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

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Tue, Jan 3, 2023 at 1:38 PM Todd Herr  wrote:

> On Tue, Jan 3, 2023 at 4:04 PM Michael Thomas  wrote:
>
>> Yet another reason why I'm skeptical. If there were a viable protocol
>> solution to this, why hasn't M3AAWG found it? Why re-spin up a working
>> group with a what appears to be a greenfield solution space if an active
>> industry working group hasn't chimed in? If there were some viable protocol
>> solution, I would expect they would at least put it forward. Working groups
>> are infinitely more productive if there is some collective agreement about
>> the general parameters of a solution, even if the particulars need to be
>> vetted. The couple of solutions I've seen thus far are either trivially
>> breakable (= striping signatures at MDA's), or frightening to contemplate
>> what they'd break (= tying envelope to message). That doesn't give me the
>> warm fuzzies about any protocol level solution.
>>
>> Also: if they are indeed working on a BCP, it would be far better to use
>> that as input rather than reinventing wheels.
>>
> While I wouldn't presume to speak for M3AAWG, and although some M3AAWG
> work products have been used as inputs to the IETF process (such as RFC
> 6449, to cite but one example), and although there are many people that are
> active both in M3AAWG and the IETF, it's my sense that M3AAWG doesn't see
> itself as a body that proposes changes to existing protocols. Rather, I've
> always seen M3AAWG as an organization that primarily figures out the best
> way to make use of existing protocols and publishes documents describing
> those best uses in the fight against messaging and other abuse.
>
> I'm not at liberty to speak about the content of current M3AAWG work on
> the topic of DKIM replay attacks or what direction that work has taken, but
> everything I've seen so far has been recommendations to do things already
> permitted by the protocols in existence, recommendations that have almost
> certainly been implemented by a number of M3AAWG member companies. Those
> recommendations are not bulletproof, however, and so people have come here
> to see if there might be a forum for defining updates to the DKIM protocol
> that might make it more resistant to replay attacks.
>

+1

So yes this was discussed and started at a M3AAWG BoF (at M3AAWG 56 in Oct
2022) that discussed DKIM replay.  As by that point there were several
drafts with proposed solutions, the suggestion from feedback at the BoF was
to send this work to IETF Dispatch.  This work was presented at IETF 115
(Nov 2022) and the Dispatch slides

are largely derived from the BoF slides i.e. summarized to fit in Dispatch
time limit.  The set of drafts mentioned at the BoF and Dispatch, are cited
in the proposed DKIM WG charter
.

-Wei


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

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Sat, Dec 31, 2022 at 4:18 PM Michael Thomas  wrote:

>
> On 12/31/22 2:37 PM, Murray S. Kucherawy wrote:
>
> On Sat, Dec 31, 2022 at 1:09 PM Michael Thomas  wrote:
>
>>
>> On 12/29/22 7:20 PM, Murray S. Kucherawy wrote:
>>
>> On Sun, Dec 25, 2022 at 4:14 PM Michael Thomas  wrote:
>>
>>>
>>>
>>> Done, and thanks for that text.
>>>
>>> One nit, Barry's text should be above the proposals not below. It makes
>>> it look like those are the only proposals on the table which I'm nearly
>>> certain is not your intent.
>>>
>> One other thing though, should there be some bounds on what appears to be
>>> the possibility of writing a BCP like document? I mean, I can think of some
>>> things that could help mitigate this but they are pretty wonky and
>>> definitely untested. Do we actually have that operational experience to
>>> recommend anything?
>>>
>>
>> The charter as-is is now up for IESG Evaluation and one AD has already
>> commented on it, so I'm going to hold any edits until after the next
>> telechat (on January 5th) so as not to give them a moving target.  After
>> that I'll apply this and any other feedback.
>>
>> That's fine, but we can talk about it in the mean time, right? I'm not
>> suggesting a specific change on the BCP part because I'm not exactly sure
>> what we should do. I know that it seems "obvious" but it also seems to me
>> that we could get out in the weeds really easy and recommend stuff that we
>> probably shouldn't. That's what I'm struggling with respect to "bounds".
>> I'm not sure that we have the operational knowledge -- or more likely
>> operational knowledge that can be shared -- to recommend something?
>>
> I expect that one of two things will happen: (1) We will attract a
> sufficiently broad set of contributors that whatever consensus they come up
> with will be defensible because it collectively has the operational
> knowledge and expertise to make appropriate BCP-style recommendations to
> the industry, or (2) we will not, and we'll know it, and thus we'll know we
> can't produce defensible advice suitable for publication.
>
> Maybe we can put the same constraint on this as we do for protocol work
> going forward as in having a step which determines whether there is a 1)
> plausible route forward or not and 2) whether it's really within the scope
> of what IETF can recommend. Sort of the same A/B switch.
>
> Mike
>
I'm worried about duplicating work unnecessarily as the M3AAWG has an email
authentication BCP.  If the WG to-be indeed does want to generate the BCP,
perhaps the M3AAWG document can be the basis for an IETF document assuming
M3AAWG is okay with that, or the WG can partner with M3AAWG to produce a
common document.  I think both are possible as there's a fair amount of
people overlapping between the IETF and M3AAWG, and I know that M3AAWG
organizationally wants to help here.

That said, I think a BCP around the existing email authentication standards
can only provide workarounds that can be bypassed by spammers i.e. new
standards are needed to properly mitigate the current risk.
-Wei

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


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

Re: [Ietf-dkim] Rechartering

[Wei Chuang]

On Sun, Nov 27, 2022 at 9:34 PM Scott Kitterman 
wrote:

> On Sunday, November 27, 2022 9:30:49 PM EST Murray S. Kucherawy wrote:
> > Hi folks,
> >
> > Area Director hat on here:
> >
> > The discussion Barry kicked off has been interesting, but it has strayed
> > (and mea culpa, in part, because the material is interesting) from the
> work
> > of discussing a charter.
> >
> > I've set the stage for re-chartering in the system, and now we need some
> > charter text.  Dave and Barry submitted text, which I've synthesized into
> > what's below.  Let's keep this thread just to discussion the charter
> text;
> > if you want to continue to debate the technical solutions or problem
> space,
> > please start other threads or reply to the other existing ones.
> >
> > Here's my run at a charter; please provide suggestions or comments, or
> tell
> > us if you think it's ready to go.  It's a variant of Barry's version with
> > parts of Dave's merged in.  I've kept the list of candidate documents as
> a
> > starting point; the WG doesn't actually have to use any of them if that's
> > where consensus lands.
> >
> > But let's figure out consensus on a charter before we try to hammer out
> > consensus on solutions.
> >
> > -MSK
> >
> > --
> >
> > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for
> > using a digital signature to associate a domain identity with an email
> > message in a secure way, and to assure receiving domains that the message
> > has
> > not been altered since the signature was created.  Receiving systems
> > can use this information as part of their message-handling decision.
> > This can help reduce spam, phishing, and other unwanted or malicious
> > email.
> >
> > A DKIM-signed message can be re-posted, to a different set of recipients,
> > without
> > disturbing the signature's validity.  This can be used to confound the
> > engines that
> > identify abusive content.  RFC 6376 identified a risk of these "replay"
> > attacks, but
> > at the time did not consider this to be a problem in need of a solution.
> > Recently,
> > the community has decided that it has become enough of a problem to
> warrant
> > being revisited.
> >
> > The DKIM working group will produce one or more technical specifications
> > that
> > describe the abuse and propose replay-resistant mechanisms that are
> > compatible
> > with DKIM's broad deployment.  The working group may produce documents
> > describing
> > relevant experimental trials first.
> >
> > 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 may adopt or ignore these as it sees fit.
>
> I would add mention of the problem statement draft.  I think it may turn
> out
> to be the most important of the ones we have now.


+1 (granted my partiality).  Hopefully it can provide helpful context and
framing device.


> I still think "compatible with DKIM's broad deployment" is too narrow.
> Also,
> I think it's one reasonable conclusion the group might reach is that the
> cure
> is worse than the disease and a resolution along the lines of "remove
> signatures during delivery" and "be more careful about what you sign
> because
> signing bad things will hurt your domain's reputation" may be the most
> appropriate approach.


> How about instead of "The DKIM working group will produce one or more
> technical specifications that describe the abuse and propose
> replay-resistant
> mechanisms that are compatible with DKIM's broad deployment" we say "The
> DKIM
> working group will evaluate potential mechanisms to mitigate this attack
> and
> produce one or more technical specifications that describe the abuse and
> propose improvements which, consistent with compatibility with DKIM's
> broad
> deployment and general email protocols, will reduce the impact of replay
> attacks".
>
>
On this I'm more with the MSK version, that we ought to create a
specification.  To me at least, the problem with DKIM replay is that it is
indistinguishable to a receiver from other benign forwarding flows.  I
believe the proposed drafts help us do this though different approaches.

-Wei


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

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

[Wei Chuang]

On Sat, Nov 26, 2022 at 8:36 AM Dave Crocker  wrote:

> On 11/25/2022 2:26 AM, Laura Atkins wrote:
> > What’s stopping large providers from removing DKIM now if they wanted to?
>
> Nothing at all.  That they can choose to, if they wish, is one of the
> appealing aspects to this.  It permits unilateral adoption.
>

Recapping what I believe I saw in the above thread- the idea is to strip
the DKIM header in the message view seen from the inbox.  This is an
interesting idea, but as pointed out elsewhere, it's pretty easy for the
spammers to bypass, as they simply need an MX they control.  Alternatively
any mailbox provider with access to the message w/o stripping the DKIM
header.


> > Or have they actually made the choice to keep the signatures in?
>
> No idea.  And yes, it would be good to ask them.  I wonder what venue
> there might be to float such a question...?
>
> (time-passing jingle plays...)  Venue found.  So now let's see how they
> respond...
>
>
As one of the instigators of the DKIM replay WG proposal at Dispatch,
apologies for the delay.  For the last several years, we've noticed an
uptick in spam attacks around this time of year, and this year is no
different.  Last year the spammers were exploiting DKIM replay.  This year,
they are exploiting the SPF's vulnerability to multi-tenancy to obscure
spam traffic though a vulnerable forwarder.  Things had to calm down a bit,
before getting back to this thread.  In any case I also bring up the SPF
issue to point out there are other authentication challenges, and to be
mindful of supporting mitigating them as well.  (My intuition keeps coming
back to the idea that can make progress here if we could distinguish these
different traffic flows)

-Wei


>
> > If they have made that choice, do we know why? If they haven’t made
> > the choice, how complicated will it be to change the inbound MTA to
> > strip headers?
>
> To quibble, I'd hope it is some form of MDA, so the step is part of
> delivery and not relaying.
>
>
> > Will this have knockon effects for their internal systems? Is there a
> > risk that stripping the DKIM header will cause authentication failures
> > if the messages are forwarded internally or externally? (I’m reminded
> > of the time Microsoft changed some internal systems around and ended
> > up having everything fail SPF because they were picking the wrong IP
> > out of their mess of headers to do SPF authentication with).
>
> The essence of the questions you ask is to press for serious due
> diligence among a range of sizeable email receiving platforms. That is
> certainly an useful step before having the working group assert the
> recommendation to remove the signature.
>
>
> > And, I think most importantly: will this recommendation by the IETF
> > have any impact whatsoever on the groups currently using DKIM replay
> > as a way to get past (some) filters?
>
> There are never any guarantees about adoption.   Once upon a time, the
> IETF made some effort to get an indication of industry interest in
> adoption.
>
> These days, not so much.  Personally, I think that checking for adoption
> interest is another kind of due diligence that ought to be required.
>
>
> > I don’t see how it will, most of them are using their own email
> > addresses / servers to collect the replayed messages and then sending
> > the messages out through their own systems.
>
> I don't understand.
>
>
> > Even if Google and Microsoft and Yahoo and the other top 20 mailbox
> > providers start stripping DKIM headers, the attackers will be able to
> > find some service somewhere that doesn’t. Worst comes to worst, they
> > stand up a MX on an EC2 instance and run their own code to collect the
> > mail.
>
> There seems to be some appeal in discounting the resulting requirement
> to move to special receivers, but I don't understand that appeal.
> Making things more expensive for attackers is pretty much the essence of
> security protections.
>
> That the added expense isn't all that high seems ok to me, since the
> expense of imposing that expense isn't that high either.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> mast:@dcrocker@mastodon.social
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

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

[Wei Chuang]

On Tue, Nov 15, 2022 at 4:10 AM Alessandro Vesely  wrote:

> On Mon 14/Nov/2022 18:54:33 +0100 Wei Chuang wrote:
> > On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely 
> wrote:
> >
> >> BTW, we all know that mailing lists send one message at a time, doing
> >> VERP for each subscriber.  They can more easily include the recipient
> in
> >> the ARC signature.  However, any spammer can do the same. >
> > WRT to the ARC like proposed approaches, agreed that the spammer can
> sign
> > for each recipient as well.  However then the spammer has identified
> > themselves in the path, and some future path aware reputation systems
> will
> > be able to distinguish the spammer from benign forwarding flows.
>
>
> If you can filter basing on a reliable reputation system, current ARC
> seals are
> enough already, aren't they?
>
>
> Best
> Ale
> --
>
>
There's the risk that ARC gets replayed like DKIM, so it too needs
modifications IMO.
-Wei


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

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

[Wei Chuang]

Just a comment on a narrow point below.

On Mon, Nov 14, 2022 at 8:03 AM Alessandro Vesely  wrote:

>
>
> BTW, we all know that mailing lists send one message at a time, doing VERP
> for
> each subscriber.  They can more easily include the recipient in the ARC
> signature.  However, any spammer can do the same.
>

WRT to the ARC like proposed approaches, agreed that the spammer can sign
for each recipient as well.  However then the spammer has identified
themselves in the path, and some future path aware reputation systems will
be able to distinguish the spammer from benign forwarding flows.

-Wei


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

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

[Wei Chuang]

On Sun, Nov 13, 2022 at 8:50 PM Roland Turner  wrote:

> On 13/11/22 03:05, Wei Chuang wrote:
>
> On Fri, Nov 11, 2022 at 11:17 PM Roland Turner  40rolandturner@dmarc.ietf.org> 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
> <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions>
>  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?
>
Yes.  As to my role in this, I am a Gmail delivery team lead with
responsibility over the email authentication systems.  The introduction in
that slide deck represents the consensus description between the anti-abuse
and delivery teams with feedback from Bron and others as to the behavior
and impact of DKIM replay, and was based on a longer version presented at
the M3AAWG 56 BoF that was shortened to fit into the allotted time for
Dispatch.  I can also say that Gmail is very interested in seeing a DKIM
replay solution be developed in the IETF.  Depending on how this goes, if
the solution is technically sound and feasible, yes we will invest in
prototyping the specification.

-Wei

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


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

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

[Wei Chuang]

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

> 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.
>
> See the dispatch slides here

for
operational experience and impact for at least Gmail and Fastmail (the
presenters).  See the introduction.  I've heard through the grapevine that
the other mailbox providers have been impacted as well.  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.
That said, the problem in the specification still remains.  I am not aware
of any tools to help with the problem, hence the request to Dispatch to do
this work.  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.

-Wei

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


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

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

[Wei Chuang]

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
> > <https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/>
> 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
> > > t

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

[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 replay mitigations

[Wei Chuang]

I've fixed up the RFC references in 01 draft of
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/

As to the DKIM replay definition question, Murray noted that the DKIM RFC
(RFC6376) already says something about DKIM replay as when they were
writing it, they had suspected it could be a problem.  It's only recently
that it has become a real problem.
-Wei

On Tue, Oct 4, 2022 at 9:16 AM Alessandro Vesely  wrote:

> On Tue 04/Oct/2022 02:01:12 +0200 Scott Kitterman wrote:
> >
> > Many normal email operations seem difficult to distinguish from the case
> you are trying to address.  Signing fields in the envelope may be enough to
> break replaying, although it would have other negative consequences.
>
>
> Scott is right.  In general the envelope can contain jack@site-A and
> jill@site-B.  When the server connects to site-A, it only transmits
> jack.  Jill
> would be rejected with something like "Relaying denied".  So at site-A, a
> signature including the envelope is already broken.
>
> About formatting, don't stuff like:
>
>  ARC (RFC8617 (https://www.rfc-editor.org/rfc/rfc8617.html))
>
> If using XML[*], write references like:
>
>  ARC ()
>
> Or, if using mmark[†]:
>
> ARC ([@!RFC8617])
>
>
> Best
> Ale
> --
>
> [*] https://authors.ietf.org/references-in-rfcxml
> [†] https://mmark.miek.nl/
>
>
>
>
>
>
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

Re: [Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

I've uploaded a draft describing for a specification that tackles the
concepts listed below:

https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/

Feedback welcome.  (Apologies for the formatting in advance as its a first
draft)
-Wei

On Mon, Aug 22, 2022 at 2:53 PM Wei Chuang  wrote:

> Hi,
> One of the known security challenges in DKIM is its vulnerability to
> replay attacks as already mentioned in Security Considerations section 8.6
> <https://datatracker.ietf.org/doc/html/draft-ietf-dkim-rfc4871bis#section-8.6>,
> and has been raised at recent M3AAWGs as a significant challenge.  I'd like
> to propose a couple of concepts for dealing with DKIM replay.  Depending on
> where the conversation goes, I can get into proposals for technical
> specification level proposals.
>
> DKIM replay typically takes advantage of capturing a DKIM signed message
> from the inbox and then rebroadcasting it out to many users.  Taking that
> observation there are a couple of directions for mitigations.
> 1. We can try to detect and prevent the recipient amplification.  One way
> may be to specify that the sender must always DKIM sign for the who the
> intended recipient is including through mailing lists and forwarding
> scenarios, in such a way that the receiver can check for this.  If the
> intended recipient verification fails, then it may be an indication of
> replay.  This must work for multiple forwarding hops and enterprise
> scenarios, and when forwarders don't participate.
> 2. Distinguish signed messages in the inbox versus those in transit.  If
> we see messages that were signed messages meant to be in the inbox,
> suddenly in transit again, this likely indicates a replayed message.
> 3. Strengthen message digital signing to be replay resistant.  Currently
> DKIM signature's identity just says it is associated with a particular
> sender.  Perhaps we ought to tie the signature back to a particular SMTP
> transaction by signing for both the sender, receiver and timestamp.  We
> could add more specification around the timestamp to make it more workable
> in the email distributed forwarding system for replay detection.  Put this
> signature in a framework such as ARC that describes forwarding hops
> better, so that receivers can make use of those identities with
> forwarding.  Using ARC as the signing framework also helps proposal 1).
> Again consider when receivers don't participate.  (This is a highly complex
> scenario and likely I'm missing important details in trying to summarize)
>
> All the while, using ARC as a framework may allow future support for
> another long standing issue, which is working on message modification while
> forwarding, in particular for mailing lists.  The proposal
> draft-kucherawy-dkim-list-canon-01
> <https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon-01> 
> provides
> a framework for handling common mailing list modifications by identifying
> those modifications.  Putting it into ARC, may generalize this by
> identifying who made the modifications and be able to tolerate multiple
> such modifications such multiple mailing list expansions.
>
> Looking forward to your initial thoughts about feasibility and interest.
> -Wei
>


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

Re: [Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

On Tue, Aug 23, 2022 at 11:07 AM Alessandro Vesely  wrote:

> On Mon 22/Aug/2022 23:53:16 +0200 Wei Chuang wrote:
> > All the while, using ARC as a framework may allow future support for
> > another long standing issue, which is working on message modification
> while
> > forwarding, in particular for mailing lists.  The proposal
> > draft-kucherawy-dkim-list-canon-01
> > <
> https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon-01> 
> provides
>
> > a framework for handling common mailing list modifications by
> identifying
> > those modifications.  Putting it into ARC, may generalize this by
> > identifying who made the modifications and be able to tolerate multiple
> > such modifications such multiple mailing list expansions.
>
>
> There doesn't seem to be interest in deeply reworking DKIM.
>

Two of the approaches (first and second) would likely just involve tweaking
ARC, so the real cost is adopting ARC IMO.  The third proposal is a step up
in implementation cost, as it likely involves extending SMTP.

Regarding better supporting mailing lists:

Another draft, draft-kucherawy-dkim-transform[*] proposed standard
> modifications.  I implemented (a variation of) it and it works about 50%
> of
> cases.  It fails when the original signature covers too many fields; for
> example, if one signs a MIME-Version field with a different
> capitalization,
> the mailing list will overwrite it and break the original signature for
> good.  Also, altering the order of To: or Cc: mailboxes breaks signatures
> irrecoverably, unless saving Original-To:, Original-Cc:, and any other
> signed field.
>

I wonder if some of that could be handled by stronger specification?  It
would be lighter weight though less interoperable.  In practice did you see
lots of re-ordering on legitimate traffic?  How much of the 50% benefit was
found due to better supporting the features in the draft?  1) subject 2)
footer 3) mime transformations 4) new mime-part?

Do you know if anyone tried
implementing draft-kucherawy-dkim-list-canon-01?  And what were the results?


> There are mailing lists that use ARC, but they also change From:.  ARC was
> thought for that case, but it is actually useful in different cases.
>

Agreed ARC doesn't fully solve support From modification that some mailing
lists do, and needs something like the above draft-kucherawy-dkim-transform
draft.


> Also, cannot use ARC to fix the path through mailing list and forwarding
> scenarios.  That was attempted by draft-levine-dkim-conditional[†].
>

Also agree this approach of describing the sending path by the sender can
help with replay scenarios.

-Wei


>
> Best
> Ale
> --
>
>
> [*] https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/
> [†] https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
>
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
>


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

[Ietf-dkim] DKIM replay mitigations

[Wei Chuang]

Hi,
One of the known security challenges in DKIM is its vulnerability to replay
attacks as already mentioned in Security Considerations section 8.6
,
and has been raised at recent M3AAWGs as a significant challenge.  I'd like
to propose a couple of concepts for dealing with DKIM replay.  Depending on
where the conversation goes, I can get into proposals for technical
specification level proposals.

DKIM replay typically takes advantage of capturing a DKIM signed message
from the inbox and then rebroadcasting it out to many users.  Taking that
observation there are a couple of directions for mitigations.
1. We can try to detect and prevent the recipient amplification.  One way
may be to specify that the sender must always DKIM sign for the who the
intended recipient is including through mailing lists and forwarding
scenarios, in such a way that the receiver can check for this.  If the
intended recipient verification fails, then it may be an indication of
replay.  This must work for multiple forwarding hops and enterprise
scenarios, and when forwarders don't participate.
2. Distinguish signed messages in the inbox versus those in transit.  If we
see messages that were signed messages meant to be in the inbox, suddenly
in transit again, this likely indicates a replayed message.
3. Strengthen message digital signing to be replay resistant.  Currently
DKIM signature's identity just says it is associated with a particular
sender.  Perhaps we ought to tie the signature back to a particular SMTP
transaction by signing for both the sender, receiver and timestamp.  We
could add more specification around the timestamp to make it more workable
in the email distributed forwarding system for replay detection.  Put this
signature in a framework such as ARC that describes forwarding hops
better, so that receivers can make use of those identities with
forwarding.  Using ARC as the signing framework also helps proposal 1).
Again consider when receivers don't participate.  (This is a highly complex
scenario and likely I'm missing important details in trying to summarize)

All the while, using ARC as a framework may allow future support for
another long standing issue, which is working on message modification while
forwarding, in particular for mailing lists.  The proposal
draft-kucherawy-dkim-list-canon-01

provides
a framework for handling common mailing list modifications by identifying
those modifications.  Putting it into ARC, may generalize this by
identifying who made the modifications and be able to tolerate multiple
such modifications such multiple mailing list expansions.

Looking forward to your initial thoughts about feasibility and interest.
-Wei


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