On Fri 20/Jun/2025 21:36:53 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 14:08, Alessandro Vesely wrote:
On Fri 20/Jun/2025 18:00:10 +0200 Bron Gondwana wrote:
On Fri, Jun 20, 2025, at 03:00, Alessandro Vesely wrote:
On Wed 18/Jun/2025 23:15:37 +0200 Bron Gondwana wrote:
Note that we're still signing each recipient individually. Then if Sheila has
a forwarding rule, it only keeps her i=1 header, so that forwarded message
would contain:
DKIM2: i=1; [email protected] [email protected]; d=example.com
DKIM2: i=2; [email protected]; [email protected]; d=example.org
This point relies entirely on the good faith of the forwarder. A malicious
replayer would put a different signature, in order to confuse the attribution
of reputation.
How? It's not like they can just arbitrarily make up a signature. My examples
here elide a bunch of crypto stuff which you can't actually create without
having a key in the DNS for example.org, and unless you own example.org, you
can't create that.
If you DO own example.org and you're the malicious forwarder then you're
tanking your own reputation. That's the point.
You get the same point also without having to add multiple i=i signatures. If
example.org is a throw away domain, evaluators would wonder whether to
attribute the reputation of example.com to the message, since that's where it
originated.
Oops, I meant i=1. Having so many signatures sounds excessive.
Example.com and example.org are different entities in my "example", if that
wasn't clear I'll use different names in future, so example.com doesn't have any choice
Example.com and example.org are clear enough. BCP 32.
Blaming Sheila for the forwarding might be dubious, because the forwarder might
have kept the wrong i=1 signature. In case of fraud, Alice is more likely to
be the culprit.
You are conflating who has what control here. If "alice" is the bad actor, and
has control of the signing architecture at example.org, I would say she almost certainly
ALSO has access to the incoming mail system, and could intercept sheila's email and
invalidly forward it.
I was hypothesizing example.com to host anonymous users, like Gmail, say. IME,
the role of example.org can be a throw away domain created for that purpose,
but also a hacked server which would stop spamming once notified.
Remember, this is a domain level signature, not an individual level signature.
Sure, you could lie about WHICH copy you are forwarding, if you have access to
all the copies.
So, I disagree that there's an issue here. Your example threat model doesn't
seem like a threat to me.
You certainly have more experience than me.
[..]
Isn't it possible to explicitly request the previous rt=? That is, to have:
DKIM2: i=2; [email protected]; [email protected]; d=example.org
Sure. You could do that. I don't know what you mean by "explicitly request". There's no
"request" here; unless you mean "request that bounces be sent to". I would expect most
sites to have a dedicated bounce handling address rather than process bounces sent back to the forwarding
target, but that's entirely up to the implementation.
It seems like there must be a step where only a "weak" match is possible, i.e.
checking the alignment between the corresponding domains rather than an exact
match. We are now requiring a weak match between the previous rt= and the
current mf= and an exact match between the current mf= and the actual return
path in the envelope. Alternatively, we could settle for alignment between the
return path and the current mf= (and the signature) and instead require an
exact match between the current mf= with the previous rt=.
I don't see the weakness. It's domain level, not individual level trust. We don't have
signing keys per user, so a domain can already "falsify" sending as any user at
that domain.
That is:
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DKIM2: i=1; [email protected] [email protected]; d=example.com
And then:
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DKIM2: i=1; [email protected] [email protected]; d=example.com
DKIM2: i=2; [email protected]; [email protected]; d=example.org
I believe any bounces generated after acceptance should use the actual
return-path, not rely on the signature's mf=. So having the actual return path
in the signature is of little importance. Perhaps having an exact match between
the previous rt= and the current mf= can provide more clarity in case of large
domains.
I disagree for the reasons I stated above. "Alice" could, if she had access to
the incoming mail flow and the signing key, just as easily create that message as she
could create one with different `mf=` per my example.
Yes.
The domain is the only interesting bit, and the ability for mail providers to
set up a bounce address different to the incoming mail address outweighs any
advantage of this mechanism.
Agreed. The only concern is that when the domain has billions of accounts,
forensic analysis might easily lose track of who was actually involved.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
