[Ietf-dkim] DKIM replay mitigations

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

Re: [Ietf-dkim] DKIM replay mitigations

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

Re: [Ietf-dkim] DKIM replay mitigations

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 C

Re: [Ietf-dkim] DKIM replay mitigations

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

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

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 wha

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

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

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

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

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

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 somewher

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

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 us

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

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

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

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

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

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 unilate

Re: [Ietf-dkim] Rechartering

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 th

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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 greenfi

Re: [Ietf-dkim] Rechartering

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

Re: [Ietf-dkim] Rechartering

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

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

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 "

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

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 throu

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

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

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

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/> > dra

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

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/> > dra

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

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/> > dra

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

.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

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

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 ambigu

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

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 r

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

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 participa

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

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 solut

Re: [Ietf-dkim] Problem statement adoption

+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

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

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

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

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

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

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

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

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 or

[Ietf-dkim] Email Authentication Examples document

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

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

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

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

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 mess

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

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 &

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

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 digi

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

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

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

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

[Ietf-dkim] Proposals for tolerating mailing list modifications

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 ca

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

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 tha

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

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 partic

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

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 b

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

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 poin

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

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: http

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

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 originate

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

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 authenticat

[Ietf-dkim] DKIM with body length

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 t

[Ietf-dkim] Re: DKIM with body length

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 &quo

[Ietf-dkim] Re: DKIM with body length

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 ag

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

I also wanted to voice strong support for this initiative. One of the key goals of this work is to authenticate messages that go through mailing lists that may modify the messages e.g. adding subject prefixes or footers to the body. The proposal on

[Ietf-dkim] Re: Should we be recording all modifications

On Sun, Nov 17, 2024 at 2:20 PM Bron Gondwana wrote: > I don't believe it's that complex, and I do believe it's worth the effort > in exchange for being able to tell with certainty which entity (by > signature; which DNS domain) is responsible for creating each part of a > message. You can then a

[Ietf-dkim] Re: Proposed charter; take 3

On Sun, Jan 5, 2025 at 4:56 PM Murray S. Kucherawy wrote: > On Tue, Dec 31, 2024 at 3:55 PM Wei Chuang 40google@dmarc.ietf.org> wrote: > >> Second, I prefer the prior language, as it empowers the DKIM2 >> working-group-to-be to update to the DMARC RFC to use the DK

[Ietf-dkim] Re: Successful reversal, but what about...

On Tue, Feb 4, 2025 at 4:28 PM Dave Crocker wrote: > On 2/4/2025 4:20 PM, John Levine wrote: > > It appears that Dave Crockersaid: > > If your above statement is true, then why is it necessary to do the > reversal? > > So you can tell if the earlier signatures in the chain were real. > > A DK

[Ietf-dkim] Re: Successful reversal, but what about...

On Tue, Feb 4, 2025 at 12:33 PM Dave Crocker wrote: > Folks, > > This is meant as a technical thread and it has /nothing/ to do with the > chartering discussion. > > But a stray thought occurred to me and has been bugging me. So I'm > looking for some other folk to consider it and elaborate upon

[Ietf-dkim] Re: Successful reversal, but what about...

On Tue, Feb 4, 2025 at 8:02 PM Murray S. Kucherawy wrote: > On Tue, Feb 4, 2025 at 6:58 PM Michael Thomas wrote: > >> FWIW, I'm not arguing against this. I just don't understand the urgency, >> and why the urgency is now... urgent. I think we are owed an explanation, >> and experimental data wou

[Ietf-dkim] Re: Charter #4?

On Wed, Jan 22, 2025 at 6:31 PM Richard Clayton wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In message il.com>, Murray S. Kucherawy writes > > >I've uploaded the charter, > > which I found at > > https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > for the record

[Ietf-dkim] Re: Charter #4?

Regarding RFC6376 l= tag, I was hoping that Taavi Eomäe who sometimes posts on this list would answer directly as he and his team wrote a blog post about the dangerous vulnerability the DKIM body length feature introduces. As note

[Ietf-dkim] Re: Charter #4?

On Mon, Jan 27, 2025 at 9:22 PM Murray S. Kucherawy wrote: > > > On Sat, Jan 25, 2025 at 10:12 AM Richard Clayton > wrote: > > >> >> * Identify message mutations made by any handling agent; and >> > >> >I suspect this means identification of common mutations, rather than all >> >mutations, since

[Ietf-dkim] Re: Charter #4?

On Mon, Jan 27, 2025 at 2:05 PM Murray S. Kucherawy wrote: > On Mon, Jan 27, 2025 at 1:42 PM Trent Adams 40proofpoint@dmarc.ietf.org> wrote: > >> Perhaps it’s just me... but I think it’d be great if we could focus on >> the question of the charter before diving into the solution so that we c

