Key Changes:
* Removed milestone dates
* Simplified a lot of the supporting text
* No mention of "trust relationships"
* Used the words "hop" and "hops" to align with the terminology in
RFC5322.
The word hop does not appear in RFC5322.
I suspect you mean RFC5321. Unfortunately, it's use in the latter might
be confusing, since it does not distinguish between SMTP 'hops' -- ie,
simple MTA-MTA relaying -- versus a series of multiple posting/delivery
sequences, such with mailing lists, which produce a very different
architectural environment than simple relaying.
An example of the danger to design thinking here is that simple relaying
within a single posting/delivery sequence is supposed to be highly
constrained, with a goal of no changes to the author's message. By
contrast, a sequence involving re-posting intermediaries permits
arbitrary changes to the original message.
* Detailed known issues, and specified the three major issues being
addressed explicitly: modifications, lack of signature on
recipient, lack of signature on sender/bounce address.
Except it does not really detail those issues. It makes some assertions
of things that must be changed, but does not explain why, either in
terms of the technical details or the operational import.
DKIM2 Draft Charter
Background
Emails often flow indirectly through multiple systems - at each hop
potentially 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.
This opening sentence demonstrates the problem of failing to distinguish
between a classic SMTP-based single posting/delivery, versus more
elaborate scenarios with multiple deliveries in the sequence leading to
a 'final' recipient.
Known difficulties caused by multi-hop email delivery include:
* If a message is modified after DKIM signing, it is not possible to
determine what was modified, or which hop made which changes.
Why is it important to know this? The draft does not say.
But since discussion on this list and elsewhere has explained this, I'll
respond to the expected explanation:
I believe the idea of being able to reverse changes, for the purpose
of validating the original signature, is lacking any experimental,
never-mind operational, experience. This a reason to treat this
line of effort as research. And yes, I mean it qualifies as an
academic research topic.
And there is a social-level potential downside to such work: A
design goal of being able to do this is likely to have the
operational effect of marginalizing any types of changes done by an
actual intermediary, such as a mailing list. So while the current
email world is fine with a mailing list doing whatever it wishes
to/with a message, this new, reversible world will likely treat
non-reversible changes as misbehaviors, causing 'failure'.
This problem of marginalizing otherwise-acceptable behaviors has
already been demonstrated, with misuse of the word 'forgery' in
email, and constraints on the values permitted in a number of
address fields.
* The SMTP RCPT TO address might not be present in the signed header
fields of an email, meaning that the same message can be sent to
arbitrarily many recipients, and those recipients can not tell if
the signer intended to them as recipients.
If only it were possible to define a header field to hold this value and
then to develop operational expectations for its inclusion... Rather
than, say, inventing a whole new protocol.
Previous discussions about replay cited this. (As I recall, I was one
of its proponents.)
But I'll also note that the bullet specifies a consequence that is not
strictly correct. This is probably an artifact of not having explained
exactly what scenarios are of a concern.
To preserve the original DKIM signature and to send to new recipients,
as if the message came from the original signer, requires a certain kind
of collusion between the original author and the misbehaving recipient,
as well as the misbehaving recipient's platform operator.
This collusion with the original author is why I've noted that, really,
the actual Replay attacks that happen originate from failures of
internal controls at the original author's email platform.
A lack of vetting and accountability for those using that platform.
Hence, seeking public standards to respond to this is externalizing an
internal problem.
* Similarly, a message with the exact same DKIM signature can be
legitimately received by multiple recipients at a single domain,
meaning that tracking signatures is not sufficient to determine
whether a message is being replayed.
Either this bullet is, really, the same as the previous one, or I've no
idea what 'problem' is being claimed here.
I've tried to formulate some guesses, but don't have confidence that any
of them is what you mean.
* The SMTP MAIL FROM address can be forged, meaning that accepting
an email and later sending a DSN to that address can cause
backscatter, making it hard to perform asynchronous content
analysis or delay delivery while collecting more signal; leading
to the use of greylisting as a suboptimal workaround to delay
making a determination.
Since the SMTP Mail From is not a signature and since it is specified to
permit any address, no it cannot be 'forged'.
On this, I have a better ability to guess at what is actually meant, but
it's better for the authors of the charter to make that clear.
The caution that I will offer is to make sure that any claimed 'problem'
is described very carefully and that it describes an actual problem and
that the problem is demonstrably serious enough to warrant an
international standard at dealing with it.
Objectives
The working group will extend and modify the mechanisms of DKIM to
address message alterations, to provide signing of the intended
recipient address at each hop, and to make asynchronous delivery
status notifications usable.
As I noted before, the expected result will not be extending and
modifying. This is inventing an entirely new protocol. It reuses some
DKIM components, but the plan is for something that is architecturally
and fundamentally different.
Also: I get accurate and useful delivery status notifications all the
time. So if there is an operational problem with them, it has not been
described.
It will be necessary for any new design to work in parallel with the
existing mechanisms, and have a clear upgrade path.
There is no 'upgrade' between independent, incompatible protocols.
There is just adoption of the new and, possibly, dropping the old.
If someone thinks otherwise, then please provide a substantive explanation.
/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
