Sorry, no. From a security standpoint they are identical problems so if
you're making an argument against l= then you are also making an
argument against anything else that allows you to know how to
reconstruct the original signature. The receiver in both cases needs to
consider the mutations and whether they are acceptable and potentially
consider it the light of who made those mutations and their reputation.
In fact, I would argue that a more complex mutation algebra would be
even more dangerous than the simple minded l= which just allows
appending content. For example, suppose it allowed in-body changes (eg,
ostensibly for MIME changes), evil.com could add a hyperlink to text in
the body of the original message:
<a href=evil.com>Click here for free money!</a>
which you can't do with l=.
But the larger point is that if you indict l=, you are indicting any
other scheme that allows reconstruction of the original message. Full
stop. Receivers in both cases will need to consider any modifications
differently and apply scrutiny and reputation to the different parts of
the message. To your point of taking ownership of changes, you can
already do that with DKIM. The mailing list, for example, can always
resign the outgoing message (and should).
The main advantage of the entity making mutations annotating them is
they actually know the sort of mutations they are making so they can be
much more accurate. Back then, it wasn't reasonable to think that
mailing lists would pay any attention to DKIM considerations, so z= and
l= were the best I could hope for. I doubt any changes proposed here
will be adopted anytime soon either, but at least it would be possible.
Mike
On 1/26/25 9:24 PM, Wei Chuang wrote:
Regarding RFC6376 l= tag, I was hoping that Taavi Eomäe who sometimes
posts on this list would answer directly as he and his team wrote a
blog post
<https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/> about
the dangerous vulnerability the DKIM body length feature introduces.
As noted in May 2024, the authors found many infrastructurally
important senders' emails had DKIM with body length, and with these
emails it was possible to completely rewrite the user visible content
yet would indicate a DKIM pass. That result could then indicate a
DMARC and BIMI pass as their example illustrated. On this public list
I'm going to leave up to the imagination of the reader what a
malicious party could do here with that malicious content, but I would
agree with the blog authors that consequences could be rather bad. And
like the authors suggest, it isn't just a few confused senders. While
percentages are small, the importance of the senders, presumed
sophistication and consequence of spoofing those emails would be
surprising to many having looked at the data on who the senders that
use this feature are. (see the blog post for examples) There was a
long mail thread
<https://mailarchive.ietf.org/arch/browse/ietf-dkim/?q=dkim%20body%20length> on
this list (ietf-dkim@) to draw attention to this vulnerability. Since
then a bunch of us in industry have been coming together to make
improvements and some of that work is described in
draft-gondwana-dkim2-modification-alegbra
<https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/>.
There are other ideas too but are waiting for this working group to
kick off due to prohibition on technical discussion until then. The
key difference between RFC6376 l= and Bron's draft is that the
forwarder making the modification takes ownership of the modification
and this provides attribution. With RFC6376 l=, anyone can make the
change without attribution which lets a malicious party slip right
in. A second difference noted by the draft is identifying the changes
in a reversible, verifiable way. A third point is around the
suggestion later in this thread about incremental changes to RFC6376
vs a new authentication mechanism. The problem with incremental
changes is that they are inherently optional, and very soon you'll
have many combinations of features in use that hurts interop. And
once optional it will take a very long time if at all to go away. I
still see DKIM body length being used yet at a lower rate, having
dropped by half after Taavi's May 2024 blog post but some decline
after that but definitely not trending towards zero. Fourth, going
back to RFC6376 l= tag, the security section
<https://datatracker.ietf.org/doc/html/rfc6376#section-8.2> 8.2
"Misuse of Body Length Limits ("l=" Tag)" says to "To avoid this
attack, Signers should be extremely wary of using this tag..." Yet
here we are where it's being used despite the vulnerability being
known back 2011. We need a new authentication technique where such
obvious footguns aren't possible.
-Wei
On Sat, Jan 25, 2025 at 2:14 PM Michael Thomas <m...@mtcc.com> wrote:
On 1/25/25 10:10 AM, Richard Clayton wrote:
> > There are additional needs. They are new. Or, at least, they
were not
> > previously a priority. Since they were not needs when DKIM was
> developed, they
> > are not 'shortcomings'.
>
> they may not have been perceived to be shortcomings then -- they are
> now, which is why a number of people wish to improve things for the
> people whose email they handle
Fwiw, mailing list traversal was always a shortcoming of DKIM from
the
very beginning. That some people dismissed it at the time doesn't
alter
the fact that it was -- and is -- a shortcoming. Our original
intent at
Cisco was to address the internal spear-phishing problem for us, but
given Cisco's widespread use of mailing lists -- both internal and
external -- that made it a hard goal to achieve. z= and l= were an
attempt to be "good enough" on my part even though there was a lot of
hostility at the time (they actually worked pretty well in practice).
That's especially true of l= since the objection was that it was
"insecure", but any new mechanism which records what changes an
intermediary made has the exact same "insecurity" in that the message
will differ from the originating signature's signed canonical text
whose
changes may or may not be benign. Frankly, that's up for the
receiver to
figure out which I think they are capable given spam/scam filters,
etc
and the reputation that you can assess from the intermediaries making
the mutations. I even wrote a patent app about that which I don't
think
was issued probably because it was too obvious.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
