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"
<superuser(_at_)gmail(_dot_)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
<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
------------------------------------------------------------------------
_______________________________________________
dmarc mailing list
dmarc(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html