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

Reply via email to