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.
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!
Obviously if you re-encode the message, then the diff will be long. Don't do
that. If you re-encode the message in a purely additive world, then you can't
encode that at all.
This might lead to needing to copy headers verbatim, since you always replace
EVERY instance of the named header, but I think this is worthwhile for the
simplicity.
> This also wouldn't support large mutations like re-encoding transport
> encodings of mimeparts or deletions in general. As you've noted in your
> example, base64 poses additional difficulties. Here to avoid mutating the
> mime part, it might be more expedient to make the footer addition as a footer
> mime part as a child of a multipart/mixed. It would not support the rewrite
> of a URL as mailing lists tend not to do this. URL rewriting is more often
> performed by security gateways, and those are already meant to be a special
> case as noted in 2.6 of draft-gondwana-dkim2-motivation
> <https://www.ietf.org/archive/id/draft-gondwana-dkim2-motivation-02.html>.
Sure, the thing with my design is that you can do all these things you are
suggesting, and it's trivial to represent. But you're not limited to that.
The nice thing about the DKIM2-Delta-Body format is that it's VERY EASY to
process as a receiver; which is important from a "it's easy to validate
changes" perspective, and the sender can choose how to represent its changes,
which is valuable from a future-proofing perspective. You can create a more
clever way to add your changes to a message and still be certain that every
validator in the rest of the chain will be able to still validate it.
...
It's this "needs to be flexible for future needs" and "needs to be easy to
reliably validate without future changes" that led me to choose such a powerful
and simple syntax for body modifications.
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
