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 <superu...@gmail.com> wrote: > On Mon, Nov 14, 2016 at 10:36 PM, <ned+dm...@mrochek.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