Sorry for not getting back to this sooner. On Thu, Mar 20, 2025 at 1:58 AM Bron Gondwana <brong= 40fastmailteam....@dmarc.ietf.org> wrote:
> > > 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. > +1 We should work through pros-cons. I propose we deep dive into this to thoroughly dig out the pros-cons this after the header draft details (and its likely successor) gets further along. > > 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. > +1 to pros/cons. While I don't see an immediate need for the generality of vcdiff, there could be might be a need someday. One way to resolve this might be to restrict the syntax to support additive for now, and reserve the rest if necessary later. Is forwarder added content described as a vcdiff copy operation? Another approach altogether from (pre/)appending to existing mime parts is treating the header or footer as new mime parts, then added them as a new child to a new multipart/mixed root mime part along with the original root mime part as the second child. No modification of the original mime part is necessary. To reverse this mutation, the original mime part needs to be identified to be recovered. > 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. > It's an interesting point. -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
