On Mon 09/Jun/2025 18:44:05 +0200 Bron Gondwana wrote:
On Mon, Jun 9, 2025, at 11:30, Alessandro Vesely wrote:
[...] As Dave said, there always will be legitimate scenarios
that match replay abuse scenarios.
I think this is the root of our disagreement. I fundamentally disagree that
there will be legitimate scenarios that match replay abuse scenarios with DKIM2.
After your description, quoted below, I gather our disagreement stems form the
term *replay abuse scenario*.
Definition #1: Replay abuse is a message signed by a reputable domain
rebroadcast by a foreign MTA without re-signing it.
Definition #2: Replay abuse is a message signed by a reputable domain
rebroadcast by a foreign MTA without recipient consent.
By definition #1, replay abuse is not possible within DKIM2. However, if the
forwarder in turn DKIM2 signs the message for each new recipient (definition
#2) it becomes formally indistinguishable from mailing list traffic.
Best
Ale
--
If every mail server which touches the message on a legitimate flow supports
DKIM2, then it's not possible to replay those messages.
As a recipient, you can keep track of domains which you have seen use DKIM2 in
the past, and stop accepting messages which claim to have been to those domains
and yet don't have a DKIM2 next-hop; because those are replays. We could also
add a DNS record along the lines of `p=dkim2always` which said that any message
which claims to have been sent to this domain as a DKIM2 destination will
always have another DKIM2 header added for its next hop - so forwarders could
assert their participation.
So quite fast, a flow like: [email protected] -> [email protected] ->
[email protected] could be fully secured.
Nobody could take any one of those messages and replay them, because any sender who had
seen both fastmailteam.com, ietf.org, and google.com DKIM2 signing messages would reject
a replay of either of any of those message versions, because they all specified a next
hop which was a known DKIM2 participant. There would be no legitimate, unsigned
"replay" possible for any of those messages, because the only party that could
possibly have forwarded them on would have added another header, and you can't fake that
without an aligned key.
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
