On Mon, May 20, 2024 at 7:17 PM Murray S. Kucherawy <superu...@gmail.com> wrote:
> On Sun, May 19, 2024 at 9:27 AM Wei Chuang <weihaw= > 40google....@dmarc.ietf.org> wrote: > .... > > Dave Crocker mentioned that there is a pathway to do a narrow update to the >> RFC6376 as an individual submission. I agree that it is a good idea as >> hopefully a narrow update can be done relatively quickly. I understand >> that body length "l=" was meant to help DKIM tolerate adding a footer >> that a mailing list might do and that there is pressure from the DMARC >> world to think about this. Perhaps that still can be done except in a >> better secure way, and that work could be a separate document to permit it >> time to figure out how to do it. One idea is to have the forwarder sign >> with an ARC Message-Signature and would take ownership of the new message. >> The forwarder would describe the offsets to recover the original body >> length and some receiver can validate the original DKIM signature. Those >> offsets will also describe the forwarder's contribution to the message. >> There would also be problems around secure footer modification of >> Content-type header that are unsolved e.g. what to do if Content-type is >> oversigned. All this work might be good candidates for the newly chartered >> Mailmaint WG. >> > > Before we make suggestions about ARC, I would strongly suggest someone try > that as a solution or mitigation to this problem. I would not like us to > publish something that shouts about this being a serious problem but then > presents untested solution(s). And frankly, I'd like to see ARC graduate > out of Experimental status if that's what we want to put forward as a > solution. > > As to MAILMAINT as a venue, we'll have to see whether the community thinks > this is "big" or "small"; if the former, it should probably get its own WG. > > 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) -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
