On Sat, Feb 1, 2025 at 10:00 AM Dave Crocker <d...@dcrocker.net> wrote:
> As such, an honest and pragmatic charter needs to cite that draft and > needs to explicitly encourage consideration of alternatives. > I think I'm fine with adding something like this, though I would hope everyone realizes that it's expected in open standards work and shouldn't be necessary. And as I mentioned elsewhere, the IETF is allergic to a closed process, and I think if that's the path the broader community or the IESG sees when the work comes up for publication, it's going to have a Bad Time(tm). > As for the current draft text details... > > Background > > An Internet message (email) may, from creation to final delivery, pass > through multiple intermediaries, some of which simply handle and route the > message, others effecting an interim delivery and re-injection into the > ecosystem. There are complexities with this handling model, such as > evaluation, filtering, intentional mutation, and even malicious activities. > > Again, the term intermediaries does not have a clear, consistent, > widely-held meaning. It could reasonably mean MTAs. It could reasonably > mean mailing lists. Because it variously does. > > There is no way to know what is meant here. Especially for a potentially > wide-spread audience, including folk with little email technology > background, but who need to understand the goals of this working group. A > charter needs to be understandable to such folk. > To me, this reads like: There are message originators, there are message consumers (i.e., the end users), and everything in between is some kind of intermediary; this latter group could handle the message in lots of different ways. The mention of the possibility of delivery and re-injection was added at your advice, I believe. If it's only confusing the story, we can remove it. But since we keep coming back to this paragraph, I'm starting to think we could just drop it or cut nearly all of it. I don't think we need to spend a ton of energy expounding precisely on the complexities of email to lay the groundwork for this charter. "The email ecosystem is venerable and complex" might be all we need to say. Do you have an alternative suggestion? > The core email protocols do not provide for authentication of the > identifiers in the message that indicate authorship, receipt, or handling, > nor do they involve themselves with evaluation of the content for any sort > of validity or safety. DKIM [STD 76 > <https://datatracker.ietf.org/doc/std76/>] defines a mechanism for > associating a domain name with a message stream and validating its use, > which permits evaluation of the stream with a high probability that the > owner of that domain name has some responsibility for the handling of that > message. > > There are contemporary issues, which were not concerns at the time of STD > 76 <https://datatracker.ietf.org/doc/std76/> or earlier standards, that > the community now seeks to address, including the following: > > - > > There is a desire to maintain validation of a message's signing > identifier across common transit and forwarding modifications. When a > message goes through a re-posting, such as through a mailing list, the > validation signature typically does not survive and cannot be recovered. > Fixing this would permit a more robust evaluation of the message. > > 'Message's signing identifier" has meaning only to experts and has not > been introduced or explained here. > There must be some reasonable boundary regarding how far into definitions the charter has to go. It's enough, I think, that we reference STD 76 where all of the background can be found. > So, perhaps: > > DKIM attaches a domain name to a message, by using a cryptographic > signature. The signature survives simple relaying but does not survive > transit through some {intermediaries?}. There is a desire to retain > signature validity across a wider range of common transit, including where > modifications are made during forwarding, such as by mailing lists. > > Sure, but this drops the "some responsibility" language you had provided previously. Are we OK with that? > > - > > Objectives > > The working group will develop a new technology suite that seeks to > address these concerns. Pursuit of incremental enhancements to DKIM and/or > novel applications of DKIM are preferred, but not required. In particular, > this technology will strive to: > > - > > Provide stronger assurances against unauthorized use of the (envelope) > sender, reducing the success of direct domain name misuse and improving the > value of delivery status notifications; > > 'stronger' only makes sense when there is some history of attempting > assurances. To my knowledge, there is no such history. > > I suggest removing the word, to avoid implying a history of failed effort > about this. > Fair enough, since this is the first attempt to include the envelope in the calculus. > > > - > > Identify message mutations made by any handling agent; and > > This objective has no foundation in the charter. There is nothing to > indicate why it is a desirable effort, relevant to the problems listed > above. Nor any indication that it has no operational history in networking > services. > The first bullet in the problem statement is the impetus for doing this. > > > - > > Attach annotations in transit of the intended chain of handling to > assure accountability for each delivery. > > ditto. > The last two bullets in the problem statement are the basis for this goal. > > The working group will strongly prefer output that, when deployed, does > not disturb the deployed ecosystem. It may, however, through the normal > course of evolution, replace technologies such as DKIM, DMARC, and ARC. > > The issue is less about disturbing the deployed ecosystem and more with > seeking incremental improvement, where replacement is a last resort. The > difference between these two is extremely important. Especially given the > demonstrated positions of the primary advocates of this work. > How about this? "The working group will prefer a result that is incremental to the deployed ecosystem. It may, however, determine that a technology that supersedes existing technologies such as DKIM, DMARC, and ARC, is a superior solution. In either case, the working group will be expected to document support for its decisions." > Proposed Milestones > > [dates to be negotiated; focus on the sequence for now] > > - > > WG Formation: Feb 2025 > - > > Overview document: Mar 2025 > - > > Mechanism document draft(s): Mar 2025 > > Looking at the history of email specification efforts in recent years, how > are these dates plausible? > > > As the annotation indicates, the dates are to be ignored for the time being. I'm far more interested in getting to consensus on the text in the prior sections and on the set and ordering of milestones irrespective of dates, and we can agree on dates when chartering is imminent. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
