Jim Fenton wrote in <f1533472-906d-4d10-bfcd-1a46431cf...@bluepopcorn.net>: |On 29 Jan 2025, at 19:30, Michael Thomas wrote: |> On 1/29/25 6:20 PM, Murray S. Kucherawy wrote: |>> My own motivation is the former, not the latter. That is, yes I \ |>> would like to recover the author domain signature if we can come \ |>> up with a relatively robust way to do that without creating a security \ |>> hole; no, my motivation has nothing to do with enabling uptake of \ |>> "p=reject", though that might be a side effect that I think others \ |>> would find beneficial. |> |> It still creates a security hole. But maybe a more tractable one; \ |> we shouldn't cop attitude that it doesn't. There are tradeoffs to \ |> both approaches. Security is a risk/reward thing, after all. | |I’m a little unclear on the need to fully describe the “mutation” that \ |might be applied by an intermediary. Even if fully described, you need \ |to have some trust of the intermediary to accept the mutation, because \ |otherwise you don’t know that the mutation doesn’t contain harmful/u\ |nwanted content (barring some magic AI thing perhaps). | |If you do have trust of the intermediary to only sign messages where \ |they have verified the DKIM signature of the message received by the \ |intermediary, shouldn’t the intermediary’s signature on the modified \ |message should be sufficient? I thought this was effectively what \ |ARC is doing, although I have quibbles about how ARC does it.
Sorry to come back to my DKIMACDC, but the question is "what is the purpose of the differences". In DKIMACDC you create the differences on the DKIM-normalized data, and the purpose is only to be able to cryptographically verify the DKIM signature of the restored DKIM-normalized data soup, as far as you want, up to the sender's original variant at maximum. There is no security hole. However, one can visualize that soup. This should possibly be done only after signatures were verified. Visualization works for headers by standard means just fine, as if they were a real email: users will have the look and feel of a normal email. For the body parts it is different, but an enhanced parser can visualize text sections likely so that users can compare two versions pretty sensibly. (To whatever extend desired that is: down to decoding base64 and QP, aka: analyzing and parsing MIME structure.) For security of visualization it must be said that already today base64 and also QP encoded text parts etc can practically contain anything, and MUAs are better off to filter control characters etc. Of course: mentioning this in security considerations is a good thing! --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |In Fall and Winter, feel "The Dropbear Bard"s pint(er). | |The banded bear |without a care, |Banged on himself for e'er and e'er | |Farewell, dear collar bear _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
