There's been a lot of great feedback here. I just cranked out an update
based on the discussion so far:
https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01
I forgot to update the title of Section 3, but other than that I think I
captured what's been discussed. Please let me know what I've missed.
-MSK
On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy
<superuser(_at_)gmail(_dot_)com>
wrote:
On Mon, Nov 14, 2016 at 10:36 PM, <ned+dmarc(_at_)mrochek(_dot_)com> wrote:
Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:
[...]
That's a pretty excellent summary. A couple of points:
I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being
the ideal choices. Is that correct? If so, we would just need to
determine the algorithm for generating the signed content that would be
included in the augmented signature. If we do something like the random
salt suggestion, is this sufficient?
- pick a random string S of length L using only printable ASCII characters
(I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and
express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an
"rs" (recipient salt) tag
This is not reversible so nothing is leaked, but as we've all conceded by
now it's not hard to attack this to recover the hashed address especially
since one might have good guesses as to what that address would be.
I can't see the point of actually encrypting the hashed content, because
anybody can decrypt it with the public key.
What am I missing?
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html