On Wed, Mar 19, 2025, at 08:24, Wei Chuang wrote: > > > On Tue, Mar 18, 2025 at 3:51 AM Bron Gondwana > <brong=40fastmailteam....@dmarc.ietf.org> 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'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 to reverse them. The benefit of this reverse operation is to >>> enable successful DKIM signature verification on earlier versions of the >>> message at the receiver. In addition this procedure can help determine >>> which party added or removed content to a message. The following are some >>> comments. >>> >>> Section 2. Delta format - headers >>> >>> The DKIM2-Delta-Header can help reverse singleton header replacement and >>> addition style mutations, however it appears support for header deletion is >>> missing. Further this header representation likely has difficulties when >>> there can be multiples e.g. DKIM-Signature. Potentially this can be fixed >>> by adding deletion bit and position metadata to DKIM2-Delta-Header. An >>> implementation simplification that tries to remove some ambiguity might be >>> to have the DKIM2-Delta-Header apply to a single header adjacent to it. >> >> I'll take this as a review comment that I need to be much more clear on how >> it works! This text from section 2 tried to describe how to remove a header >> in one of the examples: >> >> Example for a message which has had Subject and From replaced, and >> Reply-To added. >> >> From: br...@fastmailteam.com.dmarc.fail >> To: dk...@lists.ietf.org >> Reply-To: dk...@lists.ietf.org >> DKIM2-Delta-Header: i=3; >> t=Subject:A replacement for DKIM; >> b=From:YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo=; >> t=Reply-To >> >> Notice that "Reply-To" has no colon, and hence is an instruction to >> remove any "Reply-To" headers. All headers are case insignificant >> for removal, and SHOULD be inserted with the case given in the header >> when being added back. > > Thanks for pointing that out. Taking "Subject:" as an example of a header > that is deleted at the forwarder i=3, when we apply the reversing > transformation to restore the message to the representation at the output of > i=2, where should the "Subject:A replacement for DKIM" be restored to? > Another issue is that each DKIM2-Delta-Header requires scanning the entire > set of headers to apply all possible restorative mutations. Further what if > multiple DKIM2-Delta-Header headers can apply to a given header i.e. which > one should win? So instead I propose that each DKIM2-Delta-Header be > restricted to the mutation of one header to act as a placeholder for the > location of the header for deletes, and adjacent to the added or modified > header.
Hmm. I would probably put it at the top if there's no existing Subject header, or at the same spot as the existing Subject header otherwise. But it shouldn't matter, Subject isn't a trace header; and the DKIM2 signature will validate regardless of where you put it - which is all that really matters when you're recreating a past message. It doesn't have to have byte-identical headers, just headers that will pass the DKIM validator. There are either zero or one DKIM2-Delta-Headers with `i=3` , and if there is one, then that's the one that you apply in order to convert from the output of signer number 3 back to the the input of signer number 3 (AKA: the output of signer 2). I think I understand your proposal, which is to do something like: DKIM2-Delta-Header: i=3; h=From; b="From:YnJvbmdAZmFzdG1haWx0ZWFtLmNvbQo=" From: d...@lists.ietf.org DKIM2-Delta-Header: i=3; h=Reply-To Reply-To: d...@lists.ietf.org DKIM2-Delta-Header: i=3; h=Subject; t="A replacement for DKIM" Subject: [DKIM2] A replacement for DKIM And then it would mean that the "From" always gets put before the "Subject". This would work fine. I'm OK with that. It does mean slightly more verbose syntax (zero or more DKIM2-Delta-Header rather than zero or one DKIM2-Delta-Headers) - it also means there are multiple headers with the same i= value. I'm happy to discuss pros-and-cons here. And I'm OK with either both from a design perspective and from an implementation perspective. > >> >> Every `DKIM2-Delta-Header` item describes a header name, and it always >> removes all instances of headers with that name, and replaces them with zero >> or more new headers with the name. >> >>> 3. Delta format - body >>> >>> The DKIM2-Delta-Body is a powerful construct to support arbitrary >>> mutations. However from an implementation perspective, it requires keeping >>> the old and new version of the message which will be cumbersome. It also >>> is also unbounded in header size. For example, imagine encoding the change >>> when the MTA re-encodes the transport format of a large message. For that >>> reason, I propose that the diff mechanism focuses on additive changes that >>> mailing lists tend to do like appending a footer. These can be encoded >>> simply. >> >> They can be encoded very simply with this format too. In DKIM1 if the >> additive change had been implemented from l=10423 then it would be encoded >> as: >> >> DKIM2-Delta-Body: i=2; c=0-10423 >> >> which is pretty short! > > Indeed I think this approach is the right way to go. I would suggest that we > limit the representation to additive transformations for now, and leave > deletions out for now until there is more evidence that it is needed. You > might argue that it's needed for appending to the base64, but what about > adding a new parent multipart/mixed and appending a footer mime-part? That > seems less damaging. We could do that. Restricting it to additive means that there's no way to add back text, only to remove it. That's much less powerful, which has pros and cons. My worry would be that it's not powerful enough, but there's tons of parsers out there which only support this version, so you'd be stuck with no ability to do things that we then discover would be more efficient. > Agreed that restoring patching the diff operation is straight forward. > However it does burden the forwarder as noted about keeping the original and > updated message. That bookkeeping will be particularly expensive for large > messages. I suspect a much easier process is for mailing list forwarders to > keep track of the mutation and publish those simple mutations. This might > be an area where we try some experimentation to see what can be done at > scale. Nothing about a more expressive syntax stops the forwarder from restricting themselves to making simple mutations. The sender can choose to only make the kinds of changes that allow them to avoid having to keep both messages around. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
