Hi...
On 11/7/2024 6:42 AM, Murray S. Kucherawy wrote:
I've loaded that text into the datatracker for DKIM, and move it to
"Draft Charter" state:
https://datatracker.ietf.org/doc/charter-ietf-dkim/
Commenting on that draft:
Attribution of email is made difficult by the exact properties that
make email valuable as a technology - a heterogeneous network of
systems with different owners, different software, different update
lifecycles - and of course different bugs!
This is an impressive opening sentence, but I'll suggest that, at best,
it not be the opening. DKIM exists and is in widespread use. For a
long time. So, this is a follow-on effort, which means that there are
quite a few years of context. While there can be some utility in
pedagogy in a charter, it should state, and work, from the established
context.
Also, generally, something like an IETF charter needs to work hard to
focus on immediate pragmatics, rather than broad concepts. The latter
seems to me to make more sense for the IRTF.
Also "attribution of email" seems atypical and extremely broad
phrasing. All sorts of different things involving email might benefit
from 'attribution'. Also, while I might have missed it, I believe
'attribution' is not a term in common use around email technical or
email security or anti-abuse communities.
Emails also often flow indirectly through these networks, 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.
While 'indirect' has well-established context in many email technical
circles, I believe it does not have clear, consistent, and precise
meaning. So it needs to be defined here, with more than an example.
I see this is an extremely important point, since the movement that has
taken place with email is to consider tight integration of domain name
and sending platform, in substantial contrast with the way email worked
for perhaps 40 years. That is, 'indirect' is tending to be treated as
almost aberrant, or at least as problematic.
DKIM gave us good tools for attributing the source of messages that
were not modified between originator and destination.
That's not the exact definition of DKIM's semantics. So, for example, a
vetting authority that does not actually send a message could sign it
and feed the signature back to a platform that does the sending. (And
there used to be a production example of this happening.)
Also, a platform might affix multiple dkim signatures, using different
domain names, to cover various roles. These are not all 'sources' of
the message, are they?
The problem, here, is the danger of taking common practice and
retrofitting it as a requirement to something that actually permits a
much wider range of use.
Several attempts have been made to address the issues that arise with
intermediaries. For various reasons, these technologies have failed to
fully address the issues that arise when changes are legitimately made
or when bad actors alter or replay messages, and we do not have
well-specified mechanisms that ensure that error reports reach all the
entities that need to be aware of them.
This is a useful paragraph. I think it needs context. Perhaps:
A DKIM signature will typically survive relaying through a Mail
Transfer Agent (MTA) from posting to delivery. The signature will
typically not survive through an intermediary, which takes delivery
and re-posts to a fresh set of recipients, such as is common for a
mailing list service. Typically, intermediaries modify a message in
ways that break the original DKIM signature.
This working group will take a holistic approach to the underlying
problems of attribution, error signalling, and trust relationships
between the entities involved in handling an email - from its
inception to arrival at its final destination. The working group will
use the mechanisms of DKIM as a basis, extending it to solve the
problems that have been identified in real-world usage.
This is extremely vague, absent any statements about approaches or final
capabilities. Unfortunately, this kind of vagueness does not bode well
for timely or effective wg output, given common wg processes.
It will be necessary for any new mechanism to work in parallel with
the existing attribution mechanisms, and have a clean upgrade path.
Parallel vs. upgrade are separate paths. Really, they compete. If
'separate' is what is meant, then this is not a DKIMbis effort. (And
creation of a parallel capability tends to be a lot more challenging for
gaining widespread adoption.)
This work will have a wide scope and the design may supersede, modify,
or replace many parts of the current email attribution techniques and
associated reporting mechanisms - while retaining the ability to
support the same use-cases.
Since 'email attribution techniques' isn't anchored, the reader can't
guess what might be affect or what certainly won't be.
One thing that seems clear to me is that this text rather strongly
indicates that this is NOT a DKIMbis enhancement effort but is
considerably more ambitious. Just how ambitious cannot be determined,
since, again, the language is vague.
To gain widespread adoption, it is expected that design proposals will
be tested during the development of specifications. The working group
will favor designs that are tested at scale and may dismiss those that
are not.
There's already been discussion about the problem with requiring testing
at scale before accepting a proposal.
IETF requirements for implementation, anytime before considering Full
Standard, are usually basic, functional testing, rather than for
performance or scaling.
I think that when those are a major concern, the testing is usually done
before coming to the IETF.
This working group will produce the following document(s):
*
A design overview describing the problem area and proposed mechanism
Frankly, I think this needs to be in an advanced state prior to
chartering this as an IETF effort. Otherwise, the wg will spend a long
time debating what problems it is trying to solve and what approaches to
consider.
The IETF really is not a good venue for the kind of broad discussions
required to reach convergence on what that first bullet requires.
*
An algebra for describing how to reverse common changes to email
content
As appealing as this topic is, I continue to believe it is a distracting
and possibly counter-productive path to pursue.
It is the sort of capability that can only work if the scope of
acceptable changes is kept extremely small. If it is then enforced, it
becomes yet-another way that email is made to sleep in a Procrustean
bed, further limiting the range of its uses.
*
A specification for authenticated email flow through multiple sites.
Email already flows through multiple sites, called MTAs. I assume what
is meant is through multiple intermediaries, with repeated
posting/delivery sequences.
*
A specification for error and bounce handling with the
authenticated email flow.
We don't already have that? The charter needs to be specific about what
we already have and how it is insufficient and what types of
enhancements are expected.
*
A best practices guide for implementation during the changeover
period, in which interoperability with existing standards needs to
be maintained.
'changeover period'? This sounds like there is expected to be an actual
replacement (of DKIM?) That's pretty much not how the Internet works.
(cf, IPv4, IPv6). At best, 'changeover' typically takes one or more
decades.
If, on the other hand, what is meant as operational advice for adoption
of the enhancement, then it would probably be best to say something like
that.
One of my mantras is:
If it is an enhancement, then what worked before will continue to work.
If the new thing does not directly support the old thing, then the
new thing is entirely new (and actually competes with the old thing
-- and will be a lot hard to get widespread adoption.)
This working group will also update the following existing document(s):
* DMARC to add DKIM2 as an additional authentication mechanism
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
