I've uploaded the charter text at the top of this thread to the tracker (not the one from 11/27 yet). I wanted to do another round trip on some of Dave's points.
I am not concerned with milestones yet. The text is far more important. On Wed, Nov 27, 2024 at 4:15 PM Dave Crocker <d...@dcrocker.net> wrote: > Summary: > > - As provided, this is an extremely broad and extremely vague > statement of work. It continues to sound far more appropriate for the IRTF > than the IETF, especially absent a concete draft specification to take as > input. (It's not as if the IETF hasn't accepted charters like this. But > it /is/ as if such working groups have typically not fared well. Stated > more baldly, "let's charter a group and then figure out what we are going > to do" has a bad history in the IETF.) > > Bron (or anyone involved), do we have any initial documents to propose formally in the charter? > > - The draft seems to include a target of 'trust relationships' which > is an open research topic that DKIM only indirectly relates to, except for > trusting a signature. > > DKIM benefits from trust relationships, as does any other authentication protocol, and is of limited use without them, but pays very little attention to them in text because they are the purview of an implementation's "special sauce". If there's a clear intent to develop an interoperable notion of trust relationships (i.e., reputation), we should say so explicitly, otherwise I suggest that we should avoid the topic or, at a minimum, leave it to a post-rechartering topic. > > - IETF Internet Mail handling really only covers a single > posting/delivery sequence. It touches on more elaborate sequences, but > only piecemeal. And draft charter does not really note or deal with this > difference in scope. So the proffered 'holistic' effort is a very > considerable increase in scope from something labeled DKIMbis or DKIM2. > > I concur, though I don't believe this is a showstopper, is it? Maybe we just need to be more explicit that the scope here is to try to carry authentication information from injection through delivery and every intermediary in between. > > > Detailed comments: > > > DKIM2 Draft Charter <https://notes.ietf.org/#Background>Background > > Emails often flow indirectly through multiple systems, 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. > > The opening sentence sets a stage that matches many end-user experience > views of email, but misses the basic technical distinction that is the > essence of the enhancement being sought. *As described in that sentence, > email is delivered more than once, before it is 'finally' delivered.* > > So instead, perhaps: > > It is common for an email to go through multiple posting/delivery > sequences, before eventually arriving at a 'final' mailbox or being > processed by a 'final' receiving software agent. Examples of such > 'indirect' flow include redirection through an alis, expansion into > multiple copies via an alias or a mailing list, as well as rewriting and > filtering before eventually arriving at a mailbox or being processed by a > receiving software agent. > > Would like to hear other opinions of this. > I left 'rewriting' in but actually don't know what it refers to, nor why > 'filtering' is relevant to DKIM signature survival. > > (By the way, I thought that posting from an ESP was also classed as an > indirect flow. Is this not correct?) > I presume "filtering" includes any sort of stripping of material an intermediary or edge MTA might consider to be worth stripping for whatever reason (e.g., malformed header fields) but I agree that an example might be helpful to clarify. I imagine "rewriting" is there for any of a number of reasons. Very early on in my email career I used to see things like m...@example.com used externally but it was rewritten (unnecessarily, it turns out) to m...@host.example.com prior to delivery when the main ingress server figured out which host was mine. There are probably more apt modern examples. > > DKIM provides a way to detect that the content of a message was not > altered between the signing domain and its eventual destination. > > This sounds correct but can be misleading, given the 'eventual'. > ...between the signer and any verifier? > DKIM was designed to work from one posting to one delivery. It was > never intended to survive the vagaries of what can happen between a > delivery and a next posting. That it sometimes does survive is nice, but > was not a design goal. > > So what is being sought here is a very basic and very substantial increase > in scope for DKIM. > Is this another example of what you described above as the perceived use case vs. what's actually happening? Perhaps: "DKIM provides a way to detect that the content of a message was not altered between the signer and a verifier, even if this requires one or more intermediate deliveries and re-injections." > > Several attempts have been made to address the issues that arise with > alterations made by intermediate systems. For various reasons, these > technologies have failed to provide the information to reliably distinguish > between legitimate mail, and replay or alteration of messages by bad actors. > > DKIM does not attempt to distinguish 'legitimate' mail from mail that is > not legitimate. > >From the use here, I infer "unmodified since injection" to cover content and something about the original, intended recipient set to cover replay. > As for 'replay' it needs to be precisely defined here, especially since > there are different views about what it refers to. > +1 > As for alteration by bad actors, I was not aware that that is considered a > problem for DKIM. In fact I thought it was /not/ a problem. So this needs > to be explained and documented. > This gets to "acceptable" mutations, whatever that means. Or "innocent", maybe? > > Objectives > > This working group will take a holistic approach to the underlying > problems of message alterations, error handling, and trust relationships > between the systems involved in handling an email - from its inception to > arrival at its final destination. > > There are problems with error handling? What are they? I don't recall > seeing discussion of this. What is the actual work to be done? What goals > for improvement are sought? > +1 > Trust relationships are far -- very far -- beyond the scope of DKIM, other > than whether a DKIM signature can be trusted. > I think it's fine to discuss how trust relationships might couple with DKIM to impact handling decisions, but how to develop or track trust is probably rightly out of scope (unless someone has something in mind). > Given the considerable increase of scope for DKIM and range of topics > cited here for improvement, the charter should have a concrete proposal to > take as input, if only to provide an example of how one might approach > dealing with these topics. > I would prefer a good starting point as well. > > The working group will use the mechanisms of DKIM as a basis, extending > and modifying them to solve problems that have been identified in > real-world usage. > > Since they have been identified, they should be documented here, clearly > enough to aid the working group in knowing whether something is in-scope > our out of scope. > +1 > > It will be necessary for any new design to work in parallel with the > existing mechanisms, and have a clear upgrade path. > > If it is parallel, it is independent. So I don't know what it means 'to > work' in parallel. And I don't know what it means to not work in parallel. > I imagine the intent is not to disrupt the deployed DKIM base while DKIM2 (or whatever) is being developed or deployed. > > To achieve its goals, this work requires a wide scope. The design may > supersede, modify, or replace many parts of the current email > infrastructure and associated reporting mechanisms - while retaining the > ability to support existing use-cases. > > Oh. In parallel with existing /email/. You want to replace the current > Internet Mail infrastructure. Gosh... > > Forgive me, but, again, this is something for the IRTF, not the IETF. > I'm not convinced there's an IRTF project to charter here; this feels IETF-y to me. I do think, if anyone's actually built and tried this already, I'd love to hear what the result is after even a brief trial. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
