Hi Dave, Sorry for the delay in replying to this - I've been traveling back from IETF in Dublin. Thanks for this very detailed review!
I think there are three key significant issues that you've raised here: * whether this is DKIMbis or a broader thing * the timeliness of bringing this work to IETF * the utility of recording changes to a message at each hop There's also just some general wordsmithing to be done, but some of that might fall out from substantive discussion on those points. Rather than having this thread splinter, I'm going to create a separate thread for each of the above topics so we don't lose them in the responses. Regards, Bron. On Thu, Nov 14, 2024, at 07:14, Dave Crocker wrote: > Hi... > > On 11/7/2024 6:42 AM, Murray S. Kucherawy wrote: >> I've loaded that text into the datatracker for DKIM, and move it to "Draft >> Charter" state: >> https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > > Commenting on that draft: > > > >> Attribution of email is made difficult by the exact properties that make >> email valuable as a technology - a heterogeneous network of systems with >> different owners, different software, different update lifecycles - and of >> course different bugs! >> > > > > > This is an impressive opening sentence, but I'll suggest that, at best, it > not be the opening. DKIM exists and is in widespread use. For a long time. > So, this is a follow-on effort, which means that there are quite a few years > of context. While there can be some utility in pedagogy in a charter, it > should state, and work, from the established context. > > Also, generally, something like an IETF charter needs to work hard to focus > on immediate pragmatics, rather than broad concepts. The latter seems to me > to make more sense for the IRTF. > > > Also "attribution of email" seems atypical and extremely broad phrasing. All > sorts of different things involving email might benefit from 'attribution'. > Also, while I might have missed it, I believe 'attribution' is not a term in > common use around email technical or email security or anti-abuse communities. > > > >> Emails also often flow indirectly through these networks, undergoing >> redirection, expansion into multiple copies via aliases and mailing lists, >> as well as rewriting and filtering before eventually arriving at a mailbox >> or being processed by a receiving software agent. >> > While 'indirect' has well-established context in many email technical > circles, I believe it does not have clear, consistent, and precise meaning. > So it needs to be defined here, with more than an example. > > > I see this is an extremely important point, since the movement that has taken > place with email is to consider tight integration of domain name and sending > platform, in substantial contrast with the way email worked for perhaps 40 > years. That is, 'indirect' is tending to be treated as almost aberrant, or > at least as problematic. > > > >> DKIM gave us good tools for attributing the source of messages that were not >> modified between originator and destination. >> > That's not the exact definition of DKIM's semantics. So, for example, a > vetting authority that does not actually send a message could sign it and > feed the signature back to a platform that does the sending. (And there used > to be a production example of this happening.) > > > Also, a platform might affix multiple dkim signatures, using different domain > names, to cover various roles. These are not all 'sources' of the message, > are they? > > The problem, here, is the danger of taking common practice and retrofitting > it as a requirement to something that actually permits a much wider range of > use. > > > >> Several attempts have been made to address the issues that arise with >> intermediaries. For various reasons, these technologies have failed to fully >> address the issues that arise when changes are legitimately made or when bad >> actors alter or replay messages, and we do not have well-specified >> mechanisms that ensure that error reports reach all the entities that need >> to be aware of them. >> > This is a useful paragraph. I think it needs context. Perhaps: > > >> A DKIM signature will typically survive relaying through a Mail Transfer >> Agent (MTA) from posting to delivery. The signature will typically not >> survive through an intermediary, which takes delivery and re-posts to a >> fresh set of recipients, such as is common for a mailing list service. >> Typically, intermediaries modify a message in ways that break the original >> DKIM signature. >> > > > > >> This working group will take a holistic approach to the underlying problems >> of attribution, error signalling, and trust relationships between the >> entities involved in handling an email - from its inception to arrival at >> its final destination. The working group will use the mechanisms of DKIM as >> a basis, extending it to solve the problems that have been identified in >> real-world usage. >> > This is extremely vague, absent any statements about approaches or final > capabilities. Unfortunately, this kind of vagueness does not bode well for > timely or effective wg output, given common wg processes. > > > > > > >> It will be necessary for any new mechanism to work in parallel with the >> existing attribution mechanisms, and have a clean upgrade path. >> > Parallel vs. upgrade are separate paths. Really, they compete. If > 'separate' is what is meant, then this is not a DKIMbis effort. (And > creation of a parallel capability tends to be a lot more challenging for > gaining widespread adoption.) > > > > >> This work will have a wide scope and the design may supersede, modify, or >> replace many parts of the current email attribution techniques and >> associated reporting mechanisms - while retaining the ability to support the >> same use-cases. >> > Since 'email attribution techniques' isn't anchored, the reader can't guess > what might be affect or what certainly won't be. > > > One thing that seems clear to me is that this text rather strongly indicates > that this is NOT a DKIMbis enhancement effort but is considerably more > ambitious. Just how ambitious cannot be determined, since, again, the > language is vague. > > > > > >> To gain widespread adoption, it is expected that design proposals will be >> tested during the development of specifications. The working group will >> favor designs that are tested at scale and may dismiss those that are not. >> > There's already been discussion about the problem with requiring testing at > scale before accepting a proposal. > > > IETF requirements for implementation, anytime before considering Full > Standard, are usually basic, functional testing, rather than for performance > or scaling. > > I think that when those are a major concern, the testing is usually done > before coming to the IETF. > > > > > >> This working group will produce the following document(s): >> >> • A design overview describing the problem area and proposed mechanism >> > Frankly, I think this needs to be in an advanced state prior to chartering > this as an IETF effort. Otherwise, the wg will spend a long time debating > what problems it is trying to solve and what approaches to consider. > > > The IETF really is not a good venue for the kind of broad discussions > required to reach convergence on what that first bullet requires. > > > >> • An algebra for describing how to reverse common changes to email content >> > As appealing as this topic is, I continue to believe it is a distracting and > possibly counter-productive path to pursue. > > > It is the sort of capability that can only work if the scope of acceptable > changes is kept extremely small. If it is then enforced, it becomes > yet-another way that email is made to sleep in a Procrustean bed, further > limiting the range of its uses. > > > >> • A specification for authenticated email flow through multiple sites. >> > Email already flows through multiple sites, called MTAs. I assume what is > meant is through multiple intermediaries, with repeated posting/delivery > sequences. > > > > > > >> • A specification for error and bounce handling with the authenticated >> email flow. >> > We don't already have that? The charter needs to be specific about what we > already have and how it is insufficient and what types of enhancements are > expected. > > > > > > >> • A best practices guide for implementation during the changeover period, >> in which interoperability with existing standards needs to be maintained. >> > 'changeover period'? This sounds like there is expected to be an actual > replacement (of DKIM?) That's pretty much not how the Internet works. (cf, > IPv4, IPv6). At best, 'changeover' typically takes one or more decades. > > If, on the other hand, what is meant as operational advice for adoption of > the enhancement, then it would probably be best to say something like that. > > > One of my mantras is: > >> If it is an enhancement, then what worked before will continue to work. >> >> If the new thing does not directly support the old thing, then the new thing >> is entirely new (and actually competes with the old thing -- and will be a >> lot hard to get widespread adoption.) >> > > > > >> This working group will also update the following existing document(s): >> >> • DMARC to add DKIM2 as an additional authentication mechanism > > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > *** bluesky: @dcrocker.bsky.social *** > mast: @[email protected] > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
