On Wed, Jul 12, 2023 at 8:34 PM Grant Taylor <gtaylor= 40tnetconsulting....@dmarc.ietf.org> 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 >
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
