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

[Wei Chuang <[e-mail]>]

On Wed, Jul 12, 2023 at 8:34 PM Grant Taylor <gtaylor=
[e-mail]> 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


>