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

[Wei Chuang <[e-mail]>]

On Wed, Dec 1, 2021 at 3:45 AM Alessandro Vesely <[e-mail]> wrote:

> 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.
>

Agreed there's risk in HTML hiding content and showing malicious things but
that risk has existed before.  An updated DKIM authenticator could help us
understand who did those malicious updates along some forwarding path.


>
> 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.
>

Could a way of dealing with "l=" is extending the list-canon
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon> ideas
of identifying signatures by mime-parts into identifying length as well?
 In other words, with list-canon each part generates a hash, and similarly
each part can have a length of the content in that part that is claimed.
It also records the content-type for each part.  I'm going to guess that
this is to help identify changes like what I believe you are concerned
with.


>
> 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.
>

I was looking at the footers that Googlegroups puts in, and it seems to add
them to both the text/plain and text/html parts.  At least one IETF mailing
list adds a new mime-part with text/plain.  BTW has someone cataloged all
these possible mailing list changes?

-Wei


>
>
> Best
> Ale
> --
>
> [*]
> https://mailarchive.ietf.org/arch/msg/dmarc/MKgdtkeKzNNguNWHwtrop0gvb_g
>
>
>
>
>
>
>