On Wed 16/Apr/2025 17:20:19 +0200 Murray S. Kucherawy wrote:
On Sat, Apr 12, 2025 at 12:28 AM Dave Crocker <[email protected]> wrote:
On 4/11/2025 12:56 PM, Richard Clayton wrote:
[...]
I agree we need to get the history right here. I don't necessarily agree
that this is fatal to adoption.
[...]
If an intermediary alters the email then the original DKIM1 signature
will no longer be verifiable.
This is not a 'design weakness'. DKIM was intended to survive simple, classic
MTA-based relaying, but it never had a goal of surviving re-postings. It does
what it was designed to do.
I tend to agree ... weakness is probably not the right word for "it
breaks completely".>>
Drive a car over a speed bump at speed. It's designed to deal with that.
Drop it from an airplane and it breaks completely. Or perhaps saying that
is, forgive me, silly.
Saying that DKIM breaks when it is used differently than intended
misdirects discussion.
And to be clear, my point is not that there is nothing to be done but
rather that claiming DKIM is a problem is simply wrong.
And, by the way, your group's effort to create something completely new
supports this point. (re-using component tech from DKIM does not make it a
variant of DKIM. Especially since the semantics of what is being pursued
are so fundamentally different.
Why not say that the problem is those mailing lists that modify the
message? Because, of course, they aren't. Neither is DKIM.
I concur that both lists and DKIM are working as designed. This isn't a
weakness as much as it is an intentional limitation of the original scope.
And lists have behaved that way since before there was DKIM.
Of course, it's not DKIM that breaks mailing lists. It's DMARC. However, I
wouldn't say DMARC uses DKIM any differently than intended. Everyone knew from
the beginning that mailing lists were collateral damage.
I think the intent of the work is reasonable though, as in "There's a class
of problems the contemporary Internet needs to resolve that DKIM wasn't
designed to solve", which is essentially what the charter ended up saying
after we iterated on this point previously. I do think it should say that,
but I don't think this is a fatal defect that can't be corrected through
iteration post-adoption.
IOW, now that we have DMARC and have seen its limitations, let's design an
authentication mechanism that better fits its model.
No-one is suggesting that the impact of, for example, mailing list
alterations to email were unforeseen (and indeed l= is present to try
and address the issue).
l= was overly naïve in addressing that point.
Re-posting a message can entail arbitrary transformations and a technology like
basic digital signing never had a goal of surviving that. DKIM was
/explicitly NOT/ designed to survive these transformations.
While there is nothing wrong with seeking to provide a mechanism that does
survive, it is a new requirement, not a failure in an existing mechanism.
So the wording here is finding fault with something that was not a goal.
Using language that implies or claims failures, for things that were known at
the time and were deemed acceptable or out of scope is not a failure.
Especially not after roughly 20 years.
Dave's objection makes perfect sense. Perhaps, the rationale for DKIM2 should
not be /replace/ the existing email security mechanisms but rather add a new
one. DKIM2 is ideal for mailing lists and free mail. For business or personal
use, DKIM1 is preferable as it survives forwarding (as designed).
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