[Ietf-dkim] Re: Charter #4?

On Wed, Jan 29, 2025 at 3:24 PM Michael Thomas wrote: > > On 1/28/25 7:38 PM, Wei Chuang wrote: > > > I would propose that the latest charter has latitude to try both the broad > and narrow approaches for "reversible transformation", and I believe that's > a g

[Ietf-dkim] Re: A few conclusions

In summary, +1 to moving forward with the suggested changes. I don't have any great suggestions for the first three items below but some comments on the fourth and fith. On Sat, Jan 11, 2025 at 11:56 AM Murray S. Kucherawy wrote: > After watching and even engaging in the discussion about the ch

[Ietf-dkim] Re: Proposed charter; take 3

+1 that this charter is greatly improved and ready for review. That said, one largish and one smallish comment below On Mon, Dec 30, 2024 at 9:02 AM Tim Wicinski wrote: > Hi > > I think V3 is worth having the IESG work over. > > I made one small change > > s/intended to them as recipients/inte

[Ietf-dkim] Re: Multiple rcpt-to's

This note hopes to clarify the current discussion on DKIM2 signing for a single recipient vs multiple recipients, by identifying how each approach might work, and validation steps involved. From this we can identify the pros and cons of the two approaches. Single RCPT TO recipient signing has bee

[Ietf-dkim] Re: ELI5: DKIM2 and DMARC

Apologies for being late to this thread and possibly rehashing things. I definitely think DMARC and DKIM2 should co-exist and complement each other, as DMARC provides a policy declaration mechanism while DKIM2 provides an authentication mechanism. On Fri, Mar 21, 2025 at 7:41 AM Todd Herr wrote:

[Ietf-dkim] Re: Multiple rcpt-to's

o gather the signed recipients and verify that the actual recipients are a subset of the declared recipients. -Wei On Mon, Mar 24, 2025 at 11:02 AM Wei Chuang wrote: > This note hopes to clarify the current discussion on DKIM2 signing for a > single recipient vs multiple recipients, by id

[Ietf-dkim] Review of draft-gondwana-dkim2-modification-alegbra-01

Review of draft-gondwana-dkim2-modification-alegbra-01 Overall: I'm very supportive of the direction of this draft, which is to describe mutations in messages as it traverses forwarders, with the intent to be able

[Ietf-dkim] Re: Review of draft-gondwana-dkim2-modification-alegbra-01

On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana wrote: > On Sun, Mar 16, 2025, at 22:33, Wei Chuang wrote: > > Review of draft-gondwana-dkim2-modification-alegbra-01 > <https://www.ietf.org/archive/id/draft-gondwana-dkim2-modification-alegbra-01.html> > > Overall: I&

[Ietf-dkim] Updated Header Signing Strawman (was: Header Signing Strawman)

DKIM2-Signature: i=1; h=list-unsubscribe-post:x-foo To: list@mailinglist.example List-Unsubscribe-Post: Order of header fields hashed: from:to:list-unsubscribe-post:x-foo:x-foo:x-foo -Wei On Wed, Mar 26, 2025 at 1:23 AM Wei Chuang wrote: > This is a strawman description for the DKIM2 header si

[Ietf-dkim] Re: Multiple rcpt-to's

On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely wrote: > On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote: > > To support that use case and other scenarios where the recipient is not > > explicitly declared in the RFC5322 message e.g. some mailing lists, the > sender > &

[Ietf-dkim] Re: Header Signing Strawman

example. It does however show the changes to header hashing through forwarding. On Wed, Mar 26, 2025 at 9:08 AM Alessandro Vesely wrote: > On Wed 26/Mar/2025 09:23:19 +0100 Wei Chuang wrote: > > FORWARDED MESSAGE: From header rewritten and Delivered-to added > > DKIM2-Signatu

[Ietf-dkim] Re: Multiple rcpt-to's

On Tue, Mar 25, 2025 at 9:43 AM Wei Chuang wrote: > > > On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely wrote: > >> On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote: >> > To support that use case and other scenarios where the recipient is not >> > explic

[Ietf-dkim] Header Signing Strawman

This is a strawman description for the DKIM2 header signing. I know that Richard is writing a draft for this, but as draft writing is heavyweight and before going too deep down a particular path, I think there is benefit to put some sort of concept out early for community feedback. In the IETF-12

[Ietf-dkim] Re: DKIM2 Signature Hashing Strawman

