Murray, et al,
I started this on Jan14 but, well, got distracted...
The draft is moving in a good direction, but I think it still has some
points worthy of serious concern.
Some basic points:
1. A charter has 3 audiences:
The IESG for approval;
The working group participants for team focus and coherence, and
adjudicating disagreements about scope and direction; and
The broader Internet technical community (including its managers,
who approve time and travel), for expanding participation and
garnering community support. A charter should be written to be
useful for this currently-uninvolved, probably-uninformed 'market'.
2. A charter has to explain the problems/opportunities it is targeting
and make a case for their importance.
3. It can help to include suggestions or draft specifications for
solutions, but that is value add and not automatically required.
However if the reality is that they exist and are expected to
dominate the working group, it is frankly misleading not to document
this in the charter. Given that existing work, the charter usually
indicates the role that pre-existing work is expected to play,
ranging from something generic like adding to discussion, all the
way up to providing a base that is expected to be changed only under
duress, presumably due to community momentum with the existing spec.
4. For cases of an established capability, the charter usually is
proactive in encouraging incremental enhancement, where possible.
Switching costs from what is existing, to something new, is usually
much, much higher than advocates appreciate. In other words, it is
difficult to move a global, operational base.
5. A charter needs to be very careful about its language, and
especially being technically precise and accurate; if it isn't, why
should anyone expect a quality technical output?
If the broader Internet community does not engage during development,
the resulting work risks being a mismatch with what that community will
accept. That is, they won't adopt and use it.
The proposed effort involves some features that appear to be easy to
obtain as value-add features and practices, on top of existing DKIM. WG
efforts should attempt to achieve that rather than wholesale
replacement, since they permit incremental specification and incremental
adoption and use. Having DKIM Replay protection appears to be a good
example, by simply defining a replica of the SMTP RCPT-TO address in the
header, and defining a common practice of including that header field it
in the signature.
The proposal for mandating forward and/or backward hop-by-hop behavior
reintroduces a form of source-routing. This might be a good idea, but
it has been operationally demonstrated to be a very high-risk approach.
Note that it is largely deprecated in services that used it. As an
obvious example, consider End-to-End Arguments. DKIM is a protocol
between end-systems, requiring no awareness or support from the email
infrastructure. The proposed hop-by-hop behavior is an infrastructure
play. Very, very different costs to achieve, and very different risk.
As for the v4 draft charter detailed comments...
On 1/14/2025 6:40 PM, Murray S. Kucherawy wrote:
An Internet message (email) may, from creation to final delivery, pass
through multiple intermediaries, some of which simply handle and route
the message, others affecting 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.
A basic problem, throughout this entire discussion, has been the effort
to treat simple relaying through MTAs, and a multiple-posting/delivering
forwarding sequence such as with mailing lists, as the same thing.
They aren't and never have been.
Treating them the same is a fundamental architectural change, at best
The above language hides this reality.
Mailing lists managers are not MTAs. Not architecturally, not as
software, and not operationally.
The core email protocols do not provide for authentication of the
identities in the message
"identities in the message" is too broad and too vague. A random name in
the body is not relevant, but this language would include it.
I suggest the reference be more explicit and constrained, such as:
"identities recorded for authorship, receipt, or handling of the
message".
(quibble: we keep saying identities when we usually mean identifiers.
at the least, this is an example of the need to be a lot more careful
about language.)
or evaluation of the content for any sort of validity or safety.
I have no idea what providing for evaluation of the content for validity
or safety means. Nor, I believe, is there any widespread history of
discussion of that, in those terms.
I suggest breaking this point out and writing something very different,
to set up the concern. (I don't understand the am not sufficiently
clear about what is intended here to be able to draft possible wording.)
DKIM [STD 76] extended the basic messaging function
No it didn't. It added a useful feature to the messaging landscape but
is not part of 'basic' messaging. Perhaps:
DKIM [STD 76] defines a means of associating a domain name with a
message stream and validating its use. This permits evaluating the
stream, with a high probability the owner of that name has some
responsibility for the handling of the message.
There is a continuing mis-statement that DKIM validates the 'source' or
the 'sender' or the 'author' of a message. It does none of that.
Really, it doesn't.
The assertion does describe the signing behavior of some platforms, but
it is not DKIM's semantic, nor does it cover the behavior of all signers.
Note for example that when a message passing through a handler like
Proofpoint, they might sign the message as it passes, but they are not
the source or sender or author of the message.
by providing assurance that a message was not modified between a
signing agent and a verifying agent by affixing a domain-specific
signature.
DKIM makes no such assertion, and it is not true as stated here.
All DKIM was designed to do was to reliably and authentically affix
/some/ identifier to /some/ parts of a message. This creates a
noise-free message stream that uses the identifier.
A side-effect of DKIM's technology is that the fields that are covered
by the signature -- and only those fields -- are protected in transit.
Other portions of the message are not.
Still, there exist known shortcomings in the email model that DKIM
alone is not designed to address, including the following:
There are additional needs. They are new. Or, at least, they were not
previously a priority. Since they were not needs when DKIM was
developed, they are not 'shortcomings'.
https://dictionary.cambridge.org/dictionary/english/shortcoming
When something goes beyond a design goal, it is not reasonable to
characterize what is now needed as a failing of the existing system.
If you have a two bedroom house and the family grows so that the family
needs more bedrooms, the problem is not a 'shortcoming' of the house,
but a changed demand by the family.
dictionary.cambridge.org
shortcoming <#>
SHORTCOMING definition: 1. a fault or a failure to reach a particular
standard: 2. a fault or a failure to reach a…. Learn more.
🔗 https://dictionary.cambridge.org/dictionary/english/shortcoming
<https://dictionary.cambridge.org/dictionary/english/shortcoming>
Focus the concern where it belongs: a new set of requirements.
* There is a desire to confirm that a message received truly
originated from, or with the approval of, the identity claiming to
have done so. Mutations of a message in transit interfere with the
validity of DKIM signatures, which stymies such efforts. If a message
is modified after DKIM signing, it is generally not possible to
determine what was modified, or which agent in the handling chain made
which change(s); these would be useful inputs to a more robust evaluation.
Perhaps:
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.
The idea of annotating reversible changes is in the weeds of solution
space, not the basics of need.
While mentioning a possible solution path might be useful, taking the
ability to do something that has no operational history at scale as
something implicitly expected and necessary is problematic to the health
of a working group.
* A DKIM signature is independent of the true set of (envelope)
recipients of the message,
'true'? DKIM has nothing to do with recipient addresses, as such.
Instead of casting this as a DKIM issue, cast it as a new functional
goal. Because it is.
meaning that the same message and signature can be sent to arbitrarily
many recipients, across one or many independent injections into the
ecosystem, and those recipients can not tell if the signer intended to
include them as recipients.
The charter needs to define DKIM Replay, since the term is over- and
mis-used, to claim a scope of concern much broader than reasonable. So,
DKIM Replay exploits the absence of a protected recipient address,
wheret an authorized user of a site sends a message that is signed
by that site, to a collaborating receiver than 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. Note that the author of the
message is authorized by the site with the author domain.
* “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.
No optimal or preferred remedy to any of the above is provided by any
contemporary technology.
good to include this.
Objectives
The working group will observe the success of current technologies,
primarily DKIM, reusing its techniques where applicable, to develop a
new technology suite that seeks to address these concerns. Early
experience from the deployment of ARC [RFC 8617] will also be
considered. In particular, this technology will:
Rather:
The working group will pursue incremental enhancements to DKIM
and/or DKIM use, where possible. It will pursue parallel or
replacement mechanisms only where incremental change is not feasible.
* 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;
The concept of authorized use of the Mail From exists in SPF and nowhere
else. As such, the premise of this objective is problematic.
* Identify message mutations made by any handling agent; and
I suspect this means identification of common mutations, rather than all
mutations, since there is no limit to the latter. This text needs
elaboration, for clarity and precision.
* Attach annotations in transit of the intended chain of handling to
assure accountability for each delivery.
Attach annotations specifying changes that were made in transit, as
part of an authenticated chain of handling, to aid accountability of
a message's handling
The working group will strongly prefer output that, when deployed,
does not disturb the deployed ecosystem.
Given the presumption of DKIM replacement, this sentence is surprising.
With the incremental approach I'm advocating, it might be reasonable to
retain.
It may, however, through the normal course of evolution, replace
technologies such as DKIM and ARC.
The draft specification this work is currently based on requires
replacement.
To allow for widespread adoption, proposed solutions are expected to
be robust in terms of interoperability and scalability.
I believe there are no IETF specifications lacking this as a
requirement. As such, it isn't meaningful to include, absent some sort
of technical details' being required or metrics attached.
Deliverables
The working group will produce multiple documents:
* An overview document describing the problem area and proposed
mechanism (Informational)
* One or more documents on implementation of the mechanism (Standards
Track)
huh? A standards track document about implementation? Seems odd.
I suspect what is meant a /specification/ of the required mechanisms.
* An Applicability Statement guiding implementation during any
deployment period, in which interoperability with existing mechanisms
needs to be maintained (Standards Track)
Given that 'implementation' is an ambiguous term, differently referring
to writing code, versus deploying, I suggest not using the word. I
think the intent here is "guiding deployment and use".
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
