On Mon, Nov 14, 2016 at 02:48:01PM +0900, Murray S. Kucherawy wrote: > On Mon, Nov 14, 2016 at 5:30 AM, Martijn Grooten <mart...@lapsedordinary.net> > wrote: > > It isn't very clear to me how this proposal deals with receipients at > different domains, including but not limited to blind carbon copies. I > may be showing my ignorance of how DKIM signing engines work under the > hood, but unless the email is not signed until a copy has been created > for each receiving domain, my understanding of the draft is that this > would result in every receiving domain receiving an invalid copy of the > email. > > > Yes, if you have three recipients going to distinct MXes, and you want this to > work, you need to sign each copy individually. You need to anticipate how the > message is likely to arrive, basically
This sounds like something that could easily go wrong, unless signing agents take a very cautious approach and create individual copies for each recipient domain. And even then, as the draft already mentions in section 5, it could go wrong if the verifier doesn't get the complete list of recipients. > Finally, is there a reason the proposal doesn't sign the canonicalized > list of recipients separately and add this signature as a separate DKIM > tag? This could allow for a more smooth transition period. > > Now that's an interesting idea. Other than that it makes the proposal backwards-compatible, it also gives some insight in possible replay attacks against DKIM. And it allows a spam filter that uses DKIM to make more granular decisions, e.g. "this looks like a replay attack, but the sender is a known list server, so it's probably okay". > One could even sign each recipient individually and add a list of > signatures to a separate DKIM header. This would allow the verifier to > check each recipient individually, which should be doable if their > number isn't too big and does not require knowledge of which signature > links to which recipient. > > I think that adds additional complexity beyond your previous suggestion and > I'm > not sure what the incremental gain is. It would allow for more flexibility. The current proposal checks whether the set of recipients seen by the verifier is the same set as that seen by the signing agent, while to prevent replay attacks, it only matters that the former is a subset of the latter. Mind you, it may still add too much additional complexity. And maybe there is an easier way to solve this cryptographically. I'll look around. Martijn. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html