On Mon, Mar 31, 2025 at 12:32 PM John Levine wrote: > It appears that Wei Chuang said: > >To sign a message, the signer must find the maximum instance tag "i=n", > >denoted as M. To add a new DKIM2-Signature, first verify that there isn't > >any to be defin

[Ietf-dkim] Re: Review of draft-gondwana-dkim2-modification-alegbra-01

On Sat, Apr 5, 2025 at 10:58 AM Alessandro Vesely wrote: > > IMHO, the original Bron's idea of a single DKIM2-Delta-Header: per > signature is more practical. Otherwise, it'd be nicer to have: > > DKIM2-Original-From: i=3; YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo=" > From: d...@lists.ietf.org > DKIM2-Ori

[Ietf-dkim] Re: Review of draft-gondwana-dkim2-modification-alegbra-01

Sorry for not getting back to this sooner. On Thu, Mar 20, 2025 at 1:58 AM Bron Gondwana wrote: > > > On Wed, Mar 19, 2025, at 08:24, Wei Chuang wrote: > > > > On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana 40fastmailteam@dmarc.ietf.org> wrote: > > > On

[Ietf-dkim] Re: Malicious Modification was: My concerns

On Sun, Apr 20, 2025 at 4:10 AM Alessandro Vesely wrote: > On Sat 19/Apr/2025 18:51:38 +0200 Allen Robinson wrote: > > On Sat, Apr 19, 2025, 9:02 a.m. Alessandro Vesely > wrote: > > [...] > > * I base64 decoded this MIME part. > > * I inserted bytes N-M > > * I trimmed the text "foobar" starting

[Ietf-dkim] Re: Malicious Modification was: My concerns

On Sat, Apr 19, 2025 at 6:03 AM Alessandro Vesely wrote: > > > > Transparent transformations, such as base64 encoding, must be recognized > as > such by the algebra. Alternatively, we could require that hashing be > performed > on the decoded content, but this would be a gratuitous incompatibili

[Ietf-dkim] Re: Review Response #2: DKIM replay

I agree that DKIM replay has been and still is very much a problem. While this issue peaked in 2022 where many senders were impacted, I still see current deliverability escalation issues with DKIM replay described as the root cause. Since 2022, we put in place several mitigation but those have li

[Ietf-dkim] Re: Review Response #12: DKIM2-Signature tag values

On Fri, Apr 11, 2025 at 6:02 PM John Levine wrote: > According to Richard Clayton : > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >In message <20250411205917.169acc3d1...@ary.qy>, John Levine > > writes > > > >>It appears that Richard Clayton said: > > > ++

[Ietf-dkim] Re: Review Response #7: Header Fields

I think the question of whether to use the exclude-list or include-list approach comes down to X- headers handling. There's a large proliferation of these headers particularly for security gateway forwarding flows. I suspect the include-list approach will likely ignore X- headers, while exclude-l

[Ietf-dkim] Re: Review Response #7: Header Fields

