On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <dubro...@corp.mail.ru> wrote:
> 15.11.2016 2:07, Murray S. Kucherawy пишет: > > 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? > > > There is no need to reverse if you know e-mail address. Alice can check > Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and > check if he is in 'er'. > Yes. I wasn't identifying "not reversible" as a shortcoming, but rather as a benefit. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
