WG Review: Domain Keys Identified Mail (dkim)

[The IESG <[e-mail]>]

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list ([e-mail]) by 2025-02-16.

Domain Keys Identified Mail (dkim)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Laura A <[e-mail]>
  Tim Wicinski <[e-mail]>

Assigned Area Director:
  Murray Kucherawy <[e-mail]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[e-mail]>
  Orie Steele <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/ietf-dkim/
  Archive: https://mailarchive.ietf.org/arch/browse/ietf-dkim/

Group page: https://datatracker.ietf.org/group/dkim/

Charter: https://datatracker.ietf.org/doc/charter-ietf-dkim/

Background

An Internet message (email) may, from creation to final delivery, pass
through multiple handling agents, some of which simply route the message,
others effecting an interim delivery and reinjection 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 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] attaches a domain name to a message by using a
cryptographic signature.  The signature survives simple relaying but does not
survive transit through some intermediate handling agents.  There is a desire
to retain signature validity across a wider range of common transits,
including where modifications are made during forwarding, such as by mailing
lists.

There are contemporary issues, which were not concerns at the time of STD 76
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.

* DKIM “replay” exploits the absence of a protected recipient address, where
an authorized user of a site sends a message that is signed by that site to a
collaborating receiver, which then re-sends the message to other recipients
not in the original set of recipients, but without any indication that the
message has been re-posted.  This way, the domain name of the DKIM signature
is intended to result in a positive reputation analysis that will obtain
deliveries that otherwise would not succeed.

* “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.

* Service providers that generate mail on behalf of an entity have no
visibility into any resulting errors, as they are sent to the entity and not
the provider.

No optimal or preferred remedy to any of the above is provided by any
contemporary technology.

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 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 that affect signature
validity; and

* Attach annotations in transit of the intended chain of handling to assure
accountability for each delivery, aiding in the mitigation of backscatter.

The working group will prefer a result that is incremental to the deployed
ecosystem.  It may, however, determine that a technology which 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.

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 specifying the new mechanism(s) (Standards Track)

* An Applicability Statement guiding use 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 Directors.

Initial Documents

The working group will consider adoption of these documents as starting
points:

* draft-gondwana-dkim2-motivation
* draft-gondwana-dkim2-modification-alegbra

As usual, consideration of other alternative proposals is encouraged.

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

* Experiments and drafts: Apr 2025 - Nov 2025

* Implementation guide: Nov 2025

* Publish documents as a group: Dec 2025

Milestones: