On Thu 09/Jul/2020 03:03:40 +0200 Murray S. Kucherawy wrote:
A sub-optimal flow might be:
- validate the MLM signature; it passes
- validate the author domain signature; it fails
- notice the MLM signature (which validated) has a "tf=" tag saying
"subject,footer"
- search the body backwards until you find the delimiter, and toss away everything after
that, which undoes the "footer"
- un-mutate the Subject
- re-validate the author domain signature (you don't have to repeat the DNS
stuff, it's cached); it (in theory) passes
<hand_waving> You could maybe do clever tricks like notice that "tf" is
there and apply the reverses inline as you process the author signature,
saving you a repeat verification pass. </hand_waving>
[...ARC comparison omitted...]
I have less confidence in the expense of the MIME un-transformations
because I've never implemented them specifically. I could take a run at it
but there are probably libraries out there that do a better job than I
would.
It'd be a stroke of luck to find a library which does exactly that. Ned's note
about the design of such tools applies here too. However, it doesn't seem
overly difficult to do it from scratch.
Let's consider a sample multipart message body, indented for legibility:
--added-boundary
Content-Type: <original-content-type>; boundary="original-boundary"
[...original preamble...]
--original-boundary
[...original header and body...]
--original-boundary--
[...original epilogue...]
--added-boundary
[...added footer...]
--added-boundary--
[...epilogue...]
Assume for simplicity that the author did not sign Content-Type:. Knowing
there's an added boundary, you can skip the initial part of the body, start
canonicalizing at the first entity's body, and stop at the next appearance of
"--added-boundary". In addition, you must also check that there are no
entities before the original part. So, all you need to know is that the
original message was multipart.
MLM code probably needs some rewriting in order to ensure that the original
preamble and epilogue are kept intact (and without adding extra empty lines.)
Some rewriting is also needed to avoid gratuitous header changes. I tried the
above procedure manually on the message I'm replying to. It failed because the
original message has:
Cc: Alessandro Vesely <[email protected]>, IETF DMARC WG <[email protected]>
whereas the published copy has:
Cc: IETF DMARC WG <[email protected]>, Alessandro Vesely <[email protected]>
For text/plain messages, instead, all you need to know is the length of the
original message. If the author signed with l=, no action is needed.
In both cases, the body hash can be done in one pass, except if the body is
converted to base64 encoding. This list often, but not always, does such
wrapping, and then signs the message again. Dunno if that's a feature or a bug.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