On Tue, Apr 15, 2025 at 10:25 PM Dave Crocker wrote: > On 4/15/2025 9:21 PM, Bron Gondwana wrote: > > Honestly, with the capacity to undo header changes from > dkim2-modification-algebra I would be more inclined to have the spec list > headers which MUST NOT be signed (probably just trace headers

[Ietf-dkim] DKIM2 Forwarding with Security Gateways

We have not looked in detail at how the DKIM2 trust model will work with security gateways for forwarded messages. With other security gateway scenarios, we have plausible trust models. For inbound security gateways the receiver that delegates to an inbound security gateway will trust its output

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

On Mon, Apr 21, 2025 at 9:34 PM Dave Crocker wrote: > On 4/21/2025 11:51 PM, Richard Clayton wrote: > > I think you may have overlooked some aspects of what is needed to make a > difference to the current situation. > > Your design records and signs the RCPT TO of the original email and > insists

[Ietf-dkim] Re: Review Response #2: DKIM replay

On Fri, Apr 18, 2025 at 10:11 AM Alessandro Vesely wrote: > On Mon 14/Apr/2025 19:01:35 +0200 Wei Chuang wrote: > > Instead I think we need a better way that can describe the originator, > when a > > message was forwarded and when a participant tries to spoof the > forwa

[Ietf-dkim] Re: DKIM2 Forwarding with Security Gateways

Hi Larry and Taavi On Wed, May 7, 2025 at 6:16 AM Larry M. Smith wrote: > On 5/6/2025, Taavi Eomäe wrote: > > Hi, > > > > On 05.05.2025 21:29, Wei Chuang wrote: > >> One idea is to ask receivers to fully trust the security gateway as > >> the modificat

[Ietf-dkim] DKIM2 Signature Hashing Strawman

ect all DKIM2 header fields in the message header 2) Find the maximum instance tag value of M where there exists a continuous sequence from 1 to M. 3) Start with an instance tag value of M and validate the DKIM2-Signature. 4) Optionally validate the DKIM2-Signature with i=1 to M-1. (Whether

[Ietf-dkim] Re: Whether to adopt draft-gondwana-dkim2-modification-alegbra-01

I support adoption of draft-gondwana-dkim2-modification-alegbra to enable further discussion within the DKIM working group. We'll need some form of message "algebra" to get the full promise of DKIM2 meaningfully solving the mailing list problem. It's not perfect as I described on the March 16th t

[Ietf-dkim] Re: is A-R useful? was DKIM2 Forwarding

On Thu, May 8, 2025 at 6:03 PM John Levine wrote: > It appears that Bron Gondwana said: > >So if there's anything ARC currently does better, I'd want to see if we > can implement that into DKIM2 as well. One case that has already been > discussed is > >the signed Authentication-Results headers

[Ietf-dkim] Re: DKIM2 and DMARC

On Wed, May 7, 2025 at 5:42 AM Alessandro Vesely wrote: > On Wed 07/May/2025 00:18:41 +0200 Wei Chuang wrote: > > forwarders will likely also want a say in what happens to a message that > fails > > validation. > > > In order to keep it simple, I'd conceive the

[Ietf-dkim] Re: is A-R useful? was DKIM2 Forwarding

On Sat, May 10, 2025 at 10:18 AM John R Levine wrote: > On Fri, 9 May 2025, Wei Chuang wrote: > >> I don't see anything useful in the A-R header that the recipient > doesn't know, or > >> couldn't easily figure out. > >> > >> Am I missi

[Ietf-dkim] DKIM2 and DMARC

DKIM2 is meant to support forwarding and DMARC from the start. One area where we haven't looked deeply is at the interaction between forwarding and DMARC with DKIM2. We have been generally assuming that DKIM2 will expand passing scenarios for cases where DKIM and SPF would fail hence fail DMARC.

[Ietf-dkim] Re: DKIM2 Forwarding with Security Gateways

On Tue, May 6, 2025 at 2:54 AM Taavi Eomäe wrote: > Hi, > > On 05.05.2025 21:29, Wei Chuang wrote: > > One idea is to ask receivers to fully trust the security gateway as > > the modifications done are to protect the receiver's users with best > > effort by t

[Ietf-dkim] Re: DKIM2 Forwarding with Security Gateways

On Tue, May 6, 2025 at 6:39 AM Alessandro Vesely wrote: > On Mon 05/May/2025 20:29:40 +0200 Wei Chuang wrote: > > Security gateways may modify the message in complex ways that message > algebra > > cannot cover > > > If changes cannot be described, how can DKIM2 be use

[Ietf-dkim] Re: DKIM2 and DMARC

On Tue, May 13, 2025 at 3:24 AM Alessandro Vesely wrote: > On 12/05/2025 17:50, John Levine wrote: > > It appears that Alessandro Vesely said: > >>> When you deliver a message, if you want to undo that particular change > to make > >>> it easier to reply to list messages, that's not a bad idea,

[Ietf-dkim] Re: Multiple signatures in DKIM2

On Sat, Jul 19, 2025 at 9:43 AM Bron Gondwana wrote: > > On Wed, Jul 16, 2025, at 19:45, Bron Gondwana wrote: > > On Wed, Jul 16, 2025, at 17:05, Barry Leiba wrote: > > What's wrong with something like this: > The verifier MUST support at least one of the signature algorithms. > The verifier SHOU

[Ietf-dkim] Re: Updated Header Signing Strawman

gt; I know I'm late but: > > On 4/7/25 06:35, Wei Chuang wrote: > > In an offline conversation with Bron and Tobias, they described a likely > > improvement to the header signing method described 26 March 2025. The > > following is my description of that proposal. The

[Ietf-dkim] Domain Name Specification for DKIM2 I-D

Hi all, I'm announcing the Internet-Draft for the "Domain Name specification for DKIM2". https://datatracker.ietf.org/doc/draft-chuang-dkim2-dns/02/ DKIM2 intends to be compatible with the existing DKIM installed base of keys hence this part of the specification is essentially the same as RFC6376

[Ietf-dkim] Re: Domain Name Specification for DKIM2 I-D

On Thu, Jul 10, 2025 at 10:52 AM John Levine wrote: > It appears that Wei Chuang said: > >-=-=-=-=-=- > > > >Hi all, > >I'm announcing the Internet-Draft for the "Domain Name specification for > >DKIM2". > >https://datatracker.ietf.org/doc

  1   2   >