ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-kucherawy-dmarc-rcpts

2016-11-14 02:58:21
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 
<martijn(_at_)lapsedordinary(_dot_)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