On Sat, Apr 12, 2025 at 12:28 AM Dave Crocker <[email protected]> wrote:
> On 4/11/2025 12:56 PM, Richard Clayton wrote: > > At the end of January Dave Crocker posted a review of the then current > "-01" version of draft-gondwana-dkim2-motivation. This document has now > been split into an "-02" and draft-gondwana-dkim2-headers (-01). > > And it is unfortunate, indeed, that this lengthy stream of comments have > been made against the original document version, rather than the current > one. > > That makes the original concerns seem abstract and distant. Which they > aren't. > > And the pattern of responses serves further to defer actually dealing with > the concerns. > I'm having trouble finding it (or my Gmail search skills are lacking); could you please provide a pointer to your review of the current one to which you're awaiting replies? > >> 1. Background and motivations > >> > >> In 2007, [RFC4871] (Domain Key Identified Mail / DKIM) was > published, > >> outlining a mechanism for a domain to sign email in a way that > >> recipients could ensure that the email had come from an entity > >> possessing the secret key matching a public key published in the DNS > >> by the source domain. For clarity in this document we call this > >> established scheme "DKIM1". > > > *Again, the defined semantic of DKIM is not to ensure who a message > > 'came from'. This confuses common practice with design. * > > > It is to identify an entity that takes 'some' responsibility for it. > > To be ultra-pedantic it merely shows that an entity with a copy of the > private key has been able to acquire a copy of (most of) the email which > has now come into your possession... > > Since this confuses what with how, it is not merely pedantic. > > DKIM states its semantics. Focusing on the mechanics distracts from the > statement of intended semantics. > > The new drafts state a very different semantic, demonstrating a very basic > misunderstanding of what DKIM does and does not do. > > And since I've posted text to that effect multiple times, it is odd that > this point continues to be ignored. > Relative to the stated goals of this new work, I think the salient point is that DKIM does not provide the "had come from" assurance that the new work needs. As mentioned on another thread, we all really hoped it could, or did, but it can't and so it doesn't. I agree we need to get the history right here. I don't necessarily agree that this is fatal to adoption. > > Like the rest of the email architecture, the design of DKIM is much more > > > flexible. And this point of confusion sets the stage for an approach to > email > > that is much more constraining than email is designed to be. The word > > Procrustean is apt. > > > A casual dismissal with a comment like 'things have changed' is the > usual > > response to this point. Unfortunately it mostly reflects a lack of > effort to > > consider tradeoffs, or to embrace the historical IETF bias to retain as > much > > usage flexibility as supportable. > > >> This document has been obsoleted and updated many times since then, > >> and a large amount of operational experience has been gained using > >> it. However, it has some known weaknesses with some kinds of email > >> flow. > >> > >> 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, you 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. 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. > 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). > > > 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. > > > *What the above language actually implies is that this new effort > > represents a substantially larger and more ambitious goal. One for > > which I believe there is little or no technical history and > > certainly no operational history.* > > > This lack of experience with any mechanism -- other than a basic email > object - > > - > > that works through multiple postings/deliveries makes this aspect of the > design > > goal an open research topic. > > > And there are no ready proposals that have been developed and discussed > and > > converged on, ever since the expansion of DMARC use created a problem > for > > multi- > > posting/delivery sequences. /That's quite a few years without landing on > a > > concrete proposal./ > > > *Surviving arbitrary manipulations that might take place, when going > > through delivery and re-posting, is another open research topic.* > > Interesting that none of the above observations prompted any response... > Is it not a re-stating of the prior points, so replying to them would yield the same (or similar) answers? -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
