ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

2016-11-16 08:52:03
Am 2016-11-16 14:03, schrieb Murray S. Kucherawy:
(dropping DMARC again)

On Wed, Nov 16, 2016 at 9:51 PM, Michael Storz 
<Michael(_dot_)Storz(_at_)lrz(_dot_)de>
wrote:

Version 01 is purely incremental, meaning you can just ignore the
new
tags if you're more worried about breakage of forwarding than the
attack it's trying to address.

Optional for the sender, yes, but not for the receiving MTA. If the
sender decides to use the new Anti-Replay-DKIM-Signature and has
published a DMARC policy with reject or quarantine, then this policy
is implicitly extended with

"ooh, and btw reject/quarantine ALL indirect emails, even if a
normal DKIM signature could be verified"

That's not correct.  The verifying MTA, if it doesn't know the new
tags, is unaffected by the new tags because RFC6376 directs the
verifier to ignore them.  It's as if they weren't there.


Ok, I see you have removed the hashing of the recipient together with the email itself. But how do you prevent a replay attack, if the new tag is not bound to the email and signed with the DKIM-key (that's how I read 4.1.4)? The spammer could remove the tag or provide his own tag with the new recipient before resending the email.

Michael

_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>