Hi Murray--
On Fri 2015-02-27 14:46:40 -0500, Murray S. Kucherawy wrote:
Sorry, by "sign" I meant "add a footer". I probably said "sign" because this is related to some DKIM work I've been planning, and the morning's caffeine was already wearing off.
:)
Thanks for that detailed answer (and Barry for his followup). It's precisely what I was looking for.
How absurd would it be to propose a flag for Mailman that would take your first case (non-MIME, or single-part text/plain) and convert it to a multipart/mixed with a child part of the original text/plain, and then apply the algorithm you have?
I'm not one to make any decisions for mailman, but this sounds pretty reasonable to me. In fact, the only argument against ever having such a switch *not* set is that non-MIME-aware text-only MUAs will now see some crufty MIME boundaries in the message that they didn't see before.
I'd bet the number of users of non-MIME-aware text-only MUAs receiving mail from mailman that are incapable of wading through a bit of extra MIME boundary info on otherwise text/plain messages is vanishingly small. Most of those folks are probably at least used to seeing it as a result of the overwhelming predominance of multipart/alternative on today's SMTP network.
The impetus here is DKIM survivability across lists. Suppose we had a DKIM canonicalization that was MIME-aware, so that it could sign the specific MIME parts or sets of parts. That signature would fail on the message as a whole -- with the footer part added -- but could in theory pass if an appended part were omitted from canonicalization. To put it in context, suppose there were a DKIM canonicalization where the signer signed (using your examples) the CDE message; the receiver gets FGHI which fails, but also has enough information to know that merely verifying FGH will pass; it then knows that FGH was "legitimate" and I was added post-signing, and may or may not be "safe" (for some value thereof) content.
What I'm worried about with such a design is the trivial text/plain message. Obviously merely appending the footer destroys any hope of validating only the original content. We'd have to entertain the idea that Mailman would make the simple message into a multipart/mixed + text/plain, then append the footer part and sign that; the verifier would drop the footer and then strip off the MIME to see if it can verify the original signature that way. That seems like its easy to get wrong, though it's likely to be a very common case.
right, the MIME boundaries provide the parsing framework to enable this kind of sub-part DKIM-verification.
One issue this process brings up is that it's now necessary to treat pretty much every part of the message as though it is multipart/signed -- that is, it needs to be handled bytewise opaquely, on pain of breaking the DKIM header.
We already know that there are tools that do things like re-encode messages from base64 to q-p, or change character sets, or just re-flow long lines (FSVO "long") in the mime boundary subheaders. They're not supposed to do this with multipart/signed messages, because the RFCs point out that opaque handling is required, but they sometimes break them anyway. I imagine the same risk would now apply to all DKIM-signed messages using your scheme.
With that caveat in mind, it's clear that without your proposal, all DKIM-signatures of messages with footers will break anyway. So this does seem to be a strict improvement, even if there are a few corner cases that aren't fully covered.
--dkg