When calling to have a wg adopt a draft, it is worth reviewing comments
on that draft beforehand Apologies for not responding to this
semi-official response to my unofficial review of the draft in January.
I will note that Allen's was the only response to my detailed review.
And it was only to my summary comments.
On the average, that speaks poorly both for group engagement and for
advocate engagement.
So...
On 3/12/2025 7:51 AM, Allen Robinson wrote:
Thanks for the thorough review. There's quite a bit to reply to here,
and I've done my best to group replies by common themes. I read
through but did not reply to the protocol comments for now because I
think it's more productive to come to consensus on the problems and
how a new protocol could address them before debating what the
protocol looks like.
> Replay is just a sender infrastructure problem
Replay is called out as a potential problem in the DKIM RFC, so it
doesn't feel unreasonable to try to solve it in some way.
The mere fact of being mentioned does not say anything about the
observation that DKIM replay happens because a platform has inadequate
controls on vetting, monitoring, and/or controlling its own /authorized/
users.
Hence, creating a mechanism to be supported throughout the Internet, to
deal with this problem, is a pretty classic case of externalizing a
problem, and making everyone else pay for it.
I'm not saying let's not do it, but I AM saying we need to be clear
about the actual source of the problem and, perhaps, consider ways to
limit its requirements, where possible.
In an ideal world every system that generates mail could have complete
certainty that every message sent through it is non-malicious. I don't
think we live in a world that's anywhere close to this.
This seems to seek to dismiss the concern. But the issue is not 'every'
system. The issue, in fact, is relatively few systems. The ones with a
business model that acquires a great many, unveted users, resulting in
their having no accountability.
> Feedback as a separate work item
Mentioning feedback mechanisms in passing in a DKIM2 overview document
but leaving specification of who gets reports and what those reports
contain to a separate document makes sense to me.
It is more than an overview document.
*But now that you raise it, it's worth wondering what it means for the
wg to adopt it, given its apparently-multiple roles.*
> Backscatter/forging of origin
The "origin" in this context is the 821.From, and not the original
author of the message.
How is the reader to know that?
While yes, the name of the command could lead to that interpretations,
it's actual an error-returns message address -- same as upper left-hand
corner on a postal envelope -- current pressure to force it to be the
same as the *22.From notwithstanding.
Forging of the origin means using that identity in an unauthorized
way. The proposal does intend on preventing one system from directing
return traffic to another system, because that's what backscatter is.
Specifying an alternate address for error response is not 'forging'.
(There is a reason I keep referring to many of these assertions and the
resulting conventions as Procrustean. They reduce email flexibility and
the reductions should be treated with concern, not the casual dismissal
they usually get.)
The relationship between 821.From and 822.From does change a little
bit under DKIM2.
DKIM has no relationship with 821.From. None. Zero. Zilch.
DKIM has no relationship with 822.From, other than including it in the
hash, with no semantic of that inclusion. None. Zero. Zilch.
For originating systems, DKIM2 expects alignment (for now, proposing
reuse of DMARC alignment definition) between 821.From, 822.From, and
DKIM2 signature. For further hops, there is expected alignment between
signature header and 821.From but no relationship to 822.From is required.
The requirement for alignment makes this new thing actually be a new
DMARC. Not obviously a new DKIM.
> Definition of forwarding
In the context of DKIM2, this is the act of accepting a message with
some 821.To <http://821.to>address and resending it to some number of
other 821.To <http://821.to>addresses, potentially after modifying the
message.
Note that this is a very basic, very important definition and it was not
in the document.
Generally, I think RFC5598 is friendly to that interpretation, but since
that doc isn't being used and especially since people generally use that
word very inconsistently, it should be formally defined or its
definition formally cited.
This definition covers most MTAs, if I understand correctly.
In terms of Internet Mail architecture, an MTA does not do the function
you described.
Lots of software providing MTA functions do that, of course, but they
are doing more than an MTA function.
Networking architecture is not the same as software architecture.
Needing to change the 821.From in this case is certainly a large
change for the ecosystem as a whole, but one that we feel provides
sufficient value to justify the cost.
Please explain, in a cost-benefit manner.
Making major changes to a global infrastructure should warrant some
careful due-diligence.
I think an argument could be made that this definition doesn't apply
to all relays.
bingo.
Systems that don't need to change 821.From or 821.To and don't modify
the message being transferred would probably be able to operate
without attaching their own signatures.
So, actual MTAs do not need changing.
> Why declare the next destination?
It is believed that this will mitigate the valuable aspect of
malicious DKIM replay, which is delivery of a single authenticated
message to many different recipients. DKIM2 does not mitigate repeated
delivery to the same address, but the value of doing this maliciously
is pretty low, between a desire to cast a wide net with whatever bad
content is being sent and the likelihood of deduplication on the
recipient meaning that at most one copy makes it to the recipient anyway.
This line of thinking confuses me.
If the originator does a DKIM signature that covers author and recipient
-- and, really, only recipient is important to the classic Replay
problem, and if the receiver has access to the 'current' RCT-TO address,
to feed into its calculation of the DKIM signature, then why is anything
else needed?
> Why do DSNs go to the previous hop instead of the originator?
DSNs should already follow the return path, so I don't think that
changes under DKIM2. What DKIM2 proposes to change is that the return
path must mirror the forward path. For example, if a message went
through A->B->C, system B would not be allowed to reuse A's 821.From
to make the return path be C->A.
If I recall, the document had some basic justification for this
requirement, having to do with backscatter, not Replay. But it is,
really, a massive infrastructure change.
/**** I think it also is a change to RFC5321, not to DKIM. ****/
> Intermediary trust when modifications can't be recorded
The intent here is to support things like security gateways.
That term sounds interesting. I have no idea what it refers to, though
I could invent a number of plausible guesses.
If an infrastructure change is being proposed 'to support' something
that does not have a common definition, it might be wise to provide a
definition, get widespread support for it, get agreement that it needs
supporting, and get agreement that this mechanism is the bast -- most
effective, least impactful -- method of supporting it.
A common feature for these products is filtering out content, and
recording the removed content somewhat defeats the purpose of removing it.
This can be broken down further into inbound and outbound cases. For
inbound, whatever system the gateway is passing the mail to would
probably need to implicitly trust the gateway. For outbound,
recipients can't be expected to trust the gateway, so the gateway
needs to be able to (re)sign as if the content being sent was unmodified.
There's quite a bit of unknown complexity around further forwarding of
mail modified by these gateways. This may end up needing to treat the
forwarded message as if the forwarding domain originated it, requiring
a new DKIM2 chain and potentially a rewrite of the 822.From address.
Without commenting further on the specific, additional details you've
provided I will note that this seems like an issue likely best factored
out of basic mail handling is, possibly layered on top of it.
For use among the network of 'security gateways' that need it. Without
bother the rest of the infrastructure.
Just a thought.
> Specifying a list of headers
In my opinion this is an opportunistic attempt to simplify the common
case, while still allowing expansion of the signed headers list via
the h= tag. I don't think it's a critical feature because, as you
point out, a minimum list could be mandated without requiring DKIM2's
h= tag to have a different meaning than DKIM's h= tag.
Developing a set of common header fields to sign might be fine, but it
is an operational convention in the realm of BCP, not a protocol
revision. Unless it violates the current DKIM spec, which I believe it
does not.
> Sender-suggested uniqueness idea
I agree that this seems less than useful on the surface, and needs
some very strong supporting evidence if it is going to be added.
I'm reasonably confident that the senders that think they want this
will quickly realize that they don't, and we will have built it out
for no reason. I'm guessing that senders asking about this are
actually worried about addressing replay-like attacks, which DKIM2
already addresses.
It's been awhile. Any evidence of this change, so far?
> Sync vs async (delayed) bounces
There's a pretty big difference between rejecting a message in the
SMTP transaction, and accepting the message but later deciding it is
undeliverable. Notably, backscatter is impossible for synchronous
rejection since the recipient of the rejection is the other end of the
socket and can never be some unrelated system.
I suspect the problem with your model this comment is derived from is
that it is one-hop, rather than multi-hop.
Not all email is one-hop across the open Internet.
No matter how much Procrustes wants to believe otherwise.
However the sync/async terminology is not helpful. Call if rejection
during-vs-after an SMTP session.
DKIM2's addition of authentication for the return path makes
asynchronous bounce handling more resilient against backscatter.
There is some experience with authentication chains, such as for
DNSSec. I seem to recall some challenges...
> Improved privacy for forwarders
I think you've accurately interpreted the goal. The 821.From used by
the mailing list service to send messages to subscriber addresses
should not be the 821.From of the SMTP transaction that submitted the
message to the mailing list. Bounces would (and already should) go to
whatever 821.From the mailing list used for sending out the message.
As with you, I think it is already a convention. After all, the mailing
list is posting a new message, so creating a new error return address
has always been a good idea.
Making a BCP that makes it normative doesn't require a change to DKIM.
(It isn't really DKIM-related, anyhow, is it?)
> DMARC breakage in mailing lists
You refer to existing mitigations. What mitigations are these?
ARC.
And, somewhat more interesting: Having mailing lists just bypass DMARC
protections by changing the *22.From address. (This, of course, does
nothing about the Display-Name, there, which is what recipients see --
and they usually do not see the address. And it does nothing about the
phishyness of the Body, which is where the actual danger lies.)
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
