On Thu, May 23, 2024 at 7:44 AM Wei Chuang <wei...@google.com> wrote:
> Just specifically in regards authenticating mailing list modifications: > fair enough that the ideas should be implemented first before any sort of > IETF publication for it. Still there ought to be a place for informal, > early discussion of ideas on authenticating mailing lists. For this > proposal, I think there are issues around the intersection of DKIM signing > and Content-type, and in particular, there will be advice such as in the > researcher's blogpost > <https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/> that > calls for "h=" oversigning the Content-type header to help prevent the > delimitter modification as was done. While understandable, I suspect this > prevents adding a mailing list footer as a new MIME part and perhaps too > restrictive. Instead would it be reasonable to say there be sufficient > protection if the forwarder takes ownership of appended footers? If not, > another approach would be to version the Content-type header? Yet another > approach would be to resign the DKIM signature by the forwarder, but that > hides who the sender is causing UI and spam filtering problems. Going back > to my original point, would the ietf-dkim list be the right place for this > cross-cutting discussion? I think there are a few targeted questions that > need some discussion. (We're interested prototyping but that's at least a > quarter or so away) > I think this is a fine place to have the discussion. Or at least I can't think of a better one. I've read the middle part a few times and I don't understand either the attack or the proposed mitigation, so I think some examples might help. Taking a multipart message that signs (but does not oversign) Content-Type in order to add a footer or something would still invalidate the message because the body would be different, even near the top (within any "l=" that is not zero). That's also true for adding Content-Type that wasn't there; the top of the message would need to change. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
