Re: [mailop] Dealing with a DKIM replay attack

[Eliot Lear]

On 8/14/16 6:46 AM, Steve Atkins wrote:
> If there were a protocol that said "if you receive mail signed by this
> domain / this key and the recipient isn't in the To: or Cc: field,
> block it", or some similar protocol that signed the envelope
> recipient, that would pretty much eliminate DKIM replay as a threat in
> some cases.

That would be a DKIM flag, right?  And you don't want to block- you just
want the signature treated as invalid.  Then normal DMARC processing
could occur.

Eliot




signature.asc
Description: OpenPGP digital signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack

[John Levine]

>If there were a protocol that said "if you receive mail signed by this domain 
>/ this key and the recipient isn't in
>the To: or Cc: field, block it", or some similar protocol that signed the 
>envelope recipient, that would pretty much
>eliminate DKIM replay as a threat in some cases.

It would, but it would also break innocent single message forwarding
and cause yet more grief for mailing lists.

A remarkable number of the addresses I manage for my church, local
town government, and so forth are just forwards to Gmail or the local
telco and cable ISPs.  You could certainly add workarounds, and in the
case of Gmail most of them have set up their Gmail accounts to send
mail with the forwarded address so Gmail knows what forwards to
expect, but it still adds complexity and fragility.

It's not clear that replay attacks are common enough to be worth extra
mechanism in potentially every message.

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vick Khera]

On Fri, Aug 12, 2016 at 7:12 PM, Tim Starr  wrote:
> The only benefit I can see from sending the exact same message from
> somewhere else would be to drive recipients to the same payload link, which
> suggests another possible way to stop this from paying off after detection:
> Make it so that all content links get turned into redirects you control, and
> can break upon request

You're not assuming the person doing the re-send is out for some form
of revenge to ruin the other person's reputation...

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop