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.
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 > 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. 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. > > > [..] > >> 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. 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. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
