Thanks Murray. Sorry I haven't got back on this, I've been on vacation with my parents in Tasmania, where the weather has been beautiful :)
I like your wordsmithing - it says similar things with different words that might be clearer to the people who need to understand what we're doing. I agree with the other comments that I've seen in this thread that it is worth having a specific mention of the need to handle delayed bounces without backscatter, but it looks like you've already handled that! Cheers, Bron. On Wed, Jan 15, 2025, at 13:40, Murray S. Kucherawy wrote: > Hi again, > > So with a few expressions of agreement and nobody telling me I'm way off > base, let me toss a revision of my own out for consideration. I'm keen to > hear from everyone about whether this is better or worse and any constructive > suggestions; I'm particularly keen to hear from those who had concerns about > the versions we've discussed so far. > > I have not entered this in the tracker but I will if we think this is a good > next step. > > Have at it. > > -MSK > > 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 affecting 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. > > The core email protocols do not provide for authentication of the identities > in the message or evaluation of the content for any sort of validity or > safety. DKIM [STD 76] extended the basic messaging function by providing > assurance that a message was not modified between a signing agent and a > verifying agent by affixing a domain-specific signature. > > Still, there exist known shortcomings in the email model that DKIM alone is > not designed to address, including the following: > > * There is a desire to confirm that a message received truly originated from, > or with the approval of, the identity claiming to have done so. Mutations of > a message in transit interfere with the validity of DKIM signatures, which > stymies such efforts. If a message is modified after DKIM signing, it is > generally not possible to determine what was modified, or which agent in the > handling chain made which change(s); these would be useful inputs to a more > robust evaluation. > * A DKIM signature is independent of the true set of (envelope) recipients of > the message, meaning that the same message and signature can be sent to > arbitrarily many recipients, across one or many independent injections into > the ecosystem, and those recipients can not tell if the signer intended to > include them as recipients. > > * “Backscatter” can result from unauthorized use of the (envelope) sender of > a message, where bulk failure notifications go to an address that is not > responsible for such unauthorized use. > > No optimal or preferred remedy to any of the above is provided by any > contemporary technology. > Objectives > The working group will observe the success of current technologies, primarily > DKIM, reusing its techniques where applicable, to develop a new technology > suite that seeks to address these concerns. Early experience from the > deployment of ARC [RFC 8617] will also be considered. In particular, this > technology will: > > * 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; > > * Identify message mutations made by any handling agent; and > * Attach annotations in transit of the intended chain of handling to assure > accountability for each delivery. > > 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 and ARC. > > To allow for widespread adoption, proposed solutions are expected to be > robust in terms of interoperability and scalability. > Deliverables > > The working group will produce multiple documents: > > * An overview document describing the problem area and proposed mechanism > (Informational) > > * One or more documents on implementation of the mechanism (Standards Track) > * An Applicability Statement guiding implementation during any deployment > period, in which interoperability with existing mechanisms needs to be > maintained (Standards Track) > > The working group may optionally introduce the mechanism document at > Experimental status first to gain operational experience before pursuing > Standards Track status. > > This working group will also liaise with the DMARC working group on adding > its specification as a new recognized authentication mechanism. If the DMARC > working group has concluded by that time, this working group can undertake > that update in coordination with the responsible Area Director. > Proposed Milestones > [dates to be negotiated; focus on the sequence for now] > > WG Formation: Jan 2025 > Overview document: Feb 2025 > Mechanism document draft(s): Mar 2025 > Experiments and drafts: Apr 2025 - Nov 2025 > Implementation guide: Nov 2025 > Publish documents as a group: Dec 2025 > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org > -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
