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.