Note: Not cc'ing the DMARC list as this is a DKIM only draft. Given the discussions about twice ranging implications of a change like this (the end of email where RCPT TO changes in transit to start), the document needs far more discussion regarding the impact on the current email architecture before it can be considered in any way complete.
As much as I appreciate having my input acknowledged, please remove me from the acknowledgement section. If this proposal is going to go forward, I don't want my name on it anywhere. Scott K On November 15, 2016 7:45:52 PM CST, "Murray S. Kucherawy" <superu...@gmail.com> wrote: >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 >> > > >------------------------------------------------------------------------ > >_______________________________________________ >dmarc mailing list >dm...@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
