On 11/21/2024 1:21 AM, Bron Gondwana wrote:
I have made a second pass at it. Text below, or see the raw copy at:
https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA
Summary:
* As provided, this is an extremely broad and extremely vague
statement of work. It continues to sound far more appropriate for
the IRTF than the IETF, especially absent a concete draft
specification to take as input. (It's not as if the IETF hasn't
accepted charters like this. But it /is/ as if such working groups
have typically not fared well. Stated more baldly, "let's charter a
group and then figure out what we are going to do" has a bad history
in the IETF.)
* The draft seems to include a target of 'trust relationships' which
is an open research topic that DKIM only indirectly relates to,
except for trusting a signature.
* IETF Internet Mail handling really only covers a single
posting/delivery sequence. It touches on more elaborate sequences,
but only piecemeal. And draft charter does not really note or deal
with this difference in scope. So the proffered 'holistic' effort is
a very considerable increase in scope from something labeled DKIMbis
or DKIM2.
Detailed comments:
DKIM2 Draft Charter
// <https://notes.ietf.org/#Background>Background
Emails often flow indirectly through multiple systems, undergoing
redirection, expansion into multiple copies via aliases and mailing
lists, as well as rewriting and filtering before eventually arriving
at a mailbox or being processed by a receiving software agent.
The opening sentence sets a stage that matches many end-user experience
views of email, but misses the basic technical distinction that is the
essence of the enhancement being sought. *As described in that sentence,
email is delivered more than once, before it is 'finally' delivered.*
So instead, perhaps:
It is common for an email to go through multiple posting/delivery
sequences, before eventually arriving at a 'final' mailbox or being
processed by a 'final' receiving software agent. Examples of such
'indirect' flow include redirection through an alis, expansion into
multiple copies via an alias or a mailing list, as well as rewriting
and filtering before eventually arriving at a mailbox or being
processed by a receiving software agent.
I left 'rewriting' in but actually don't know what it refers to, nor why
'filtering' is relevant to DKIM signature survival.
(By the way, I thought that posting from an ESP was also classed as an
indirect flow. Is this not correct?)
DKIM provides a way to detect that the content of a message was not
altered between the signing domain and its eventual destination.
This sounds correct but can be misleading, given the 'eventual'.
DKIM was designed to work from one posting to one delivery. It was
never intended to survive the vagaries of what can happen between a
delivery and a next posting. That it sometimes does survive is nice,
but was not a design goal.
So what is being sought here is a very basic and very substantial
increase in scope for DKIM.
Several attempts have been made to address the issues that arise with
alterations made by intermediate systems. For various reasons, these
technologies have failed to provide the information to reliably
distinguish between legitimate mail, and replay or alteration of
messages by bad actors.
DKIM does not attempt to distinguish 'legitimate' mail from mail that is
not legitimate.
As for 'replay' it needs to be precisely defined here, especially since
there are different views about what it refers to.
As for alteration by bad actors, I was not aware that that is considered
a problem for DKIM. In fact I thought it was /not/ a problem. So this
needs to be explained and documented.
Objectives
This working group will take a holistic approach to the underlying
problems of message alterations, error handling, and trust
relationships between the systems involved in handling an email - from
its inception to arrival at its final destination.
There are problems with error handling? What are they? I don't recall
seeing discussion of this. What is the actual work to be done? What
goals for improvement are sought?
Trust relationships are far -- very far -- beyond the scope of DKIM,
other than whether a DKIM signature can be trusted.
Given the considerable increase of scope for DKIM and range of topics
cited here for improvement, the charter should have a concrete proposal
to take as input, if only to provide an example of how one might
approach dealing with these topics.
The working group will use the mechanisms of DKIM as a basis,
extending and modifying them to solve problems that have been
identified in real-world usage.
Since they have been identified, they should be documented here, clearly
enough to aid the working group in knowing whether something is in-scope
our out of scope.
It will be necessary for any new design to work in parallel with the
existing mechanisms, and have a clear upgrade path.
If it is parallel, it is independent. So I don't know what it means 'to
work' in parallel. And I don't know what it means to not work in parallel.
To achieve its goals, this work requires a wide scope. The design may
supersede, modify, or replace many parts of the current email
infrastructure and associated reporting mechanisms - while retaining
the ability to support existing use-cases.
Oh. In parallel with existing /email/. You want to replace the current
Internet Mail infrastructure. Gosh...
Forgive me, but, again, this is something for the IRTF, not the IETF.
Deliverables
To gain widespread adoption, it is expected that proposed solutions
will be tested during the development of specifications. The working
group will favor designs which have been tested for interoperability
at scale.
This working group will produce multiple documents, at least:
* A overview document describing the problem area and proposed
mechanism (informational)
* One or more documents on implementation of the mechanism
(standards track)
* A guide for implementation during the changeover period, in which
interoperability with existing mechanisms needs to be maintained
(informational)
This working group will also liaise with the DMARC working group on
adding this as a recognised authentication mechanism.
Milestones
* WG Formation: Dec 2024
* Overview document adopted: Jan 2025
You think it will take only one month to complete the overview document,
given what time-frames other email work has been taking?
* Mechanism document draft(s) adopted: Mar 2025
Only two more months for a stable specification effort? Really?
* Experiments and updated drafts: Apr 2025 - Nov 2025
* Implementation guide adopted: Nov 2025
* Group of documents sent to IESG: Dec 2025
d/
--
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
