Re: [dmarc-ietf] Reversing modifications from mailing lists

[Alessandro Vesely <[e-mail]>]

On Tue 30/Nov/2021 18:30:39 +0100 John R Levine wrote:
> On Tue, 30 Nov 2021, Wei Chuang wrote:
>> What about adding a footer to some html mime part is poorly handled when
>> using "l="?  Multipart bodies could be handled by other techniques.
> 
> See section 8.2 in the DKIM spec which says if you use l= you need to be 
> careful with your MIME boundaries so naughty people can't add another part that 
> overlays the real message.


I'm not clear about the last but one paragraph of that section:

    An example of such an attack includes altering the MIME structure,
    exploiting lax HTML parsing in the MUA, and defeating duplicate
    message detection algorithms.

I'm going to file an errata about it.  Altering the MIME structure is only 
possible if the value of l= is less than the original message length.  If the 
whole MIME structure forms the body hash, including the epilogue, it is not 
feasible to alter it.  If Content-Type is not signed, the attacker can change 
the top boundary and append whatever content she likes, thereby relegating the 
original, unaltered MIME structure to the role of preamble.

Setting l= with MIME structures doesn't help a non-breaking footer addition. 
For plain text messages, it would help.  However, Section 5.4.1. suggests to 
sign Content-Type when setting l=, to avoid the above attack, and signing 
Content-Type makes for breakable DKIM signatures since MLMs overwrite that 
field.  (Yes, they set text/plain again if the type was such, but 
capitalization and comments may differ.)  Hence I retract what I said in my 
previous message[*], that l= works well with a wide range of mailing lists.

Finally, I thought duplicate message detection was rather related to Message-ID 
than to l=.


> I have seen lists that edit the footer into the HTML of the body, I think at 
> Yahoo groups.  Don't see how you're going to describe that in a reversible way.


Hm... when HTML parts are paired by alternative plain text parts, it is hard, 
due to HTML complexity, to make the added footers look alike.

Anyway, I wouldn't want to authenticate a message that underwent an HTML footer 
addition, because it can completely replace the original content in the end 
recipient's eyes.  My draft requires footers to be plain text.


Best
Ale
-- 

[*] https://mailarchive.ietf.org/arch/msg/dmarc/MKgdtkeKzNNguNWHwtrop0gvb_g