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

[Grant Taylor <[e-mail]>]

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.



Thank you and have a good day,

Grant. . . .