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

From: Alessandro Vesely <[email-masked]>
Date: Wed, 1 Dec 2021 12:45:43 +0100

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

---

From: "John Levine" <[email-masked]>
Date: 1 Dec 2021 14:10:30 -0500

It appears that Alessandro Vesely  <[email-masked]> said:
>possible if the value of l= is less than the original message length. 

I wish you hadn't.  I think the original concern was for sloppy MIME that
forgot the -- after the last part.

>recipient's eyes.  My draft requires footers to be plain text.

Yet that's exactly what one of the largest discussion group services in the world did.
As I keep pointing out, this is like an UNCOL, it does not generalize enough to be useful.

On the other hand, ARC handles this just fine.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 2 Dec 2021 12:52:23 +0100

> forgot the -- after the last part.

I hope such errors are not so common as to deserve some kind of standardization.

> On the other hand, ARC handles this just fine.

I, for one, am unable to use ARC as a receiver and authenticate messages that 
may well be spear phishing.  So even though ARC can handle everything, it is 
not usable by everyone.

In order to trust the authorship of a message from Yahoo groups you have to 
trust Yahoo, either expressing your trust in an ARC filter configuration file 
or directly whitelisting Yahoo groups in a DMARC filter.  However, not all 
mailing lists need such special settings to authenticate their posters.  There 
are mailing lists which make no changes, and ones which make revertible changes.

Your objection sounds like you find that a lisp compiler is useless because it 
doesn't compile fortran, which is one of the most ubiquitous languages in the 
world.

Two methods is better than one.

Best
Ale
--

---

From: Wei Chuang <[email-masked]>
Date: Sun, 5 Dec 2021 11:55:30 -0800

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

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

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

---

From: "John R Levine" <[email-masked]>
Date: 5 Dec 2021 15:24:25 -0500

> understand who did those malicious updates along some forwarding path.

I'm pretty sure that changing DKIM is very out of scope for this working 
group.

We have a decade of experience with DKIM.  If l= were useful, someone 
would have figured it out by now.

R's,
John

---

From: Benny Pedersen <[email-masked]>
Date: Sun, 05 Dec 2021 21:35:20 +0100

On 2021-12-05 21:24, John R Levine wrote:
> I'm pretty sure that changing DKIM is very out of scope for this 
> working group.

+1

> would have figured it out by now.

is there any talks about dkim l= tag anywhere ?, can dkim verify l= 
number of lines is not changed ?, will it gives special results if its 
changed or not changed, does dmarc understand this tests in dkim ?

if dkim cant do this its not usefull dkim specs says it exists imho

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Dec 2021 00:22:41 -0800

> I'm pretty sure that changing DKIM is very out of scope for this working

As I read the charter, I don't agree.  It says in at least two places that
this could be in scope.

Whether the chairs want the WG to engage in such work right now is another
matter.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 12:39:41 +0100

On Sun 05/Dec/2021 20:55:30 +0100 Wei Chuang wrote:
>>> 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. >

ARC can do better for such kind of forensic analysis.

>> [...]  Hence I retract what I said in my previous message[*], that l=
>> works well with a wide range of mailing lists. >

Those ideas have been ruminated for a while.  See also
https://datatracker.ietf.org/doc/html/draft-crocker-dkim-doseta-00
https://datatracker.ietf.org/doc/html/draft-vesely-smooth-canon-00

In fact, at this point DKIM is what it is, for the good and the bad of it.

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

Wikipedia has a list of ten software packages, dunno if it's complete:
https://en.wikipedia.org/wiki/List_of_mailing_list_software
It doesn't dig into their peculiarities.

Mailing lists existed before computers, and are not regulated by strict rules, 
so trying to harness their behavior holds little water.  For example, it is 
customary these days to have discussion fora backed by mailing lists, where 
messages arrive with a From: display name referring to a user while the address 
part points to the forum server.  In that case, the user most likely typed the 
text in a web page, so the From: is not /re/-written, it's written that way 
from the start.  Although those messages have parts that were not written by 
the user, it is not possible to catalogue the changes.  And not even ARC can 
handle such messages in a way that would results in a From: address pointing to 
the real author.

Best
Ale
--