-----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

Reply via email to