On 1/28/2025 7:29 AM, Murray S. Kucherawy wrote:
I've uploaded the discussed changes to the charter,
Core advocates of this effort are thoroughly committed to the details of
their draft document.
And they have been consistently hostile to proposals for alternative
details, either ignoring the suggestions, responding with casual
dismissal, or worse. Fundamentally, there has been no willingness to
engage in meaningful discussion about alternatives.
As such, an honest and pragmatic charter needs to cite that draft and
needs to explicitly encourage consideration of alternatives.
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.
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.
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.
*
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 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.
*
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.
*
Attach annotations in transit of the intended chain of handling to
assure accountability for each delivery.
ditto.
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.
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 Director.
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?
*
Experiments and drafts: Apr 2025 - Nov 2025
*
Implementation guide: Nov 2025
*
Publish documents as a group: Dec 2025
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
