-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the end of January Dave Crocker posted a review of the then current "-01" version of draft-gondwana-dkim2-motivation. This document has now been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over 14 (sorry) emails... ">>" is a quote from our document, ">" a quote from Dave Crocker ... lines that do not start with a ">" are me speaking. - -=-=-=-=-=-=-=-=-=-=-=-=- >> A further issue is that bad actors may "replay" bad email that >> systems have DKIM signed and erode the reputation of the signer. > >Only bad actors who are within the signing domain's own community of users. > > *Let me repeat this: DKIM Replay relies on having the message > originate with a user who is authorized to send from the abused > domain's platform. * > >So, really, this is a failure of internal regulation and accountability that >is >being externalized here. Although that is strictly true, the recipients of the replayed email do not see it that way. Those recipients tend to blame the mailbox provider who has deemed the email to be authentic enough to place in their inbox. The mailbox provider's explanation that this is entirely legitimate email, that comes from where it says it does, has a DKIM1 signature that attests to it not being altered in any way cuts little ice. The mailbox provider is also stuck because the system doing the relaying to them may also be relying on the fact that the email is authentic ... and that system is also being used for all sorts of other email so blocking it is inappropriate. >Theoretically, it might involve a compromised account, within that services, >of >course. However that has not been part of the narrative reporting this >problem. Indeed ... but having said all that, the erosion of reputation of the signer is not, out in the real world, anything like fast enough for them to act (and it may be a one-off event so far as they are concerned). Hence the wish to address the replay problem... and the DKIM2 design we came up with does this -- not surprising because it was based on one of the anti-replay systems proposed a while back. Now, having agreed who is ultimately at fault ... I find myself at a loss to understand how this part of the review I am responding to is actionable in any way other than saying "replay is entirely the fault of the signer" within one or more documents -- which I don't think is in any way productive, and it hardly moves any protocol work forward. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ/lz+mHfC/FfW545EQKhzQCfXlEmULAyGk1DrxkyZ8DIRRmmwYgAoNKx YdWQTA9ryeeTNhroFavWdSgB =O/rF -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org